Core Web Vitals في 2026: ما الذي يُحرّك LCP وINP وCLS فعليًا

لا تزال معظم الفرق تتعامل مع Core Web Vitals على أنها رقم في Lighthouse يجب ملاحقته، لا بنية تقنية يجب إصلاحها. لهذا السبب يمكن لموقع أن يحصل على 95 في PageSpeed Insights ومع ذلك يفشل في تقييم Core Web Vitals الخاص به داخل Google Search Console. هذان الرقمان يقيسان أمرين مختلفين، وواحد منهما فقط يؤثر في الترتيب وفي تجربة المستخدمين الفعليين.

سنتجاوز هنا نصائح الإضافات (plugins). فإذا كان حل مشكلة الأداء عندك هو "تثبيت إضافة تخزين مؤقت"، فأنت تعالج عرَضًا لا السبب. فيما يلي ما يُحرّك كل مؤشر فعليًا، ولماذا تختلف بيانات المختبر (lab) عن بيانات الميدان (field) بشكل متكرر لدرجة أنه لا يمكن الوثوق بأحدهما بمفرده.

LCP مشكلة في المسار الحرج، لا مشكلة في الصور

يقيس Largest Contentful Paint اللحظة التي ينتهي فيها عرض أكبر عنصر مرئي في الصفحة — عادةً صورة رئيسية (hero image) أو عنوان أو بانر. تلجأ الفرق افتراضيًا إلى "ضغط الصورة"، وهذا يساعد فعلًا، لكنه نادرًا ما يكون عنق الزجاجة بعد نقطة معينة.

المسار الحرج الحقيقي يبدو كالتالي:

1. زمن الوصول إلى أول بايت (Time to First Byte). إذا كان خادمك أو المصدر (origin) يحتاج بضع مئات من الميلي ثانية للاستجابة قبل أن يملك المتصفح أي شيء يعمل عليه، فلن ينقذك أي قدر من ضغط الصور. يمكن لتقنيات العرض عند الحافة (edge rendering)، والنسخ المتماثلة الإقليمية للقراءة (regional read replicas)، ونقل المسارات الحساسة لزمن TTFB إلى طبقة الحوسبة في شبكة CDN (مثل Cloudflare Workers أو Vercel Edge أو Lambda@Edge)، أن تقلّص هذا الزمن بشكل ملموس — ومقدار التحسن يعتمد بشدة على بنيتك التقنية ومنطقتك الجغرافية ونقطة البداية.
2. ملفات CSS وJS الحاجبة للعرض (render-blocking). كل ورقة أنماط وكل سكربت متزامن يتوجّب على المتصفح تحليله قبل أن يتمكن من الرسم يؤخر LCP. ضع كود CSS الحرج المتعلق بالمحتوى الظاهر أعلى الصفحة (above the fold) مباشرة داخل الصفحة (inline)، وأجّل الباقي.
3. إمكانية اكتشاف الموارد. يحتاج ماسح التحميل المسبق (preload scanner) في المتصفح إلى العثور على صورة LCP الخاصة بك مبكرًا. فإذا كانت هذه الصورة تُحقن عبر JavaScript، أو تُحمّل من خلال خاصية background-image في CSS، أو مخفية خلف طلب بيانات من جهة العميل (client-side fetch)، فأنت بذلك تؤخر اكتشافها بمئات الميلي ثانية. استخدم fetchpriority="high" على وسم <img> الفعلي، إضافةً إلى <link rel="preload"> خاص بها.
4. تحميل الخطوط. إذا كان عنصر LCP لديك نصًا، وتقوم بتحميل خط ويب دون استراتيجية خط احتياطي (fallback)، فأنت تضيف رحلة اتصال كاملة (round-trip) قبل أن يتمكن هذا النص من الظهور. تحل خاصية font-display: swap والتحميل المسبق (preloading) نصفي المشكلة كل على حدة: فـswap يعرض خطًا احتياطيًا فورًا حتى لا تحجب رحلة الاتصال مؤشر LCP (لكنها قد تُحدث إعادة تدفق مرئية للنص — وتضر بمؤشر CLS — عند استبدال الخط الاحتياطي بالخط الحقيقي)، بينما يقلّص التحميل المسبق لملف الخط نفسه زمن الجلب فيحدث الاستبدال بشكل أسرع. استخدم الأسلوبين معًا، لا أحدهما بدلًا من الآخر.

لا شيء من هذا إعداد إضافة (plugin). إنه أمر متعلق بالتوجيه (routing)، وترتيب الترميز (markup)، وتلميحات الموارد (resource hints) — قرارات تُتخذ داخل خط بناء مشروعك (build pipeline) وفي HTML الخاص بك، لا في لوحة تحكم WordPress.

INP هو ما يحدث حين لا تتحمّل بنية JavaScript لديك النمو

