مؤشرات أداء الويب الأساسية Core Web Vitals هي المقاييس الثلاثة التي تستخدمها جوجل للحكم على إحساس الزائر الحقيقي بالصفحة: كم يستغرق ظهور المحتوى الرئيسي، وكم تسرع الصفحة في الاستجابة للمس والنقر، وكم يقفز التصميم أثناء التحميل. تؤثر هذه المؤشرات في الترتيب، لكن السبب الأعمق للاهتمام أبسط: الصفحات البطيئة المهتزة تخسر زوارها، والمقاييس تشير مباشرة إلى ما يزعجهم.
يشرح هذا الدليل كل مقياس بلغة واضحة، ويعلمك القياس الصحيح، ويستعرض الإصلاحات ذات الأثر الأكبر مرتبة تقريبا حسب الجهد مقابل العائد.
المقاييس الثلاثة بلغة واضحة
LCP: رسم أكبر محتوى
يقيس LCP الوقت حتى ظهور أكبر عنصر مرئي، عادة صورة رئيسية أو عنوان كبير، بعد أن يبدأ الزائر تحميل الصفحة. يجيب عن سؤال: "متى تبدو الصفحة محملة؟"
- جيد: أقل من 2.5 ثانية
- يحتاج تحسينا: 2.5 إلى 4 ثوان
- ضعيف: أكثر من 4 ثوان
INP: التفاعل حتى الرسم التالي
يقيس INP الاستجابة. عندما ينقر شخص زرا أو يفتح قائمة أو يكتب في حقل، يتتبع INP الوقت حتى يتفاعل ما على الشاشة بشكل مرئي. حل محل مقياس FID الأقدم لأن FID كان يقيس التفاعل الأول فقط؛ أما INP فينظر إليها جميعا ويبلغ عن واحد من الأسوأ.
- جيد: أقل من 200 ميلي ثانية
- يحتاج تحسينا: 200 إلى 500 ميلي ثانية
- ضعيف: أكثر من 500 ميلي ثانية
CLS: إزاحة التصميم التراكمية
يقيس CLS الاستقرار البصري. كل مرة يتحرك فيها محتوى بعد عرضه، كنص يقفز للأسفل لأن إعلانا حُمل فوقه، تضاف الإزاحة إلى النتيجة. يجيب عن سؤال: "هل شدت الصفحة الأشياء من مكانها وأنا أحاول القراءة أو النقر؟"
- جيد: أقل من 0.1
- يحتاج تحسينا: 0.1 إلى 0.25
- ضعيف: أكثر من 0.25
الخطوة الأولى: قس قبل أن تلمس شيئا
هناك نوعان من البيانات، والخلط بينهما يهدر أسابيع.
البيانات الميدانية هي ما عاشه الزوار الحقيقيون، تجمعها كروم وتُبلغ في تقرير Chrome UX Report. هذه ما تستخدمه جوجل فعليا للترتيب. تراها في PageSpeed Insights (القسم العلوي) وفي تقرير مؤشرات الويب الأساسية في Search Console.
البيانات المخبرية هي تحميل محاكى على جهاز متحكم به، تنتجها Lighthouse أو لوحة الأداء في أدوات المطور. قابلة للتكرار ومفصلة، مثالية للتشخيص، لكنها ليست ما ترتب به جوجل، وكثيرا ما تخالف البيانات الميدانية. فخ شائع: اختبارك المخبري على حاسوب سريع يبدو ممتازا بينما بياناتك الميدانية من مستخدمي الهواتف الحقيقيين راسبة.
سير العمل: استخدم البيانات الميدانية لتقرر ماذا تصلح وهل نجح الإصلاح، والبيانات المخبرية لتفهم لماذا البطء. شغل PageSpeed Insights على قوالبك الرئيسية (الصفحة الرئيسية، صفحة المقال، صفحة المنتج)، وسجل أي مقياس يفشل، وقدم القالب صاحب أكبر زيارات.
إصلاح LCP
تنقسم مشكلات LCP إلى أربعة تأخيرات، وتظهر لك أدوات المطور أيها الغالب.
حمّل عنصر LCP مبكرا
الفشل الأشيع: اكتشاف الصورة الرئيسية متأخرا. إن كانت صورة خلفية CSS أو محقونة بجافاسكريبت، فلا يستطيع المتصفح بدء تنزيلها حتى يحلل CSS أو يشغل السكربت. الإصلاحات:
- استخدم وسم
<img>عاديا في HTML بدل خلفية CSS حيث أمكن - أضف
fetchpriority="high"للصورة الرئيسية - حملها مسبقا:
<link rel="preload" as="image" href="hero.webp"> - لا تؤجل تحميل صورة LCP أبدا. وضع
loading="lazy"على الصور أعلى الصفحة من أكثر جروح LCP الذاتية شيوعا على الويب.
قلص الصورة نفسها
قدم الصيغ الحديثة (WebP أو AVIF توفران 30 إلى 60 بالمئة مقارنة بـ JPEG)، وحجّم الصور لأبعادها المعروضة عبر srcset، واضغط بجودة 75 إلى 85، فهي لا تُفرَّق بصريا عن 100 في الصور الفوتوغرافية.
اخفض زمن استجابة الخادم
لا يمكن للصورة أن تبدأ قبل وصول HTML. إن تجاوز زمن أول بايت لديك 800 ميلي ثانية، فانظر في التخزين المؤقت (شبكة CDN أمام الموقع، تخزين الصفحات في نظام إدارة المحتوى) قبل أي شيء آخر. في ووردبريس تحديدا، إضافة تخزين مؤقت تحسن LCP عادة أكثر من أي عمل على الصور.
أوقف الموارد الحاجبة للعرض
كل ملف أنماط في الرأس يحجب العرض حتى يُنزل. ادمج وصغر ملفات CSS بأداة مثل مصغر CSS لدينا، وضمّن القدر الصغير من CSS اللازم لمحتوى أعلى الصفحة، وحمل الباقي لاحقا. أما جافاسكريبت فأضف defer للسكربتات التي لا تحتاج التشغيل قبل العرض، وهي كلها تقريبا.
إصلاح INP
فشل INP يعني أن الخيط الرئيسي مشغول لحظة تفاعل المستخدم. لا يستطيع المتصفح فعل أكثر من شيء واحد في الخيط الرئيسي؛ إن كان يشغل مهمة جافاسكريبت مدتها 400 ميلي ثانية حين ينقر شخص زرا، فتلك النقرة تنتظر.
اعثر على المهام الطويلة وقسمها
في لوحة الأداء بأدوات المطور، سجل تفاعلا وابحث عن "المهام الطويلة" المعلمة بالأحمر فوق 50 ميلي ثانية. الحل تقسيم كتل العمل المتزامنة الكبيرة إلى قطع أصغر مع إفساح المجال للمتصفح بينها ليعالج الإدخال. يمكن للكود الحديث استخدام scheduler.yield() أو تقطيع setTimeout؛ وأطر العمل تفعل ذلك تلقائيا بشكل متزايد إن اتبعت أنماطها الموصى بها.
قلل جافاسكريبت المشحونة
أرخص مهمة تُحسَّن هي مهمة تُحذف. دقق حزمك: سكربتات الأطراف الثالثة (التحليلات، ودردشة الدعم، وأدوات اختبار A/B، وتضمينات الشبكات الاجتماعية) هي عادة أسوأ مخربي INP، وكل منها يستحق سؤال "هل يستحق ما يكلفه؟" حمل ما لا مفر منه بـ defer أو بعد أول تفاعل. وصغر الباقي عبر مصغر JS لدينا؛ فالملفات الأصغر تُحلل أسرع أيضا.
تجنب إعادة رسم العالم مع كل ضغطة مفتاح
قاتل INP الكلاسيكي: حقل بحث يرشح قائمة من 2000 صف بشكل متزامن مع كل ضغطة. أخّر المعالجة (انتظر 150 إلى 300 ميلي ثانية بعد توقف الكتابة)، واعرض القوائم الطويلة افتراضيا، وأبق تحديثات الحالة محصورة في المكون الذي يحتاجها.
إصلاح CLS
لإزاحة التصميم قائمة أسباب قصيرة، وكلها قابلة للإصلاح من المصدر.
أعط الصور والتضمينات أبعادا
وسم <img> بلا خاصيتي العرض والارتفاع يكون ارتفاعه صفرا حتى يصل الملف، ثم يدفع كل ما تحته للأسفل. حدد width وheight صراحة (يحجز المتصفح المساحة بنسبتهما) أو استخدم خاصية aspect-ratio في CSS. الأمر نفسه للفيديوهات وإطارات iframe وخانات الإعلانات: احجز مساحتها مسبقا بارتفاع أدنى حتى لو لم يملأها الإعلان.
تعامل مع خطوط الويب بحذر
عند تحميل خط مخصص، يعاد قياس النص المعروض بالخط الاحتياطي وقد يعيد تدفق الصفحة كلها. استخدم font-display: swap مع خط احتياطي معدل القياسات، وحمل مسبقا ملف الخط أو الملفين المستخدمين أعلى الصفحة. والأفضل أن تسأل: هل تكفيك حزمة خطوط النظام؟ فهي صفر بايتات وصفر إزاحة.
لا تدرج محتوى فوق محتوى قائم أبدا
اللافتات وإشعارات الكوكيز وأشرطة "ثبت التطبيق" التي تدفع الصفحة للأسفل بعد التحميل هي CLS خالص. احجز مساحتها في التصميم الأولي، أو اعرضها طافية فلا تزيح المحتوى.
حرك بـ transform لا بخصائص التخطيط
تحريك height أو top أو margin يشغل التخطيط ويحسب إزاحة. تحريك transform وopacity لا يفعل. هذا التغيير الواحد يصلح معظم CLS المرتبط بالحركة.
ترتيب أولويات واقعي
إن كان موقعك يفشل في كل شيء ووقتك محدود، فهذا التسلسل يمنحك أكبر تحسن لكل ساعة:
- فعل تخزين الصفحات أو ضع CDN أمام الموقع. يحسن LCP في كل مكان دفعة واحدة.
- أصلح الصورة الرئيسية: صيغة مناسبة، حجم صحيح،
fetchpriority="high"، وبلا تأجيل أبدا. - أضف العرض والارتفاع لكل صورة. يصلح عادة معظم CLS بجولة واحدة.
- أضف
deferلكل سكربت يقبله واحذف سكربتات الأطراف الثالثة التي لا تستطيع تبريرها. - صغر ووحد CSS و JS. أدوات مصغر HTML ومصغر CSS ومصغر JS لدينا تتولى العمل على مستوى الملفات.
- أصلح الخطوط:
font-display: swapوالتحميل المسبق، أو انتقل لخطوط النظام. - عندها فقط تعمق في تحليل المهام الطويلة لأجل INP، وهو الإصلاح الأكثر التهاما لجهد الهندسة.
التحقق من الإصلاح
بعد نشر التغييرات، اختبر مخبريا فورا لتتأكد أن الميكانيكا تحسنت، لكن تذكر أن البيانات الميدانية نافذة متدحرجة من 28 يوما. سيستغرق تقرير Search Console حتى شهر ليعكس إصلاحاتك كاملة، وتنتقل الصفحات من "ضعيف" إلى "يحتاج تحسينا" إلى "جيد" مع تقدم النافذة. لا تتراجع مذعورا بعد أسبوع لأن اللوحة لم تتحرك.
وواصل المراقبة بعد النجاح. سكربت تسويقي جديد أو صورة رئيسية معاد تصميمها أو لافتة واحدة بلا أبعاد قد تمحو بهدوء أشهرا من العمل. تضيف بعض الفرق ميزانية أداء إلى خط الدمج المستمر تفشل البناء إن تجاوزت أحجام الحزم أو نتائج Lighthouse حدا معينا. وحتى فحص يدوي شهري لقوالبك الرئيسية يمنع معظم الانتكاسات.
نظرة أخيرة
مؤشرات أداء الويب وسيلة لا غاية. تجاوز العتبات يهم لخانة الترتيب، لكن الجائزة الفعلية موقع يشعر مستخدمه بأنه فوري، ويكافئ المستخدمون ذلك بمعدلات ارتداد أدنى وتحويلات أعلى من كل مصادر الزيارات لا من جوجل وحدها. قس بالبيانات الميدانية، وأصلح أكبر مخالف أولا، وتحقق، وحافظ على الانضباط بعد النجاح.