الخلاصة: تُحمَّل الصفحة بالسرعة الكافية حين تجتاز مؤشرات Core Web Vitals الثلاثة عند النسبة الخامسة والسبعين من الزوار الحقيقيين: LCP أقل من 2.5 ثانية، وINP أقل من 200 مللي ثانية، وCLS أقل من 0.1. تقيّم جوجل هذه من بيانات كروم الحقيقية عبر نافذة 28 يوماً لا من اختبار معملي، وتعايرها حول الموبايل متوسط الأداء، فيكون تقرير الموبايل هو الأضعف دائماً تقريباً. حلّ INP محل FID في مارس 2024 وهو المقياس الذي تفشل فيه معظم المواقع الآن. أصلح LCP بتسليم أسرع وصور أخف، وINP بجافاسكربت أخف، وCLS بأبعاد صريحة.
ماذا تعني "تُحمَّل بسرعة" فعلاً؟
تعني اجتياز Core Web Vitals: ثلاثة مقاييس تقيس بها جوجل التجربة الحقيقية. أكبر عنصر مرئي (LCP) يقيس التحميل بعتبة جيدة أقل من 2.5 ثانية. والتفاعل مع الرسم التالي (INP) يقيس الاستجابة، جيد أقل من 200 مللي ثانية. والإزاحة التراكمية للتخطيط (CLS) تقيس الاستقرار البصري، جيدة أقل من 0.1. ولا تجتاز الصفحة إلا حين تبلغ 75% من الزيارات الحقيقية العتبة الجيدة في الثلاثة جميعاً.
هذا الفحص الثاني عشر في قائمة السيو للذكاء الاصطناعي، وأول فحوصات الفحص التقني قبل الإقلاع الستة. الصفحة التي تفشل فيه تخسر الزوار قبل أن يُحمَّل محتواك أصلاً، والزائر الذي يغادر اقتباس لا يحصل عليه المحرك أبداً.
لماذا تختلف بيانات الميدان عن نتيجة المعمل؟
لأن جوجل تقيّمك على المستخدمين الحقيقيين لا على اختبارك. مؤشرات Core Web Vitals التي تُحتسب تأتي من تقرير تجربة مستخدمي كروم (CrUX): زيارات فعلية من أجهزة حقيقية، مجمّعة عند النسبة الخامسة والسبعين عبر نافذة متحركة مدتها 28 يوماً. النتيجة المثالية في Lighthouse نتيجة معملية على جهاز واحد ولا تثبت شيئاً عن الميدان.
وتوثيق تقرير Core Web Vitals من جوجل يؤكد الآلية: يقيّم كل مقياس عند النسبة الخامسة والسبعين ويصنّف مجموعة الروابط على مستوى أسوأ مقاييسها، فـCLS ضعيف مع LCP جيد يبقي الصفحة ضعيفة. ويترتب على ذلك أمران. التغييرات تظهر بعد نحو 28 يوماً لأن النافذة متحركة، فالإصلاح المنشور اليوم لن يحرك التقرير فوراً. والعتبات معايَرة حول الموبايل متوسط الأداء، ولهذا قد تبدو الصفحة نفسها فورية على حاسوبك وتفشل مع ذلك في الميدان.
كيف تصلح LCP؟
LCP عادة مشكلة صورة وتسليم. أكبر عنصر فوق الطية، غالباً الصورة البطلة أو كتلة نص كبيرة، عليه أن يُرسَم خلال 2.5 ثانية، وأربعة إصلاحات تحركه أكثر:
- حمّل صورة LCP مسبقاً بتلميح preload بأولوية جلب عالية حتى يجلبها المتصفح مبكراً بدلاً من اكتشافها متأخراً.
- قدّم صيغاً حديثة (WebP وAVIF) عبر CDN، فتقلل الوزن والتأخر الجغرافي الذي يضخّم زمن التحميل.
- قلّل زمن استجابة الخادم (TTFB): استضافة أسرع، وتخزين مؤقت، وعدد أقل من عمليات إعادة التوجيه قبل أن تبدأ الصفحة بالرسم.
- ضمّن CSS الحرج وحمّل الخطوط مسبقاً حتى لا يتوقف الرسم منتظراً أوراق الأنماط أو خطوط الويب.
أشهر خطأ في LCP هو التحميل المؤجل للصورة البطلة. تأجيل أكبر صورة فوق الطية يؤخر العنصر نفسه الذي يقيسه LCP، فالتحميل المؤجل لما تحت الطية فقط.
كيف تصلح INP، المقياس الذي تفشل فيه معظم المواقع؟
INP مشكلة جافاسكربت. يقيس زمن استجابة كل تفاعل عبر الزيارة كلها لا الأول فقط، ولهذا حلّ محل مقياس تأخر أول إدخال في مارس 2024، ولهذا صار أكثر مؤشرات Core Web Vitals فشلاً. حين ينتظر نقر أو لمس انتهاء الخيط الرئيسي من مهمة طويلة، يرتفع INP. والإصلاحات بنيوية: قسّم مهام الجافاسكربت الطويلة إلى أجزاء أصغر، وأجّل النصوص غير الحرجة، وأفسح للخيط الرئيسي أثناء التفاعلات، وقلّل تعقيد DOM حتى يعالج المتصفح أقل. والنصوص الخارجية وروبوتات المحادثة والتحليلات الثقيلة مذنبون متكررون، لأنها تعمل على الخيط الرئيسي نفسه الذي تحتاجه أزرارك.
كيف تصلح CLS؟
CLS مشكلة مساحة محجوزة. تحدث الإزاحة حين يُحمَّل شيء فيدفع محتوى كان موجوداً، والإصلاح حجز المساحة مسبقاً. امنح كل صورة وفيديو وإطار مضمّن ومساحة إعلان أبعاداً صريحة حتى يحفظ المتصفح المساحة قبل وصول الأصل. واستخدم font-display swap وخطوطاً بديلة متطابقة حتى لا يتدفق النص عند تحميل خط الويب. واحجز مساحة لأي شيء يُحقن متأخراً، كلافتات الكوكيز أو الإعلانات الديناميكية، بدلاً من تركه يدفع الصفحة للأسفل. ولأن CLS درجة لا زمن، فإعلان واحد متأخر التحميل قادر على إفشال صفحة مستقرة في كل ما عداه.
أي مقياس تصلح أولاً؟
| الأولوية | المقياس | السبب الجذري | الإصلاح الأساسي |
|---|---|---|---|
| 1 | أي مقياس "ضعيف" | أسوأ نطاق يجرّ الدرجة كلها | أصلح المقياس الأحمر أولاً |
| 2 | INP | جافاسكربت ثقيل على الخيط الرئيسي | قسّم المهام وأجّل النصوص |
| 3 | LCP | تسليم بطيء وصورة بطلة ثقيلة | تحميل مسبق وصيغ حديثة وTTFB أسرع |
| 4 | CLS | مساحة غير محجوزة | أبعاد صريحة في كل مكان |
لا تحسّن مقياساً أخضر أصلاً. أصلح ما يقع في النطاق الضعيف أولاً، ثم INP (الأصعب والأكثر فشلاً)، ثم LCP (الأعلى أثراً تجارياً)، ثم CLS (الأسهل).
كيف نطبق القاعدة في HBS؟
نفحص Core Web Vitals على بيانات الموبايل الحقيقية، لا مجرد اجتياز Lighthouse، قبل نشر أي صفحة، ونرتّب الأولويات بحسب نطاق بيانات الميدان بدلاً من ملاحقة رقم معملي مثالي. تُعامَل السرعة كمعيار موثوقية تسليم للبحث والتحويل معاً، ولهذا هي أول بوابة في الفحص التقني قبل الإقلاع. وأعمال حلول السيو المتقدمة التي نقدمها تشمل تشخيص القوالب الفاشلة على بيانات الميدان وإعادة بناء المسارات الحرجة للأداء حتى تجتاز الصفحات على الأجهزة الحقيقية وتبقى كذلك.
السرعة هي تذكرة الدخول
لو صفحتك بتفشل في Core Web Vitals على الموبايل، فلا فرصة لأي عمل بنية أو ثقة أو محتوى خلفها أن يهم، لأن الزائر غادر أصلاً. اجتز المقاييس الثلاثة على الأجهزة الحقيقية وأبقِها خضراء طوال نافذة الـ28 يوماً. لو موقعك شكله سريع ليك بس Search Console بيقول غير كده، فريق حلول السيو المتقدمة في HBS يقدر يشخّص فشل بيانات الميدان، ويصلّح أسباب LCP وINP وCLS على مستوى الكود، ويخليها خضراء. اطلب مراجعة مجانية وشوف مستخدمينك الحقيقيين بيخسروا السرعة فين.