حلّ مؤشر Interaction to Next Paint محل First Input Delay كأحد مؤشرات Core Web Vitals في مارس 2024، وهو مؤشر أصعب في التلاعب به لأنه يأخذ عينات من كل تفاعل خلال زيارة الصفحة، لا من أول تفاعل فقط. يمكن لموقع أن تكون أول نقرة فيه سريعة ومع ذلك يفشل في INP، لأن تفاعلًا لاحقًا — بعد أن تكون مكونات كافية قد تم تركيبها (mounted) وتراكمت حالة (state) كافية — يستغرق وقتًا طويلاً في الاستجابة بما يكفي لسحب درجة p75 إلى الأسفل، حتى لو بدت أول نقرة فورية.

يهيمن على مؤشر INP التنافس على الخيط الرئيسي (main thread). لا يستطيع المتصفح الاستجابة للمس أو لضغطة مفتاح ما دام مشغولًا بتشغيل JavaScript. الأسباب المعتادة هي:

• المهام الطويلة (long tasks). أي مهمة تتجاوز 50ms تحجب الخيط الرئيسي عن معالجة المدخلات. تحديثات الحالة الكبيرة، وإعادة العرض (re-renders) غير المُحسّنة، والسكربتات المتزامنة من أطراف ثالثة (أدوات الدردشة، أكواد التحليلات، شبكات الإعلانات) هي الأسباب الأكثر شيوعًا.
• تكلفة الترطيب (hydration). الأطر البرمجية الثقيلة من جهة العميل التي ترطّب (hydrate) الصفحة بأكملها عند التحميل — بدلًا من ترطيبها تدريجيًا أو بشكل انتقائي — تُشغل الخيط الرئيسي بالكامل في اللحظة نفسها التي يبدأ فيها المستخدمون بالتفاعل. تُعد بنية الجزر (islands architecture — ترطيب Astro الانتقائي للمكونات المعزولة) وقابلية الاستئناف (resumability — أسلوب Qwik الذي يسلسل (serializes) حالة التنفيذ ويستأنفها دون إعادة تشغيل منطق المكونات إطلاقًا) تقنيتين مختلفتين تستهدفان هذه المشكلة نفسها، إلى جانب React Server Components. إذا كنت تشغّل تطبيق صفحة واحدة (SPA) مُعرَّض بالكامل من جهة العميل لموقع تسويقي، فغالبًا ما يظهر أثر ذلك في INP أولًا.
• معالجات أحداث غير مُجمَّعة (unbatched). إدخال واحد يُطلق عدة عمليات إعادة عرض متزامنة، أو إعادة حساب للتخطيط (layout)، أو استدعاءات API، يتراكم أثره بسرعة. تساعد تقنية debouncing، واستخدام requestIdleCallback للأعمال غير العاجلة، ونقل الحسابات الثقيلة إلى Web Workers، جميعها في تخفيف هذا التراكم.
• حجم سكربتات الأطراف الثالثة. أدوات إدارة الوسوم (tag managers) التي تُحمّل دزينة من السكربتات التابعة هي من أكبر قاتلي مؤشر INP، لأنك لا تتحكم في تكلفة تنفيذها، بل فقط في ما إذا كانت ستُحمَّل أصلًا ومتى.

يقلّل تقسيم الكود (code splitting) والتحميل الكسول (lazy loading) القائم على المسارات إجمالي JavaScript الذي يُشحن، لكن مؤشر INP تحديدًا يكافئ إبقاء الخيط الرئيسي حرًا خلال نوافذ التفاعل — وهذه مشكلة جدولة بقدر ما هي مشكلة حجم حزمة (bundle size).

CLS لا يزال في معظمه مشكلة انضباط

Cumulative Layout Shift هو أسهل المؤشرات الثلاثة إصلاحًا، وهو الوحيد الذي لا علاقة له ببنية الخادم التحتية. تنشأ مشكلاته عن:

• الصور والعناصر المضمّنة (embeds) بلا خاصيتي width/height صريحتين أو بلا aspect-ratio محجوزة في CSS.
• خطوط الويب التي تستبدل خطًا احتياطيًا ذا أبعاد مختلفة، ما يُحدث إزاحة في تدفق النص — يمكن تخفيف ذلك باستخدام خاصية size-adjust داخل قاعدة @font-face مضبوطة لتطابق خطك الاحتياطي.
• الإعلانات، وبانرات ملفات تعريف الارتباط (cookie banners)، والمحتوى المُحقن ديناميكيًا الذي يدفع المحتوى الموجود إلى الأسفل بعد رسم التخطيط الأولي.
• المحتوى المُدرج فوق محتوى موجود مسبقًا (خطأ شائع في أنظمة إدارة المحتوى/التخصيص — كإضافة بانر أعلى الصفحة بعد اكتمال تحميلها).

