تشخيص Core Web Vitals: كيف تُصلح LCP وINP وCLS دون تخمين

يخفق العمل على Core Web Vitals حين تقفز الفرق من الدرجة إلى الإصلاح. يقول تقرير إن LCP ضعيف، فيضغط أحدهم الصور. ويبدو INP ضعيفًا، فيحذف أحدهم نصًّا برمجيًا. ويتحرّك CLS، فيعدّل أحدهم تخطيطًا. أحيانًا يساعد ذلك، لكنه كثيرًا ما يهدر الوقت لأن الفريق لم يشخّص أبدًا القالب والجهاز وبيانات الميدان ورحلة المستخدم خلف المؤشر.

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

لتدقيق أوسع قبل التوسّع، استخدم قائمة فحص السيو التقني. ولفحص سريع على مستوى الصفحة، ابدأ بـمدقق سرعة الصفحة.

ابدأ ببيانات الميدان

اختبارات المختبر مفيدة، لكنّ Core Web Vitals تتعلّق بتجربة المستخدم الحقيقية. تُظهر بيانات الميدان ما يختبره الزوّار الفعليون عبر الأجهزة والاتصالات والمتصفّحات. وتساعد أدوات المختبر على إعادة إنتاج المشكلات وتنقيحها، لكن لا ينبغي أن تكون المصدر الوحيد للحقيقة.

ابدأ بتجميع عناوين URL بحسب القالب:

• الصفحة الرئيسية.
• صفحات الخدمات.
• مقالات المدوّنة.
• صفحات مغناطيس العملاء.
• صفحات الأدوات.
• صفحات التواصل أو الحجز.

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

شخّص LCP: ما العنصر الأكبر؟

يقيس Largest Contentful Paint اللحظة التي يصبح فيها عنصر المحتوى الرئيسي مرئيًا. يبدأ التشخيص بتحديد عنصر LCP، لا بتخمين نصيحة سرعة عامة.

تشمل أسباب LCP الشائعة:

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

يعتمد الإصلاح على السبب. فإذا كان عنصر LCP صورة بطل، فقد تهمّ أبعاد الصورة وصيغتها وسلوك التحميل المسبق وأولوية التخطيط. وإذا كان التأخير في استجابة الخادم، فلن يحلّ ضغط الصور المشكلة الجذرية. وإذا انتظرت الصفحة JavaScript من جانب العميل قبل عرض المحتوى، فإن القالب يحتاج إلى عمل على العرض لا إلى إضافة قابس آخر.

يشرح مقال Core Web Vitals 2026 الأقدم لدينا سبب أهمّية تحديد الأولوية. وهذه المسوّدة هي النسخة التشغيلية: ابحث عن العنصر، وابحث عن التأخير، ثم أصلِح ذلك التأخير.

شخّص INP: أيّ تفاعل بطيء؟

ينظر Interaction to Next Paint إلى الاستجابة بعد أن يتفاعل المستخدم مع الصفحة. وكثيرًا ما تأتي مشكلات INP من JavaScript ثقيل، أو مهامّ طويلة، أو معالِجات أحداث باهظة، أو نصوص برمجية من أطراف ثالثة تتنافس على الخيط الرئيسي.

لا تبدأ بحذف النصوص البرمجية عشوائيًا. حدّد التفاعل أولًا:

• فتح التنقّل.
• النقر على المرشّحات أو علامات التبويب.
• الكتابة في نموذج.
• فتح نافذة منبثقة.
• إرسال نموذج.
• التفاعل مع أداة مضمّنة.

ثم افحص ما يحدث بعد التفاعل. هل المتصفّح مشغول بتشغيل مهمّة طويلة؟ هل يؤخّر نصّ برمجي من طرف ثالث الاستجابة؟ هل يؤدّي التطبيق عملًا كثيرًا قبل عرض ردّ فعل؟ هل يُعاد عرض مكوّن أكثر مما يلزم؟

