بيانات الميدان هي الدرجة الوحيدة التي تُحتسب
Lighthouse يعمل على هاتف متوسط محاكى وعلى اتصال مخنوق داخل مركز بيانات. مستخدموك ليسوا كذلك. جوجل ترتّب بناءً على CrUX — جلسات حقيقية، ونافذة متحرّكة مدتها 28 يومًا، وتُحتسب عند النسبة المئوية 75 — لذا فمطاردة رقم مختبري قد تترك المؤشّر الذي يهمّ دون تغيير. ثبّت مكتبة web-vitals وأرسل LCP وINP وCLS إلى تحليلاتك الخاصة مع إرفاق قالب الصفحة، لتتمكّن من رؤية أن صفحة الأسعار تجتاز وصفحة نتائج البحث لا تجتاز. تعامل مع أدوات المختبر كمُنقِّح أخطاء لا كلوحة نتائج: فهي تخبرك لماذا كانت عملية تحميل بعينها بطيئة، وهي ممتازة في ذلك. فقط لا تقدّم أبدًا درجة Lighthouse إلى صاحب مصلحة كدليل على أن المستخدمين الحقيقيين يعيشون تجربة جيدة.
LCP دائمًا تقريبًا صورة واحدة أو خط واحد
لـ Largest Contentful Paint ميزانية 2.5 ثانية عند النسبة المئوية 75، وبحسب خبرتنا هناك أربعة أسباب تفسّر معظم حالات الإخفاق. أولًا، صورة الواجهة محمّلة تحميلًا كسولًا — فالمتصفح لن يبدأ جلبها أصلًا قبل تنفيذ التخطيط. اضبط عليها fetchpriority="high" واحذف loading="lazy"؛ وفي Next.js هذا هو خاصية priority. ثانيًا، الصورة ملف PNG بحجم 900KB بينما يجب أن تكون AVIF بحجم 60KB وبالأبعاد الصحيحة. ثالثًا، خط ويب يحجب العرض ويؤخّر رسم النص: استضِفه ذاتيًا، وحمّل مسبقًا الوزن الواحد الظاهر أعلى الصفحة، واستخدم font-display: swap مع خط احتياطي مطابق في المقاييس حتى لا يكلّفك التبديل CLS أيضًا. رابعًا، استجابة خادم بطيئة — إذا تجاوز زمن أول بايت 600ms فلن ينقذك أي عمل في الواجهة الأمامية. أصلح ذلك أولًا.
INP مشكلة JavaScript يمكنك قياسها
حلّ Interaction to Next Paint محلّ First Input Delay في مارس 2024، وهو اختبار أصعب بكثير: يقيس كل تفاعل عبر الزيارة كاملة لا الأول فقط، والميزانية 200ms. المهام الطويلة على الخيط الرئيسي هي السبب، وفي مواقع React تكون الترطيب (hydration) عادةً أكبرها. أرسل JavaScript أقل إلى العميل — مكوّنات الخادم أو نمط الجزر أو التحسين التدريجي البسيط، كلها تنجح، وإطار العمل أقلّ أهمية من عدد البايتات. جزّئ أي عمل يتجاوز 50ms باستخدام scheduler.yield أو بتسليم التحكّم إلى حلقة الأحداث. وانتبه للقَتَلة المحدّدين: معالج onChange ثقيل يرشّح قائمة كبيرة مع كل ضغطة مفتاح، وسكربت تحليلات يعمل تزامنيًا داخل معالج نقرة، ومديرو الوسوم من طرف ثالث الذين يصفّون كودًا اعتباطيًا لموردين. طبّق debounce، أو أجّل إلى worker، أو احذف المورّد.
CLS رخيص، وبعض النصائح مبالَغ في قيمتها
Cumulative Layout Shift هو الأسهل بين الثلاثة في تحقيق 0.1: ضع خاصيتَي width وheight على كل صورة وفيديو، واحجز مساحة لمواضع الإعلانات واللافتات والتضمينات باستخدام min-height، ولا تُدرج محتوى فوق محتوى قائم بعد التحميل أبدًا — لافتة ملفات ارتباط أو شريط ترويجي يدفع الصفحة للأسفل هو فشل كلاسيكي بيدك أنت. والآن قائمة المبالَغ فيها. تضمين CSS الحرج عمل شائك، ينكسر عند إعادة التصميم، ونادرًا ما يتفوّق على إرسال CSS أقل ببساطة. والتحميل المسبق لعشرات الموارد يجعل كل شيء يتنافس ويبطّئ LCP عادةً. وتحسين حجم الحزمة تحسينًا دقيقًا إلى ما دون 100KB مضغوطة تقريبًا أثره أقلّ بكثير من حذف سكربت طرف ثالث حاجب واحد. ودرجة 100 كاملة في Lighthouse على صفحة تخفق في CrUX ليست نتيجة — إنها نتيجة سلبية كاذبة دفعت ثمنها.