تحقيق CLS أقل من 0.1 أمر ممكن على أي بنية تقنية تقريبًا، بمجرد أن يحصل كل عنصر ديناميكي على مساحة محجوزة له. لا يوجد حل بنيوي (infrastructure) لخاصية width مفقودة.

لماذا تختلف درجات المختبر عن بيانات الميدان

هذا هو الجزء الذي تتجاهله معظم التقارير. تعمل بيانات "المختبر" (lab) في Lighthouse وPageSpeed Insights على تحميل واحد للصفحة، على جهاز محاكى من فئة متوسطة، عبر اتصال مُقيَّد السرعة، في حالة ذاكرة تخزين مؤقت نظيفة، دون أي تباين حقيقي بين المستخدمين. إنها قابلة للتكرار، ما يجعلها مفيدة لاختبارات الانحدار (regression testing) — لكنها تبقى لقطة اصطناعية.

أما بيانات الميدان (field) — وهي ما يظهر في تقرير Core Web Vitals داخل Search Console وفي Chrome UX Report (CrUX) — فهي إجمالي متحرك لمدة 28 يومًا عند المئين 75، تُجمع من مستخدمي Chrome الحقيقيين على أجهزة حقيقية وشبكات حقيقية وحالات تخزين مؤقت حقيقية. وهذه هي البيانات التي تستخدمها Google فعليًا كإشارة ترتيب.

تظهر الفجوة بطرق يمكن توقعها:

• تنوع الأجهزة. يعمل اختبار المختبر على جهاز محاكى ثابت. أما بيانات الميدان فتشمل هواتف أندرويد حقيقية منخفضة الأداء تعمل على شبكات 4G، والتي ستظهر دائمًا نتائج INP أسوأ من ملف تعريف متوسط اصطناعي.
• تباين الأطراف الثالثة. اختبارات A/B، ومنصات إدارة الموافقة (consent management)، وأكواد الإعلانات غالبًا لا تعمل بالطريقة نفسها في تشغيلة المختبر (الذي قد لا يقبل ملفات تعريف الارتباط، أو يفعّل تحديد الموقع الجغرافي، أو يُحمّل شبكات إعلانات خاصة بمنطقة معينة) كما تعمل مع الزيارات الحقيقية.
• حالة التخزين المؤقت. غالبًا ما تُجرى اختبارات المختبر في حالة "باردة" (cold). أما المستخدمون الحقيقيون فيصلون إلى ذاكرة التخزين المؤقت لشبكة CDN، وإلى خطوط تم "تسخينها" مسبقًا، وإلى موارد سبق تحميلها في زيارات سابقة — ما قد يجعل أدوات الميدان تُظهر نتائج أفضل من المختبر، عكس النمط المعتاد.
• حجم العينة والمئين. تشغيلة اختبار واحدة في المختبر تعطيك نقطة بيانات واحدة فقط. أما بيانات الميدان عند p75 فتعني أن ربع زياراتك الحقيقية كانت أسوأ من الرقم الذي تراه — وهذا بالضبط هو الطرف (tail) الذي لا تصل إليه أبدًا "الحلول السريعة" القائمة على الإضافات.

تعامل مع بيانات المختبر كبوابة فحص انحدار (regression gate) ضمن CI، لا كبديل عن درجتك الفعلية. وتعامل مع بيانات الميدان بوصفها الحقيقة الأساسية (ground truth) التي أنت مسؤول عنها، وشخّصها باستخدام مراقبة المستخدم الحقيقي (real-user monitoring)، لا بتكرار تشغيل Lighthouse.

ما الذي يجب إعطاؤه الأولوية فعليًا

إذا كنت تُرتّب الأولويات: أصلح CLS أولًا (الأرخص والأكثر يقينًا)، ثم أصلح LCP ثانيًا (تغييرات في البنية التحتية والترميز بأرقام واضحة قبل/بعد)، وتعامل مع INP كهاجس بنيوي مستمر لا كإصلاح لمرة واحدة — فهو يتدهور من جديد في كل مرة تُطلق فيها سكربت طرف ثالث جديدًا أو شجرة مكونات أثقل.

ولهذا السبب أيضًا يجب أن يكون العمل على Core Web Vitals من مسؤولية من يكتبون كودك ويُطلقونه، لا بندًا في قائمة تحقق تسويقية. يتعامل فريق تحسين محركات البحث التقني لدينا مع الأداء بوصفه مشكلة هندسية لها أثر جانبي على الترتيب، لا العكس — لأن هذا هو الترتيب الذي تعمل به الأمور فعليًا.

خلاصة القول: درجات المختبر تخبرك إن كنت قد كسرت شيئًا منذ الأمس. أما بيانات الميدان فتخبرك بما عاشه مستخدموك وGoogle فعليًا. وإذا تعارض هذان الرقمان، صدّق بيانات الميدان — واذهب لإصلاح البنية، لا إعدادات الإضافة.