حلّ INP (زمن استجابة الصفحة لتفاعل المستخدم) محلّ FID قبل أكثر من عام، ولا تزال معظم الفرق الهندسية بلا خطة عمل فعلية للتعامل معه. إليك ما نوصي به في كل مشروع نطلقه.
ابدأ بالميزانية. نتعامل مع 2.0s في LCP (سرعة ظهور أكبر عنصر في الصفحة)، و0.05 في CLS (مقدار اهتزاز عناصر الصفحة أثناء التحميل)، و200ms في INP بوصفها بوابات صارمة. وإذا أخفقت صفحة في أي منها في اختبارات المعمل، لا يُدمج الـ PR. هذه ليست أمنية معلّقة على الجدار — إنها فحص داخل الـ CI.
في LCP، الرافعة الأكبر بلا منازع هي صورة الواجهة. استخدم AVIF، وحدّد الأبعاد صراحةً، وعلّمها بـ `priority`، واخدمها من CDN بإعدادات تخزين مؤقت سليمة. وإن كانت الواجهة نصية فحسب، فاعرضها من الخادم وانتهى الأمر.
في CLS، ثبّت الأبعاد على كل صورة وفيديو وعنصر مضمّن. واحجز مساحة للإعلانات وللوحدات المحمّلة بالتأجيل. ولا تُدخل خطوطًا تتبدّل في منتصف العرض ما لم تكن قد ضبطت مقاس الخط البديل ليطابقها.
في INP، المسألة أقل ارتباطًا بالسرعة المطلقة وأكثر ارتباطًا بالمهام الطويلة التي تحجب الخيط الرئيسي. دقّق في حزمتك البرمجية. جزّئ المكوّنات الثقيلة. أجّل مكتبات الحركة إلى حين الحاجة إليها. وانقل المنطق كثيف المعالجة إلى worker إن أمكن.
قِس على أجهزة حقيقية. أرقام المعمل وأرقام الميدان تحكيان قصتين مختلفتين — يجب أن يكون Chrome User Experience Report مرجعك الحقيقي، لا تشغيلة Lighthouse على جهازك.
بقلم فريق brainiac/studio. ننشر أعمالًا أصلية يكتبها المهندسون والمصممون والمسوّقون الذين ينفّذون العمل بأنفسهم — ولا نُسندها أبدًا إلى مصنع محتوى.