لماذا تفشل مؤشرات الويب الأساسية لديك رغم أن الصفحة "تبدو" سريعة؟

المشكلة

أدوات القياس المخبري (Lighthouse، القسم المخبري في PageSpeed Insights) تقيس تشغيلاً محاكياً واحداً على ملف جهاز واحد — مفيد للتشخيص، لكنه ليس ما يعتمده جوجل فعلياً في الترتيب. المؤشرات المؤثرة على الترتيب هي بيانات ميدانية من CrUX، مجمّعة من أجهزة وشبكات زوار حقيقيين على مدى نافذة متحركة من 28 يوماً. قد تحصل الصفحة على درجة مخبرية جيدة في تشغيل واحد بينما يفشل مؤشر INP الحقيقي لأن المستخدمين الفعليين يستخدمون هواتف أبطأ تُشغّل كماً أكبر من كود العميل مما حاكاه الاختبار المخبري — أو العكس.

الأعراض

• PageSpeed Insights يُظهر درجة مخبرية في التسعينات بينما يُظهر قسم البيانات الميدانية ("اكتشف ما يختبره مستخدموك الحقيقيون") تصنيف LCP أو INP ضمن "يحتاج تحسين" أو "ضعيف"، أو يعرض "لا تتوفر بيانات" لصفحة قليلة الزيارات.

• تقرير مؤشرات الويب الأساسية في Search Console يصنّف مجموعة من الروابط كـ"ضعيف" أو "يحتاج تحسين" حسب نمط الرابط، ويرتبط هذا النمط بقالب أو مكوّن محدد، لا بالموقع كاملاً.

• مؤشر LCP يتحكم فيه استدعاء بيانات من جهة العميل — أكبر عنصر مرئي لا يُرسَم إلا بعد عودة استجابة API مُعرَضة عبر جافاسكريبت، بدلاً من وجوده في HTML الأولي.

• مؤشر INP يتدهور تحديداً أثناء التفاعل (النقر على فلتر، فتح قائمة) في صفحات تحمل حالة عميل ثقيلة أو مكتبات حركة، رغم أن التحميل الأولي بدا جيداً.

• ارتفاعات في CLS تُعزى إلى استبدال خطوط الويب بعد الرسم الأول، أو صور بلا أبعاد صريحة (width/height)، أو محتوى يُحقن فوق عناصر مرسومة مسبقاً (إعلانات، لافتات، أدوات تُحمَّل ديناميكياً).

كيف نشخّص المشكلة

نبدأ من تقرير مؤشرات الويب الأساسية في Search Console وبيانات CrUX الميدانية (عبر PageSpeed Insights أو واجهة CrUX البرمجية) مصنّفة حسب نمط الرابط، لنُصلح ما يفشل فعلاً لدى زوار حقيقيين بدلاً من ملاحقة درجة مخبرية. لكل مجموعة فاشلة نأخذ رابطاً ممثلاً ونحلّله عبر لوحة الأداء في أدوات مطوري Chrome وأثر Lighthouse لتحديد العنصر والسكربت المسؤول تحديداً — عنصر LCP وما الذي أخّر رسمه، والسكربتات الأطول تشغيلاً أثناء التفاعل بالنسبة لـ INP، والتعديل الدقيق في DOM المسبب لانزياح التخطيط بالنسبة لـ CLS. في المواقع الثقيلة بجافاسكريبت نفحص تحديداً مقدار ما يعتمد على العرض والترطيب من جانب العميل ضمن المسار الحرج، لأنه غالباً السبب الجذري المشترك بين المؤشرات الثلاثة.

الحل