كثيرًا ما تكون إصلاحات INP إصلاحات هندسية: قلّل عمل الخيط الرئيسي، وقسّم المهامّ الكبيرة، وأجّل النصوص البرمجية غير الحرجة، وبسّط المعالِجات الباهظة، أو أظهِر ردّ الفعل أبكر. الهدف ليس إزالة وظيفة مفيدة، بل إبقاء الصفحة مستجيبة حين يحاول الزوّار استخدامها.

شخّص CLS: ما الذي تحرّك؟

يقيس Cumulative Layout Shift الحركة البصرية غير المتوقّعة. وأبسط سؤال تشخيصي هو: ما الذي تحرّك، ولماذا لم تُحجَز المساحة له؟

تشمل الأسباب الشائعة:

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

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

أصلِح القوالب قبل الصفحات الفردية

إذا كانت لدى صفحة خدمة واحدة مشكلة، فافحصها. وإذا كانت لدى كل صفحة خدمة المشكلة نفسها، فأصلِح القالب. عادةً ما تكون إصلاحات مستوى القالب الأعلى رافعةً لأنها تحسّن كل صفحة مبنيّة على ذلك النمط.

بالنسبة لـ SEO Evaluate، يهمّ هذا لأن الموقع يضمّ الآن مزيدًا من عناوين المدوّنة، ومزيدًا من المسارات المحلية، ومزيدًا من مسارات مغناطيس العملاء. وينبغي أن يحمي عمل الأداء النظام، لا أن يرقّع صفحة واحدة ويترك النمط خلفه.

استخدم منظور خدمة السيو التقني هنا: قابلية الزحف، والعرض، والأداء، والروابط الداخلية، والبيانات المنظَّمة، كلها يعزّز بعضها بعضًا. فصفحة سريعة لا يمكن فهرستها لا تكفي. وصفحة قابلة للفهرسة تُحبط المستخدمين لا تكفي أيضًا.

تحقّق بعد الإصلاح

بعد إجراء تغيير، اختبر على طبقات:

1. أعِد تشغيل اختبارات المختبر لتأكيد تحرّك المشكلة المشتبه بها في الاتجاه الصحيح.

2. افحص الصفحة يدويًا على الجوّال وسطح المكتب.

3. تأكّد من أن الصفحة لا تزال تعرض المحتوى والروابط والنماذج وschema نفسها.

4. راقِب بيانات الميدان عبر الزمن، لأنها تتحدّث بعد أن يختبر المستخدمون الحقيقيون التغيير.

5. وثّق ما تغيّر كي لا يعيد الفريق إدخال المشكلة نفسها لاحقًا.

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

اربط الأداء بخطة المحتوى

عمل Core Web Vitals ليس منفصلًا عن نموّ المحتوى. فإذا كان فريقك على وشك نشر مزيد من المقالات أو الموارد أو الأدوات أو الصفحات المحلية، فإن القوالب تحتاج إلى أن تكون قوية بما يكفي لحمل ذلك النموّ. فالقالب البطيء أو غير المستقرّ يتضاعف عبر كل صفحة تضيفها.

لهذا تنتمي طبقة الأداء إلى تدقيق ما قبل التوسّع. يتناول مقال قائمة فحص السيو التقني الأساس الأوسع: قابلية الزحف، والبنية، وCore Web Vitals، والبيانات المنظَّمة، والإشارات الدولية، والقياس.

الخاتمة

ينبغي أن يكون تشخيص Core Web Vitals محدّدًا. لا تُصلح «السرعة» على نحو مجرّد. ابحث عن القالب المتأثّر، وحدّد ما إذا كان LCP أو INP أو CLS هو القيد، واعزل السبب، وتحقّق دون كسر محتوى الصفحة أو مسار التحويل فيها.

إن أردت مسار تدقيق منظَّمًا، فحمّل قائمة فحص السيو التقني. وإن أردت مساعدة في ترتيب أولويات العمل الهندسي، احجز مكالمة ويمكننا مراجعة القوالب ذات الأولوية أولًا.