مؤشرات أداء الويب الأساسية Core Web Vitals هي ثلاثة مقاييس تعتمدها جوجل لقياس تجربة المستخدم الحقيقية: LCP يقيس سرعة ظهور المحتوى الرئيسي، وINP يقيس سرعة استجابة الصفحة للنقر واللمس، وCLS يقيس مقدار تحرك عناصر التصميم. القيم الجيدة هي LCP حتى 2.5 ثانية، وINP حتى 200 مللي ثانية، وCLS حتى 0.1.
هذا هو المقال الرئيسي في سلسلة تسريع المواقع، وتتعمق المقالات الداعمة في تحسين LCP وصيغ الصور والخطوط وزمن الحظر الكلي TBT.
ما هي مقاييس Core Web Vitals؟
هي ثلاثة مقاييس، لكل منها حد “جيد” و”يحتاج تحسين” و”ضعيف”، وتقاس عند الشريحة 75 من مرات تحميل الصفحة الحقيقية. أي أن ثلاث زيارات على الأقل من كل أربع يجب أن تحقق الحد الجيد لتنجح الصفحة.
| المقياس | ماذا يقيس | جيد | ضعيف |
|---|---|---|---|
| LCP | تحميل المحتوى الرئيسي | ≤ 2.5 ث | > 4.0 ث |
| INP | الاستجابة للتفاعل | ≤ 200 م.ث | > 500 م.ث |
| CLS | تحرك التصميم المفاجئ | ≤ 0.1 | > 0.25 |
البيانات الميدانية مقابل بيانات المختبر
هذا هو الجزء الأكثر سوء فهم.
- البيانات الميدانية تأتي من مستخدمي كروم الحقيقيين (تقرير Chrome UX). يعرضها PageSpeed Insights في الأعلى عندما يكون لموقعك زيارات كافية، وتجمع Search Console الروابط حسب حالتها. وهذه هي البيانات التي تعتمدها أنظمة جوجل.
- بيانات المختبر تأتي من اختبار محاكى واحد مثل Lighthouse. يمكن تكرارها وهي ممتازة للتشخيص، لكنها لا تمثل تجربة مستخدميك.
نتيجة 100 في Lighthouse مع بيانات ميدانية راسبة تبقى راسبة، ونتيجة في السبعينات مع بيانات ميدانية ناجحة تعني تجربة جيدة للمستخدمين.
كيف تختبر Core Web Vitals
- PageSpeed Insights لرابط محدد: بيانات ميدانية (إن وجدت) واختبار Lighthouse.
- Search Console ← مؤشرات أداء الويب الأساسية لمجموعات الروابط على مستوى الموقع.
- لوحة Performance في أدوات مطوري كروم لتسجيل التحميل أو التفاعل ومعرفة ما يحدث بالضبط.
- مكتبة web-vitals إذا أردت جمع بياناتك الميدانية في أدوات التحليل.
اختبر القوالب المهمة: الرئيسية، صفحة تصنيف، صفحة منتج، مقال، وصفحة الدفع. وابدأ بالموبايل.
LCP: سرعة التحميل
LCP هو زمن عرض أكبر صورة أو كتلة نص في الشاشة الظاهرة، وفي أغلب المواقع يكون صورة الواجهة أو صورة المنتج أو العنوان الرئيسي.
أسباب شائعة لضعف LCP:
- بطء استجابة الخادم (ارتفاع TTFB).
- صورة LCP محملة تحميلا كسولا أو مكتشفة متأخرا أو ثقيلة.
- ملفات CSS وخطوط تحجب العرض.
- العرض من جهة المتصفح الذي يؤخر المحتوى.
مكاسب سريعة: التخزين المؤقت للصفحات، تقديم صورة الواجهة بصيغة حديثة وبالمقاس الصحيح، إضافة fetchpriority="high" لها، وعدم تحميلها تحميلا كسولا أبدا. الخطوات كاملة في كيفية تحسين LCP في ووردبريس.
INP: سرعة الاستجابة
يرصد INP زمن الاستجابة للتفاعلات (النقر واللمس والكتابة) طوال الزيارة ويعرض واحدا من أبطأها. وقد حل محل FID في مارس 2024 لأن FID كان يقيس تأخير أول تفاعل فقط.
أسباب شائعة لضعف INP:
- مهام جافاسكريبت طويلة تحجب الخيط الرئيسي.
- سكريبتات خارجية ثقيلة: أدوات الدردشة، مدير الوسوم، سكريبتات الإعلانات والتتبع.
- معالجات أحداث مكلفة تحدث أجزاء كبيرة من الصفحة.
- حجم DOM ضخم بسبب أدوات بناء الصفحات.
الحلول: احذف أو أخر السكريبتات غير الضرورية، قسم المهام الطويلة، وخفف معالجات الأحداث. والمقياس المختبري المقابل هو Total Blocking Time، راجع تقليل TBT.
CLS: ثبات التصميم
يجمع CLS التحركات المفاجئة في التصميم. المثال الشهير: توشك على الضغط على رابط فتظهر صورة فوقه فتضغط على إعلان بدلا منه.
أسباب شائعة:
- صور وإطارات iframe بدون عرض وارتفاع (أو
aspect-ratio). - شرائط إعلانية أو إشعارات كوكيز تضاف فوق المحتوى.
- خطوط ويب تتبدل بمقاسات مختلفة جدا.
- عناصر تتحمل متأخرا (مراجعات، تضمينات) بدون مساحة محجوزة.
الحلول:
<img src="hero.avif" width="1600" height="900" alt="..." />
.embed { aspect-ratio: 16 / 9; }
.notice { position: fixed; bottom: 0; } /* طبقة فوق المحتوى بدل دفعه */
للخطوط استخدم ضبط مقاسات الخط البديل (size-adjust وascent-override) أو خطا بديلا قريبا لتقليل القفزة عند التبديل.
خطة إصلاح مرتبة حسب الأولوية
- الخادم والتخزين المؤقت. كاش للصفحات، وكاش للكائنات إن دعمته الاستضافة، وشبكة CDN. بدون TTFB معقول لن يفيد الباقي كثيرا.
- عنصر LCP. مقاس صحيح، صيغة مناسبة، أولوية عالية، بدون تحميل كسول.
- CSS والخطوط. احذف CSS غير المستخدم بأمان، ضمن CSS الحرج، وحمل مسبقا الخط أو الخطين المستخدمين أعلى الصفحة.
- جافاسكريبت. احذف أو أخر أو أجل، وراجع سكريبتات الطرف الثالث.
- ثبات التصميم. أبعاد للوسائط ومساحة محجوزة للعناصر الديناميكية.
- أعد القياس ميدانيا بعد 28 يوما، لأن البيانات الميدانية نافذة متحركة.
هل تهم Core Web Vitals في السيو؟
هي جزء من إشارات تجربة الصفحة لدى جوجل، لكن جوجل أوضحت أن المحتوى الممتاز يمكن أن يتصدر حتى مع مؤشرات أضعف. تعامل مع السرعة كاستثمار في تجربة المستخدم ومعدل التحويل أولا، وستأتي فائدة السيو بعدها. وهي جزء من تدقيق السيو التقني الأشمل.
ملاحظات خاصة بووردبريس
- إضافة جيدة للكاش والتحسين تغطي معظم القائمة، لكن اضبطها بعناية. إعدادات “تأخير كل جافاسكريبت” العنيفة قد تكسر القوائم والسلايدر، فاختبر جيدا.
- أدوات بناء الصفحات تضيف وزنا على DOM وCSS، فأعد استخدام القوالب وتجنب التداخل الزائد.
- كل إضافة قد تحمل سكريبتات على الموقع كله، ومراجعة الإضافات غالبا هي أكبر مكسب.
- الاستضافة مهمة: الخادم المشترك المزدحم يظهر أثره في TTFB على كل صفحة.
أخطاء شائعة
- مطاردة 100 في Lighthouse بدلا من إصلاح البيانات الميدانية.
- اختبار الصفحة الرئيسية على الكمبيوتر فقط.
- تحميل كل الصور تحميلا كسولا بما فيها صورة الواجهة.
- تشغيل إضافتي تحسين معا تقوم كل منهما بضغط الملفات ودمجها.
إذا كان موقعك لا يجتاز Core Web Vitals وتريد خطة واضحة، اطلع على خدماتي أو تواصل معي.
الأسئلة الشائعة
ما هي مؤشرات أداء الويب الأساسية الثلاثة؟
Largest Contentful Paint (LCP) للتحميل، وInteraction to Next Paint (INP) للاستجابة، وCumulative Layout Shift (CLS) لثبات التصميم.
هل تؤثر Core Web Vitals على السيو؟
تستخدم جوجل إشارات تجربة الصفحة ومنها هذه المؤشرات في أنظمة الترتيب، لكن الصلة بالبحث وجودة المحتوى أهم. وتفيد المؤشرات الجيدة أكثر عندما تتقارب الصفحات المنافسة في باقي العوامل.
لماذا تختلف نتيجة Lighthouse عن بيانات PageSpeed Insights الميدانية؟
يجري Lighthouse اختبارا محاكى واحدا على جهاز واحد، بينما تأتي البيانات الميدانية من مستخدمي كروم الحقيقيين خلال 28 يوما على أجهزتهم وشبكاتهم، لذلك تختلفان غالبا.
متى حل INP محل FID؟
حل Interaction to Next Paint محل First Input Delay كمؤشر أساسي في مارس 2024.