إصلاح LCP عادة يعني إدخال أكبر عنصر ظاهر أعلى الصفحة (غالباً صورة رئيسية أو عنوان) ضمن HTML المُعرَض من الخادم بدلاً من تركه خلف استدعاء من جهة العميل، وإعطاء أولوية لطلب هذه الصورة (`fetchpriority="high"` وتجنّب التحميل الكسول لها)، وإزالة الموارد التي تحجب العرض قبلها. إصلاح INP يعني تقليل كود جافاسكريبت الذي يعمل أثناء التفاعل وبعده مباشرة — تقسيم الحزم غير الحرجة، تأجيل سكربتات الطرف الثالث، وتجنّب تحديثات حالة متزامنة كبيرة مع كل ضغطة مفتاح أو حدث تمرير. إصلاح CLS يعني حجز مساحة للصور والتضمينات والإعلانات قبل تحميلها (أبعاد صريحة أو صناديق بنسبة عرض إلى ارتفاع ثابتة) وتحميل خطوط الويب بطريقة تتجنّب انزياحاً بصرياً واضحاً عند استبدالها.

تفاصيل التنفيذ

في هذا الموقع المبني على Next.js، يعتمد العمل على LCP على أدوات الإطار نفسه لا على نصائح عامة: مكوّن `next/image` لتحديد الأبعاد والأولوية تلقائياً للصور الرئيسية، ومكونات الخادم التي تعرض المحتوى الأساسي من جهة الخادم بدلاً من خلف استدعاء عميل، ونمط `dynamic-loaders` (أغلفة عميل خفيفة حول مكونات تفاعلية أثقل، تُستورد عبر `next/dynamic` مع `ssr: true`) لتقسيم الأقسام الغنية بالحركة كي لا تحجب الرسم الأول أو تُضيف عبئاً على الخيط الرئيسي يُحتسب ضمن INP. أما CLS، فمكونات الصور تحمل أبعاداً صريحة، والأقسام المتحركة تستخدم خصائص `initial`/`animate` من مكتبة `framer-motion` ضمن مساحة تخطيط محجوزة مسبقاً بدلاً من حقن محتوى يزيح عناصر موجودة. نقيس قبل الإصلاح وبعده بنفس البيانات الميدانية المعتمدة على CrUX المستخدمة في التشخيص، لا مجرد إعادة تشغيل مخبري.

أخطاء شائعة

• الاكتفاء بتحسين تشغيل واحد لأداة Lighthouse وإعلان النجاح، دون التحقق مما إذا كانت البيانات الميدانية الحقيقية (CrUX) تحرّكت فعلاً — فالدرجات المخبرية والميدانية قد تتباعد بشكل كبير.

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

• إضافة المزيد من كود جافاسكريبت من جهة العميل (سكربت "مراقبة أداء" أو "تحسين") لإصلاح مشكلة سببها جافاسكريبت نفسه، وهو ما قد يزيد INP سوءاً.

• حجز مساحة لـ CLS بارتفاع ثابت بالبكسل يتكسّر على التخطيطات المتجاوبة، بدلاً من حجز يعتمد على نسبة العرض إلى الارتفاع ويتكيّف مع عرض الشاشة.

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

التحقق

نتحقق عبر تقرير مؤشرات الويب الأساسية في Search Console خلال نافذة تقارير CrUX التالية (قد تستغرق النتائج حتى 28 يوماً لتنعكس كاملة في البيانات الميدانية، لذا نتحقق أيضاً فوراً من تحرّك المؤشرات المخبرية الأساسية كمؤشر مبكر)، ونعيد تشغيل قسم البيانات الميدانية في PageSpeed Insights للتأكد أن LCP وINP وCLS الحقيقية عبرت إلى نطاق "جيد"، لا فقط أن الدرجة المخبرية تحسّنت.

الخدمة والحلول ذات الصلة

غالباً ما تشترك مؤشرات الويب الأساسية وتحسين محركات البحث للجافاسكريبت في نفس السبب الجذري — العرض الثقيل من جهة العميل — لذا يكون تشخيص مؤشرات الويب الأساسية ومراجعة جافاسكريبت في الغالب نفس العمل التشخيصي منظوراً إليه عبر مقياسين مختلفين.