كيفية تحسين سرعة صفحة الويب الخاصة بك للحصول على موقع إلكتروني أسرع
تم التحديث: ٢٧ مارس ٢٠٢٦
ملخص
ركز على مؤشرات أداء الويب الأساسية (Core Web Vitals): LCP (سرعة رسم أكبر كتلة محتوى أقل من 2.5 ثانية)، INP (التفاعل مع الرسم التالي أقل من 200 مللي ثانية)، و CLS (تراكم تغيرات تخطيط الصفحة أقل من 0.1). استخدم صور AVIF، وقواعد التخمين (Speculation Rules) API للتنقل الفوري، و HTTP/3، و Lighthouse للقياس. السرعة تؤثر بشكل مباشر على تصنيفات SEO ومعدلات التحويل.
سرعة الصفحة ليست مجرد ميزة إضافية. خوارزمية التصنيف في Google تكافئ المواقع السريعة. يغادر المستخدمون المواقع البطيئة (معدل ارتداد 50% في الصفحات التي تستغرق أكثر من 3 ثوانٍ). وبالنسبة لعملك، فإن كل تحسن بمقدار 100 مللي ثانية في وقت التحميل يمكن أن يزيد التحويلات بنسبة 1-7%.
في عام 2026، أصبح تحسين السرعة أمراً مفروغاً منه. لكن الأدوات تطورت. انتقل التركيز من وقت التحميل الخام إلى استجابة التفاعل — مدى سرعة تمكن المستخدمين فعلياً من القيام بشيء ما على صفحتك. يغطي هذا الدليل المقاييس المهمة والتقنيات العملية لتحسينها.
فهم مؤشرات أداء الويب الأساسية (Core Web Vitals)
مؤشرات أداء الويب الأساسية هي ثلاثة مقاييس تستخدمها Google للتصنيف. وهي تقيس تجربة المستخدم الحقيقية:
سرعة رسم أكبر كتلة محتوى (LCP)
يقيس LCP مدى سرعة ظهور المحتوى الرئيسي. وتحديداً، أكبر عنصر مرئي على الشاشة.
الهدف: أقل من 2.5 ثانية
0s ─────────────────────── 4s
├─── Good (LCP <2.5s)
├─── Fair (2.5s-4s)
├─── Poor (>4s)
ما الذي يعتبر "محتوى"؟
- الصور
- العناوين ونصوص المتن
- صور غلاف الفيديو (Video poster images)
- العناصر التي تحتوي على صور خلفية
ما الذي لا يُحتسب؟
- عناصر SVG
- عناصر Canvas
- محتوى Iframe
كيفية تحسين LCP:
- التحميل الكسول (Lazy load) للصور الموجودة أسفل الجزء المرئي (below-the-fold):
<img src="hero.avif" loading="lazy" alt="Hero image" />
- تحسين المسار الحرج (Critical path): تقليل ملفات CSS و JavaScript التي تمنع العرض (render-blocking).
// Before: render-blocking CSS
<link rel="stylesheet" href="styles.css" />
// After: critical CSS inline, defer the rest
<style>{criticalCSS}</style>
<link rel="stylesheet" href="styles.css" media="print" onload="this.media='all'" />
- التحميل المسبق (Preload) لعنصر LCP:
<link rel="preload" as="image" href="hero.avif" />
التفاعل مع الرسم التالي (INP)
يقيس INP مدى استجابة موقعك لتفاعلات المستخدم. عندما ينقر المستخدم، أو يمرر، أو يكتب، كم من الوقت يستغرق حتى الرسم التالي؟ حل هذا المقياس محل تأخير الإدخال الأول (FID) في مارس 2024.
الهدف: أقل من 200 مللي ثانية
لماذا هذا مهم؟ الاستجابة البطيئة تجعل موقعك يبدو معطلاً، حتى لو تم تحميله في النهاية.
0ms ──────────────────── 500ms
├─── Good (INP <200ms)
├─── Fair (200-500ms)
├─── Poor (>500ms)
كيفية تحسين INP:
- تقسيم مهام JavaScript الطويلة (التي تزيد عن 50 مللي ثانية تصبح ملحوظة):
// Bad: blocks for 100ms
function processLargeDataset(data) {
const result = data
.map(item => expensiveCalculation(item))
.filter(item => item.isValid);
updateUI(result);
}
// Good: break into chunks
async function processLargeDataset(data) {
const chunkSize = 100;
for (let i = 0; i < data.length; i += chunkSize) {
const chunk = data.slice(i, i + chunkSize);
const result = chunk
.map(item => expensiveCalculation(item))
.filter(item => item.isValid);
updateUI(result);
// Yield to browser to handle other tasks
await new Promise(resolve => setTimeout(resolve, 0));
}
}
- استخدام web workers للحسابات المكلفة:
// main.js
const worker = new Worker('worker.js');
worker.postMessage({ data: largeDataset });
worker.onmessage = (event) => updateUI(event.data);
// worker.js
self.onmessage = (event) => {
const result = complexCalculation(event.data);
self.postMessage(result);
};
- تأجيل JavaScript غير الضروري:
<!-- Critical for interactivity -->
<script src="interactive.js"></script>
<!-- Deferred: analytics, non-essential features -->
<script defer src="analytics.js"></script>
تراكم تغيرات تخطيط الصفحة (CLS)
يقيس CLS التغيرات غير المتوقعة في تخطيط الصفحة. عندما يتحرك المحتوى فجأة بينما يحاول المستخدمون التفاعل، تكون تجربة سيئة.
الهدف: أقل من 0.1
مثال: أنت على وشك النقر فوق زر، ولكن يتم تحميل إعلان ويدفع الزر لأسفل. تنقر بطريق الخطأ على الإعلان بدلاً من ذلك. هذا هو تغير التخطيط (layout shift).
كيفية تحسين CLS:
- حجز مساحة للمحتوى الديناميكي:
<!-- Bad: ad can cause shift -->
<div id="ad"></div>
<!-- Good: reserve space -->
<div style="width: 300px; height: 250px;">
<div id="ad"></div>
</div>
- استخدام
content-visibilityلمنع التغيرات:
/* Prevent cumulative layout shift on images */
img {
content-visibility: auto;
}
- تجنب إدراج محتوى فوق المحتوى الموجود:
// Bad: prepend new items (shifts everything down)
setItems([...newItems, ...items]);
// Good: append new items (no shift)
setItems([...items, ...newItems]);
تحسين الصور
تمثل الصور عادةً 50-80% من حجم الصفحة. تحسينها له التأثير الأكبر.
AVIF: تنسيق الجيل القادم
تنسيق AVIF أصغر من WebP، وهو بدوره أصغر من JPEG. في عام 2026، أصبح دعم AVIF واسع النطاق (جميع المتصفحات الحديثة).
<picture>
<source srcset="image.avif" type="image/avif" />
<source srcset="image.webp" type="image/webp" />
<img src="image.jpg" alt="Description" />
</picture>
أحجام الملفات النموذجية لنفس الصورة:
- JPEG: 100KB
- WebP: 60KB
- AVIF: 40KB
استخدم ImageOptim أو TinyPNG أو Squoosh للضغط.
الصور المتجاوبة
قدم أحجاماً مختلفة بناءً على عرض الجهاز:
<img
src="image-400w.avif"
srcset="
image-400w.avif 400w,
image-800w.avif 800w,
image-1200w.avif 1200w
"
sizes="(max-width: 600px) 90vw, (max-width: 1200px) 70vw, 1200px"
alt="Product image"
/>
هذا يخبر المتصفح:
- على الشاشات التي يبلغ عرضها 600 بكسل أو أقل، قم بتحميل صورة بنسبة 90% من عرض نافذة العرض (viewport)
- على الشاشات التي يتراوح عرضها بين 600-1200 بكسل، قم بتحميل 70% من عرض نافذة العرض
- للشاشات الأكبر، قم بتحميل صورة ثابتة بعرض 1200 بكسل
تحسين الشبكة
قواعد التخمين (Speculation Rules) API
تسمح قواعد التخمين للمتصفح بجلب الصفحات مسبقاً (prefetch) أو عرضها مسبقاً (prerender) والتي من المرجح أن يزورها المستخدم بعد ذلك.
<script type="speculationrules">
{
"prerender": [
{
"source": "list",
"urls": ["/checkout", "/confirmation"]
}
]
}
</script>
بهذه الطريقة، إذا نقر المستخدم على "المتابعة لإتمام الشراء"، فستكون الصفحة محملة بالفعل في علامة تبويب مخفية.
HTTP/3 و Early Hints
بروتوكول HTTP/3 أسرع من HTTP/2. إذا كانت استضافتك تدعمه، فقم بتفعيله.
تخبر ميزة HTTP 103 Early Hints المتصفح بالبدء في جلب الموارد الحرجة قبل أن يصبح ملف HTML الرئيسي جاهزاً:
HTTP/1.1 103 Early Hints
Link: </css/styles.css>; rel=preload; as=style
Link: </js/app.js>; rel=preload; as=script
HTTP/1.1 200 OK
<!-- HTML content -->
معظم شبكات توصيل المحتوى (CDNs) مثل Cloudflare و Fastly تدعم هذا. تحقق من استضافتك.
القياس باستخدام Lighthouse
يعد Lighthouse هو المعيار الصناعي لقياس الأداء.
# Using Lighthouse CLI
npm install -g @google/lighthouse
lighthouse https://example.com --view
أو استخدم أدوات مطوري Chrome: F12 ← علامة تبويب Lighthouse ← "Analyze page load".
ما الذي يجب البحث عنه:
- الفرص (Opportunities): مرتبة حسب التأثير المحتمل (مثلاً، "تخلص من الموارد التي تمنع العرض: توفير 2.4 ثانية")
- التشخيصات (Diagnostics): تفاصيل حول ما هو بطيء
- عمليات التدقيق الناجحة (Passed audits): ما الذي يعمل بشكل جيد
حدد درجة مستهدفة لكل فئة:
- الأداء (Performance): 90+
- إمكانية الوصول (Accessibility): 95+
- أفضل الممارسات (Best Practices): 95+
- SEO: 100
مراقبة المستخدم الحقيقي (RUM)
تختبر الأدوات المعملية مثل Lighthouse موقعك في بيئة محكومة. أما مراقبة المستخدم الحقيقي (RUM) فتقيس تجربة المستخدم الفعلية.
مكتبة Web Vitals
import {
getCLS,
getFID,
getFCP,
getLCP,
getTTFB,
} from 'web-vitals';
getCLS(console.log); // Cumulative Layout Shift
getFCP(console.log); // First Contentful Paint
getLCP(console.log); // Largest Contentful Paint
getTTFB(console.log); // Time to First Byte
// Send to analytics
getLCP((metric) => {
analytics.track('Core Web Vitals', {
metric: metric.name,
value: metric.value,
rating: metric.rating, // 'good', 'needs-improvement', 'poor'
});
});
تعرض خدمات مثل Vercel Analytics أو Google Analytics 4 أو Datadog مؤشرات أداء الويب الأساسية من مستخدمين حقيقيين.
ميزانية الأداء
حدد أهدافاً لموارد معينة:
// Budget in lighthouse config
{
"budgets": [
{
"type": "bundle",
"name": "main",
"baseline": 150000,
"maxSize": 170000
},
{
"type": "font",
"name": "Inter",
"maxSize": 50000
}
]
}
قم بتشغيل Lighthouse CI في بيئة CI/CD الخاصة بك لإيقاف عمليات البناء (builds) التي تتجاوز الميزانية.
الأخطاء الشائعة
الكثير من نصوص الطرف الثالث (third-party scripts): التحليلات، الإعلانات، أدوات الدردشة — كل منها يضيف عبئاً إضافياً. قم بتحميلها بشكل غير متزامن (asynchronously).
خطوط الويب غير المحسنة: يتم تحميل خطوط النظام فوراً. تسبب خطوط الويب وميضاً من النص غير المرئي (FOIT). استخدم استراتيجيات font-display:
@font-face {
font-family: 'Inter';
src: url('inter.woff2') format('woff2');
font-display: swap; /* Show fallback until font loads */
}
الحزم الكبيرة (Large bundles): استخدم تقنية Tree-shaking لإزالة الكود غير المستخدم، وقم بتقسيم الكود حسب المسار (route)، واستخدم التحميل الكسول للمكونات:
// Before: entire library bundled
import { datePicker, dropdown, modal } from 'ui-lib';
// After: lazy load what you need
const datePicker = lazy(() => import('ui-lib/DatePicker'));
الاستجابات غير المضغوطة: تأكد من تفعيل ضغط gzip/brotli على خادمك.
أهم النقاط المستفادة
تحسين السرعة هو عملية مستمرة:
- قس أولاً: استخدم Lighthouse و Google Analytics لتحديد نقاط الاختناق.
- ركز على مؤشرات أداء الويب الأساسية: LCP و INP و CLS — هذه تؤثر بشكل مباشر على التصنيفات.
- حسن الصور: استخدام AVIF + الصور المتجاوبة يحقق أكبر المكاسب.
- قسم JavaScript: المهام الطويلة تدمر درجات INP.
- قس تجربة المستخدمين الحقيقيين: الأدوات المعملية قد لا تعكس الظروف الواقعية.
- راقب باستمرار: حدد ميزانيات الأداء وفرضها في مرحلة CI.
تحسن بمقدار ثانية واحدة في وقت التحميل يمكن أن يعني آلاف الدولارات من الإيرادات الإضافية للتجارة الإلكترونية. السرعة ليست خياراً.