كيف تحسّن مؤشرات أداء الويب الأساسية (Core Web Vitals): دليل عملي لـ LCP و INP و CLS

مؤشرات أداء الويب الأساسية (Core Web Vitals) ثلاثة قياسات تستخدمها Google لوصف تجربة تحميل الصفحة واستخدامها: سرعة ظهور المحتوى الرئيسي، وسرعة استجابة الصفحة حين يتفاعل معها أحد، ومقدار تقافز التخطيط. وهي جزء من طريقة تقييم Google لتجربة الصفحة، وإن كان المحتوى المفيد ذو الصلة أهم بكثير في الترتيب. وهي قبل كل شيء مؤشر جيد على ما إذا كان موقعك يبدو سريعًا.

المقاييس الثلاثة وما يُعدّ جيدًا

• Largest Contentful Paint (LCP): اللحظة التي يكتمل فيها عرض أكبر صورة أو كتلة نص في منفذ العرض. الجيد: 2.5 ثانية أو أقل؛ الضعيف: أكثر من 4 ثوانٍ.
• Interaction to Next Paint (INP): المدة التي تحتاج إليها الصفحة لتستجيب استجابة مرئية للنقرات واللمسات وضغطات المفاتيح، على امتداد الزيارة كلها. الجيد: 200 مللي ثانية أو أقل؛ الضعيف: أكثر من 500 مللي ثانية. وقد حلّ INP محل First Input Delay ضمن مؤشرات أداء الويب الأساسية في مارس 2024.
• Cumulative Layout Shift (CLS): مقدار تحرّك المحتوى المرئي على نحو غير متوقَّع. الجيد: 0.1 أو أقل؛ الضعيف: أكثر من 0.25.

تنجح الصفحة حين تستوفي 75% من مرات تحميلها (المئين 75) الحدّ «الجيد» لكل مقياس، ويُقاس ذلك للجوال ولسطح المكتب كلٌّ على حدة. ومعنى هذا أن الربع الأبطأ من زوّارك لا يُحسب عليك، أما الزائر المعتاد على هاتف متوسط فيُحسب.

البيانات المختبرية مقابل البيانات الميدانية

البيانات الميدانية تأتي من زوّار حقيقيين. يجمعها تقرير Chrome UX Report من Google من مستخدمي Chrome الذين وافقوا على ذلك، على امتداد نافذة متحركة من 28 يومًا، وهي ما يعرضه تقرير «مؤشرات أداء الويب الأساسية» في Search Console وأعلى صفحة PageSpeed Insights. إنها البيانات المعتبَرة، لكنها تحتاج إلى زيارات كافية وتتغيّر ببطء.

البيانات المختبرية تأتي من تحميل الصفحة مرة واحدة في ظروف مضبوطة، كما يفعل Lighthouse. وهي متاحة فورًا لأي صفحة وتبيّن لك لماذا كان المقياس بطيئًا، وهذا ما يجعلها أداة التشخيص. لكن تشغيلًا مختبريًا واحدًا على هاتف محاكى لن يطابق أجهزة زوّارك وشبكاتهم الحقيقية، والاختبار المختبري لا يستطيع قياس INP إطلاقًا، لأن أحدًا لا يتفاعل مع الصفحة. و Total Blocking Time (TBT)، أي المدة التي يكون فيها الخيط الرئيسي مشغولًا عن الاستجابة في أثناء التحميل، هو أقرب إشارة مختبرية إليه.

استخدم الاثنين: البيانات الميدانية لتعرف هل لديك مشكلة وهل نجح إصلاحك؛ والبيانات المختبرية لتعثر على السبب. ولجمع بياناتك الميدانية بنفسك، ترسل مكتبة JavaScript المفتوحة المصدر web-vitals المقاييس الثلاثة من الزيارات الحقيقية إلى تحليلاتك.

تحسين LCP

ينقسم زمن LCP إلى أربعة أجزاء: زمن وصول البايت الأول، والتأخير قبل أن يبدأ المتصفح بتحميل مورد LCP، وزمن تنزيله، والتأخير قبل عرضه. اعرف أيّ الأجزاء كبير، ثم:

• سرِّع استجابة الخادم بالتخزين المؤقت للصفحات وشبكة CDN، لتصل شيفرة HTML سريعًا.
• اجعل صورة LCP قابلة للاكتشاف مبكرًا: استخدم <img> عاديًّا في HTML بدلًا من خلفية CSS أو صورة تُحقن عبر JavaScript، ولا تضع عليها loading="lazy" أبدًا.
• أعطِها الأولوية: أضف fetchpriority="high" إلى صورة LCP، أو حمّلها مسبقًا إن كانت الإشارة إليها تأتي متأخرة.
• صغِّرها: قدّمها بمقاس عرضها وبصيغة WebP أو AVIF؛ راجع كيف تقلّل حجم الصور.
• أزل الموارد المعيقة للعرض: ضمِّن CSS الحرج داخل الصفحة، وأجّل السكربتات غير الأساسية، وتجنّب عرضًا ثقيلًا من جهة العميل قبل ظهور المحتوى الرئيسي.

تحسين INP

يسوء INP حين يكون الخيط الرئيسي في المتصفح مشغولًا، بتشغيل JavaScript في العادة، لحظة تفاعل المستخدم، أو حين يطول رسم نتيجة العمل الذي أطلقه التفاعل.

• أرسل JavaScript أقل. أزل المكتبات والإضافات غير المستخدمة، وقسّم الحزم، ولا تُجرِ الترطيب (hydration) لأجزاء من الصفحة لا تحتاج إلى أن تكون تفاعلية.
• فتّت المهام الطويلة. قسّم كل عمل يتجاوز 50 مللي ثانية إلى أجزاء أصغر وأفسح المجال للمتصفح بينها، عبر setTimeout أو scheduler.yield() حيث يكون مدعومًا.
• اختصر ما تفعله معالجات الأحداث. حدّث الواجهة أولًا ثم نفّذ العمل المكلف؛ وطبّق تأخير الارتداد (debounce) على معالجات الإدخال.
• راجع سكربتات الأطراف الخارجية. أدوات المحادثة ومديرو الوسوم وأدوات اختبار A/B تشغّل في الغالب شيفرة ثقيلة عند كل تفاعل. حمّلها لاحقًا، أو عند الحاجة فقط.
• أبقِ DOM بحجم معقول، لأن شجرة DOM الكبيرة تبطّئ كل إعادة عرض.

تحسين CLS

• حدّد أبعاد الصور والفيديو بخاصيتَي width و height أو بـ aspect-ratio في CSS، لتُحجز المساحة قبل تحميلها.
• احجز مساحة للإعلانات والمحتويات المضمَّنة والشرائط. أعطِ حاوياتها ارتفاعًا أدنى، ولا تُدرج محتوى فوق ما يقرؤه الزائر الآن.
• روِّض خطوط الويب. استخدم font-display: swap أو optional، وحمّل الخطوط الأساسية مسبقًا، واستخدم خطًّا احتياطيًا بمقاييس مطابقة (size-adjust) لتقليل الإزاحة عند وصول خط الويب.
• حرِّك العناصر عبر transform، لا عبر خصائص مثل top أو height التي تحرّك المحتوى المحيط.
• دع ذاكرة التخزين المؤقت للرجوع والتقدّم (back/forward cache) تعمل، وتجنّب معالجات unload، لتُستعاد الزيارات العائدة فورًا بلا إزاحات.

أين موقع Rudra من ذلك

يُجري فاحص سرعة الموقع المجاني اختبارًا مختبريًا واحدًا عبر Lighthouse بمحاكاته الافتراضية للجوال. ويُعرض كل مقياس مع قيمته المَقيسة، موسومًا بأنه قياس مختبري من تشغيل واحد، ومقارَنًا بالحدود المنشورة: LCP عند 2.5 ث / 4 ث، و CLS عند 0.1 / 0.25، و TBT عند 200 / 600 مللي ثانية. والفحوص المخفقة تسرد ما يصل إلى خمسة من الملفات أو العناصر المسؤولة، مع الوفر التقديري، لتعرف من أين تبدأ. وهو لا يقيس INP ولا يتضمن بيانات ميدانية؛ تحقق منهما في Search Console أو PageSpeed Insights. ولمعرفة أسباب بطء الصفحة عمومًا راجع لماذا موقعي بطيء.

طريقة عمل مجدية

1. راجع تقرير «مؤشرات أداء الويب الأساسية» في Search Console لتعرف أيّ مقياس يخفق وفي أي مجموعة من الصفحات.
2. اختر صفحة ممثِّلة من تلك المجموعة وأجرِ عليها اختبارًا مختبريًا عدة مرات.
3. أصلح أكبر سبب أولًا، وانشر التغيير، وأعد الاختبار في المختبر.
4. انتظر تحديث البيانات الميدانية (فهي نافذة من 28 يومًا) قبل أن تحكم على النتيجة.