ما هي مقاييس LCP وINP وCLS لأداء المواقع؟

Core Web Vitals هي القياسات الثلاثة التي تقدّمها Google لتجربة الصفحة. LCP يراقب التحميل، وINP الاستجابة للتفاعل، وCLS الانزياح البصري. أهداف التجربة الجيدة موضوعة لمعظم الزيارات. يكتبها web.dev كنسبة 75 من تحميلات الصفحة. يُقرأ الجوّال وسطح المكتب منفصلين. فتح الصفحة مرة ورؤيتها سريعة ليس بلوغ تلك النسبة.

في صفحة Web Vitals المحدَّثة في 31 أكتوبر 2024، LCP وCLS قياسان مستقران. صار INP القياس المستقر في 2024، وحلّ محل First Input Delay. القياس المستقر لا يُغيَّر أكثر من مرة في السنة. وهو ليس مضطرًا أن يبقى دائمًا. هذه الأرقام الثلاثة لا تقول هل النص صحيح. زمن التحميل الجيد لا يصلح صفحة مشوّشة. وهذه المقالة لا تعد بترتيب أيضًا.

LCP هو الزمن من بدء الزائر تحميل الصفحة حتى يُرسم أكبر صورة أو كتلة نص في المساحة الظاهرة. في كثير من الصفحات هذا العنصر هو صورة الغلاف. إصلاح الزمن بمفتاح واحد نادرًا ما يكفي. يوصي web.dev بالنظر معًا إلى مستند HTML الأول والملف الذي يستخدمه عنصر LCP.

بطء زمن البايت الأول، TTFB، يعني أن الخادم يتأخر في إرسال HTML. التحويلات، أو بعد الزائر عن الخادم، أو ذاكرة مؤقتة لا تُستخدم، قد تطيل ذلك. فاصل طويل بين TTFB وأول محتوى قد يُظهر أن المتصفح ينزّل ملفات كثيرة قبل الرسم، أو أن المحتوى يُبنى بجافاسكربت. فاصل طويل بين أول محتوى وLCP يوحي أن الصورة الأساسية ليست جاهزة في HTML، وأن نصًا برمجيًا يطلبها لاحقًا.

وضع loading="lazy" على صورة LCP يؤخر التحميل عمدًا. يقول web.dev ألا تُحمَّل صورة LCP تحميلًا كسولًا أبدًا. إن كانت الصورة في HTML، يمكن منحها أولوية بـ fetchpriority="high". منح هذه الأولوية لصور كثيرة يوقف الفائدة. في PageSpeed Insights انظر أولًا إلى بيانات المستخدم الحقيقي، قسم CrUX. قسم المختبر للتشخيص حين يشير إلى الجهة نفسها التي تشير إليها بيانات الميدان. إن لم يكن للعنوان بيانات خاصة به، فقد تعرض الأداة بيانات الموقع كله. الصفحة الرئيسية وصفحة داخلية ليستا مضطرتين إلى LCP واحد.

يراقب INP التفاعلات المؤهلة طوال الزيارة، ويكتب أطولها، مع استبعاد القيم الشاذة أحياناً عندما تكثر التفاعلات. للتجربة الجيدة 200 ميلي ثانية أو أقل. لا يستطيع Lighthouse أخذ هذا القياس في اختبار بلا إدخال من المستخدم. في المختبر يستخدم زمن الحجب الكلي مكانه. تحسّن المختبر قد يحسّن INP في الميدان. لا يحلّ محله.

ينقسم التفاعل إلى ثلاثة أجزاء. يبدأ التأخير حين ينقر الزائر ويستمر حتى يبدأ التعامل مع الحدث. المعالجة هي مدة تشغيل الرمز الذي يجيب عن النقرة. العرض هو الزمن بعد انتهاء ذلك الرمز حتى يرسم المتصفح الإطار التالي. تصغير الرمز قبل معرفة أي جزء هو الطويل تخمين.

CLS هو تحرّك المحتوى الظاهر حين لم يكن ذلك متوقعًا. الأسباب التي يكتبها web.dev كثيرًا هي الصور بلا أبعاد، والإعلانات والمحتوى المضمّن الذي يصل متأخرًا، والرسوم التي تكسر التخطيط، وتغيّر الخط.

ترك العرض والارتفاع عن صورة أو فيديو يؤجل المكان حتى يكتمل تنزيل الملف. جعل العرض مئة في المئة في CSS والارتفاع تلقائيًا يترك الفجوة نفسها. width وheight، أو aspect-ratio، يفتحان المكان مسبقًا. الإعلانات والخرائط وتضمين الفيديو والشريط الذي يُضاف لاحقًا قد تدفع الصفحة بالطريقة نفسها. احجز مكانًا للمحتوى المتأخر بـ min-height أو aspect-ratio. إغلاق ذلك المكان حين لا يصل إعلان يُنتج انزياحًا بقدر دفع المحتوى لاحقًا. إن تعذّر حجز المكان، فوضع المحتوى المتأخر أسفل الصفحة يقلل الأثر.

رسم يستخدم top وleft يزيح التخطيط. نقل يُعمل بـ transform لا يُكتب في CLS. حين يصل خط الويب ويحل محل الخط الاحتياطي تتحرك الأسطر أيضًا. ينبغي أن يأتي الخط الاحتياطي من عائلة قريبة من الخط النهائي. font-display: optional طريق يمكن أن يُبقي الخط من التغيير إن لم يكن جاهزًا قبل التخطيط الأول.

الانزياح خلال 500 ميلي ثانية من تحميل بدأه الزائر لا يُكتب في CLS. زر مثل تحميل مزيد من المنتجات يختلف، لهذا السبب، عن شريط يهبط من الأعلى بلا تنبيه.

أعلى PageSpeed Insights بيانات من مستخدمي Chrome الحقيقيين. أسفله المختبر. حين يفترقان، بيانات الميدان تصف التجربة. المختبر لرؤية السبب. قياس مستخدمين حقيقيين خاص بك يملأ تفصيل الصفحة الذي لا يعطيه CrUX. القيمة التي تُقرأ بجافاسكربت ليست مضطرة أن تطابق تقرير CrUX.

هذه القياسات لا تغيّر ما تقوله الصفحة. النص والنموذج والعرض تبقى داخل الموقع والبرمجيات.