Core Web Vitals: هل فشل موقعك في التقييم؟ إصلاح LCP وINP وCLS

الجواب المختصر: فشل Core Web Vitals يعني أن مقياسًا واحدًا على الأقل من ثلاثة يتجاوز حدّه لدى الزوار الحقيقيين: ينبغي ألا يزيد LCP (التحميل) على 2.5 ثانية، وINP (الاستجابة) على 200 مللي ثانية، وCLS (ثبات التصميم) على 0.1، وكلها مقيسة عند المئين 75. ابحث عن المقياس الفاشل في بيانات الزوار الحقيقيين لا في درجة المختبر، وأصلح هذا المقياس أولًا. يقول Google إن أنظمة الترتيب لديه تستخدم Core Web Vitals، لكن القيم الجيدة لا تضمن مركزًا متقدمًا.

ماذا يعني فشل Core Web Vitals؟

Core Web Vitals هي الجزء من مبادرة Web Vitals لدى Google الذي ينطبق على كل صفحة ويب. يذكر web.dev ثلاثة مقاييس، لكل منها جانب من تجربة المستخدم:

تُحكم القيم عند المئين 75 من مرات تحميل الصفحة، منفصلةً للهاتف وللحاسوب. بعبارة بسيطة: في ثلاث زيارات من أربع ينبغي أن تكون القيمة جيدة، وللهاتف والحاسوب حكم لكل منهما. ويقول web.dev للأدوات أن تعدّ الصفحة ناجحة إذا حققت الأهداف الثلاثة كلها عند المئين 75. فيكفي مقياس واحد أحمر لتفشل.

وهناك تفصيل عند الحد: يكتب web.dev «أو أقل» لـ INP وCLS، بينما تكتب وثائق Google للبحث «أقل من 200 مللي ثانية» و«أقل من 0.1». فاستهدف قيمة أدنى من الحد بوضوح ولن يهم الفرق.

وهناك تغيير ينبغي أن تعرفه: حلّ INP محل First Input Delay (FID) بوصفه أحد Core Web Vitals في مارس 2024، كما يقول إعلان web.dev. وأي دليل ما زال يذكر FID قديم. وقد قرأنا كل الصفحات المذكورة في هذه المقالة في 4 نوفمبر 2026؛ وآخر تحديث لنظرة web.dev العامة كان في 31 أكتوبر 2024.

هل تؤثر Core Web Vitals في ترتيب Google؟

نعم بحسب Google، لكنه لا يذكر وزنًا. تقول صفحته عن تجربة الصفحة: «Core Web Vitals are used by our ranking systems.» وهو يوصي بقيم جيدة للنجاح في البحث، ويضيف أنه لا توجد إشارة واحدة لتجربة الصفحة.

والصفحة نفسها واضحة بالقدر ذاته في ما يخص الحدود. فالنتائج الجيدة في تقرير Core Web Vitals في Search Console أو في أدوات من جهات خارجية «doesn't guarantee that your pages will rank at the top of Google Search results». وتقول أيضًا إن ملاحقة درجة مثالية لأجل SEO وحده قد لا تكون أفضل استثمار لوقتك. فـ Google يحاول دائمًا أن يعرض المحتوى الأكثر صلة، حتى لو كانت تجربة الصفحة ضعيفة.

وما لا ينشره Google هو وزن هذه المقاييس، ولذلك لا نذكر نحن أيضًا رقمًا. وقراءتنا، لا معلومة من Google: عامل الحدود بوصفها معيار جودة لزوارك، وأوصل المقاييس الثلاثة كلها إلى «جيد»، ثم أعد وقتك إلى المحتوى. وتقيّم أنظمة الترتيب الأساسية لدى Google المحتوى عمومًا صفحةً صفحة، فافحص كل نوع من الصفحات يهمك.

بيانات المختبر أم البيانات الميدانية: أيهما يُحتسب في Core Web Vitals؟

يستند التقييم إلى البيانات الميدانية: قياسات من زيارات حقيقية. يجمعها تقرير Chrome User Experience Report (CrUX) من مستخدمي Chrome الحقيقيين، ويعرضها PageSpeed Insights وتقرير Core Web Vitals في Search Console. وبحسب web.dev يغطي تقرير CrUX فترة 28 يومًا.

أما بيانات المختبر فتأتي من تحميل الصفحة مرة واحدة في إعداد مضبوط: جهاز واحد وشبكة واحدة وموقع واحد. وهذا مثالي لإيجاد الأسباب ولاختبار إصلاح قبل نشره، لكن دليل LCP يحذّر من أن «lab tests alone may not be entirely representative». وحين يختلف الاثنان يقول دليل LCP أن تركّز أولًا على بيانات المستخدمين الحقيقيين. ولاختلافهما أسباب وجيهة:

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

وهكذا تقرأ أرقامك في أربع خطوات:

1. افحص عنوانك في PageSpeed Insights. يضم القسم «Discover what your real users are experiencing» البيانات الميدانية، ويضم «Diagnose performance issues» تجربة المختبر.
2. تأكد مما تنظر إليه. بدّل بين الهاتف والحاسوب وبين العنوان المفرد والموقع كله (origin). فإذا لم تتوفر لعنوان بيانات كافية يعرض PageSpeed Insights بيانات الموقع كله بدلًا منها.
3. جد المقياس الذي يتجاوز حدّه عند المئين 75. هذا هو مقياسك الفاشل. وإذا كانت الزيارات قليلة فلا توجد بيانات ميدانية؛ فاستخدم قيم المختبر وقس زوارك بنفسك بمكتبة web-vitals الصغيرة من web.dev.
4. افتح تشخيص المختبر لهذا المقياس لترى السبب، وأصلح هذا الشيء الواحد أولًا.

كيف تحسّن LCP: يظهر أكبر عنصر متأخرًا

يبلّغ LCP متى يُرسم أكبر صورة أو كتلة نص أو فيديو في المنطقة المرئية. يقسّم دليل LCP من web.dev الزمن إلى أربعة أجزاء يتكوّن منها LCP: استجابة الخادم (TTFB)، والتأخر قبل أن يبدأ المتصفح تحميل مورد LCP، والزمن الذي يحتاجه هذا المورد ليُحمَّل، والتأخر حتى يُرسم العنصر. فاعرف الجزء الأكبر قبل أن تغيّر شيئًا: قد يؤدي تقصير جزء إلى نقل الزمن إلى جزء آخر فحسب. والصورة الأشد ضغطًا لا تفيد إذا بقي العنصر مخفيًا حتى يُحمَّل سكربت.

وتتضمن قائمة أنجع الإصلاحات من فريق Chrome ما يلي:

1. اجعل صورة LCP سهلة الاكتشاف وأعطها الأولوية. استخدم ‎<img>‎ عاديًا بالسمة src أو srcset، لا data-src يحتاج إلى JavaScript. ورجّح بناء الصفحة على الخادم على تجميعها في المتصفح وحده. وأضف ‎fetchpriority="high"‎ وأزل ‎loading="lazy"‎ من هذه الصورة وحدها.
2. قصّر استجابة الخادم. قدّم المحتوى وخزّنه قريبًا من زوارك، وغالبًا بشبكة CDN.

والوسم نفسه يعالج LCP، ويعالج CLS عبر مقاسه:

<!-- الصورة الرئيسية: في HTML وبأولوية عالية وبلا تحميل كسول وبمقاس -->
<img src="/img/hero.webp" width="1200" height="630" alt="وصف قصير" fetchpriority="high">

<!-- الصور الأبعد في الصفحة: التحميل الكسول مناسب هنا -->
<img src="/img/team.webp" width="600" height="400" alt="وصف قصير" loading="lazy">

كيف تحسّن INP: تستجيب الصفحة ببطء

يراقب INP كل نقرة ولمسة وضغطة مفتاح أثناء الزيارة ويبلّغ تقريبًا عن أبطأها (وفي الصفحات الكثيرة التفاعلات تُهمل القيم الشاذة). أما تمرير الفأرة فوق عنصر والتمرير فلا يُحتسبان. وبحسب دليل INP يتكون كل تفاعل من ثلاثة أجزاء: التأخر في الإدخال، والزمن الذي تعمل فيه معالجات الأحداث، والتأخر حتى يُعرض الإطار التالي. والمتهم المعتاد هو JavaScript الذي يُبقي الخيط الرئيسي (main thread) مشغولًا. وهذه أهم إصلاحات فريق Chrome:

1. قسّم المهام الطويلة. المهمة التي تزيد على 50 مللي ثانية تحجب الخيط الرئيسي. أعد التحكم كثيرًا: بـ ‎scheduler.yield()‎ حيث يدعمه المتصفح، وبـ setTimeout بوصفه الطريقة الأقدم.
2. أرسل JavaScript أقل. اعثر على الشيفرة غير المستخدمة بأداة التغطية (coverage) في أدوات مطوري Chrome، وقسّم الشيفرة التي لا تلزم في البداية، ونظّف الوسوم القديمة في مدير الوسوم.
3. تجنب تحديثات العرض الكبيرة. أبقِ DOM صغيرًا، وتجنب التخطيط القسري، واستخدم CSS containment للمحتوى خارج الشاشة.

كيف تحسّن CLS: التصميم يهتز

لا وحدة لـ CLS. فهو يجمع بين مقدار ما تحرك من المحتوى المرئي ومسافة تحركه. وفي الميدان يُعدّ على امتداد الزيارة كلها، لكن الإزاحات في غضون 500 مللي ثانية من تفاعل المستخدم تُستبعد. ويسرد دليل CLS من web.dev الأسباب الشائعة: صور بلا أبعاد، وإعلانات، وعناصر مضمّنة وإطارات iframe بلا أبعاد، ومحتوى يُحقن ديناميكيًا، وخطوط الويب. والمفيد:

• احجز المساحة. أعطِ الصور والفيديوهات width وheight، أو استخدم خاصية aspect-ratio في CSS. وللمحتوى مجهول المقاس تفضل min-height معقولة على القيمة الافتراضية صفر.
• حرّك بـ transform. تحريك top أو left أو margin يزحزح التصميم. ولافتات ملفات تعريف الارتباط التي تنزلق مثال شائع.
• دع ذاكرة الرجوع والتقدم تعمل. فهي تستعيد صفحات مرسومة بالكامل. ومن العوائق الشائعة توجيهات التخزين no-store ومستمعو الحدث unload.
• تعامل مع خطوط الويب. font-display: optional وخطوط بديلة مطابقة بـ size-adjust وتحميل الخطوط الحرجة مسبقًا، كلها تقلل الإزاحات المرتبطة بالخطوط.

كيف يفحص SEOgrinder مقاييس Core Web Vitals

SEOgrinder أداتنا ونحن من نبنيها. أدخل عنوانًا عامًا في SEOgrinder وتأتيك أرقام السرعة من Google PageSpeed Insights، للهاتف وللحاسوب. تعرض بطاقة Core Web Vitals قيمتي LCP وCLS من تجربة Lighthouse في المختبر، وقيمة INP من الزوار الحقيقيين، ويعرض صندوق منفصل بعنوان «بيانات مستخدمين حقيقيين» بيانات المستخدمين الحقيقيين لآخر 28 يومًا. وإذا لم تتوفر لدى Google بيانات كافية للصفحة فالتقرير يقول ذلك بدل أن يخمّن. وتذكر مهام مثل «الزوار الحقيقيون على الهاتف ينتظرون … حتى يظهر المحتوى» المقياس والقيمة والحل. وللاستجابة البطيئة من الخادم، التي تدخل في LCP، مهمة خاصة بها هي «استجابة الخادم بطيئة».

حدوده: يقرأ SEOgrinder أرقام Google ولا يغني عن رصدك الخاص للمستخدمين الحقيقيين. ولا يقيس الترتيب. وإذا استُهلكت حصة Google اليومية لقياس السرعة، جاء التقرير من دونه.

الأخطاء الشائعة

• الاعتماد على درجة المختبر وحدها. لا تستطيع قياس INP، وقد تختلف عما يعيشه الزوار. ابدأ بقيم الزوار الحقيقيين.
• فحص جهاز واحد فقط. الهاتف والحاسوب يُحكم عليهما منفصلين.
• تحميل الصورة الرئيسية كسولًا. ‎loading="lazy"‎ على صورة LCP يضيف تأخيرًا.
• إغفال أبعاد الصور. من دون width وheight لا يستطيع المتصفح حجز المساحة.
• إصلاح الجزء الخطأ من LCP. اضغط الصور بعد أن يبيّن التقسيم أن زمن التحميل هو المشكلة.
• توقع نتيجة فورية. تغطي البيانات الميدانية 28 يومًا، فتتغير تدريجيًا. افحص تجربة المختبر مباشرة بعد الإصلاح، وقيم الزوار الحقيقيين في الأسابيع التالية.

الأسئلة الشائعة

ما درجة Core Web Vitals الجيدة؟

ليست هناك درجة واحدة. تنجح الصفحة حين يكون LCP عند المئين 75 مساويًا 2.5 ثانية أو أقل، وINP مساويًا 200 مللي ثانية أو أقل، وCLS مساويًا 0.1 أو أقل. أما الرقم من 0 إلى 100 الذي قد تعرفه من Lighthouse فقيمة مختبر، وهو شيء مختلف.

لماذا لا يعرض PageSpeed Insights بيانات زوار حقيقيين لموقعي؟

غالبًا لأن الزيارات قليلة جدًا ليبلّغ CrUX عنها. ويقترح web.dev في هذه الحال أن تضيف قياسك الخاص للزوار الحقيقيين. وإلى ذلك الحين اعمل بقيم المختبر.

هل أحتاج إلى درجة مثالية؟

لا. الهدف هو النجاح. ويقول Google نفسه إن ملاحقة درجة مثالية لأسباب SEO وحدها قد لا تكون أفضل استثمار لوقتك.

خطوتك التالية

مرّر أهم صفحاتك عبر SEOgrinder، وافتح بطاقة Core Web Vitals وانظر أولًا إلى قيم الزوار الحقيقيين. أصلح المقياس الواحد الفاشل، واضغط إعادة التحقق، ثم اقرأ قيم المختبر. والصورة الأوسع في قائمة تدقيق SEO عندنا.

اقرأ أيضًا

• تحسين ترتيب الموقع في جوجل: 3 أمور توصي بها Google نفسها
• الروابط الداخلية: كيف تجد الصفحات اليتيمة وتقلّل عمق النقرات
• البيانات المنظمة بصيغة JSON-LD: مثالان جاهزان للنسخ والاختبار