قد تقلل حجم صورة الواجهة إلى النصف ولا يتحسن ظهورها على الهاتف كما توقعت. السبب أن LCP لا يقيس تنزيل الصورة وحده؛ قد ينتظر المتصفح معرفة عنوانها، أو يتأخر رسمها بعد وصول الملف. تحسين LCP على الموبايل يبدأ بتحديد العنصر الفعلي ومراحل تأخره، ثم تجربة تغيير يناسب سبب التأخير.
حدد العنصر بدل افتراض أنه الصورة
تعرض وثائق web.dev لتحسين LCP تحليلًا يفصل رد السيرفر، وتأخير بدء تحميل المورد، ومدة تحميله، وتأخير رسم العنصر. استخدم تقرير الأداء وأدوات المتصفح لمعرفة العنصر المرصود في الصفحة التي تختبرها؛ فقد يكون صورة أو كتلة نص بحسب العرض والمحتوى.
ابدأ بعنوان URL واحد وعرض هاتف محدد وحالة واضحة للكاش. سجّل تاريخ الاختبار ونسخة الصفحة والعنصر وصورة من تسلسل الشبكة. لا تقارن نتيجة من اتصال سريع بنتيجة من إعداد محاكاة مختلف وتعتبر الفرق نجاحًا لتعديل الصورة. كرر القياس في الظروف نفسها، ثم راجع التفاوت قبل اختيار التغيير التالي.
اربط السبب بالإجراء المناسب
| الإشارة | ما تراجعه أولًا |
|---|---|
| رد السيرفر متأخر | زمن توليد الصفحة والكاش والطلبات الخلفية |
| الصورة تبدأ متأخرة | وجودها في HTML وكيف يكتشف المتصفح عنوانها |
| تنزيل المورد يستغرق وقتًا | الأبعاد والترميز والحجم وشبكة التسليم |
| الملف وصل لكن العنصر تأخر | CSS والعمل على المسار الرئيسي وإخفاء العنصر |
هذه المصفوفة أداة تشخيص، لا وصفة لتطبيق كل الإجراءات دفعة واحدة. إذا بدأ تنزيل الصورة مبكرًا وانتهى بسرعة، فقد لا يفيد المزيد من الضغط. وإذا كان السيرفر هو الجزء الأبطأ، فراجع أثر صفحة بسيطة ومخزنة قبل تحميل المشكلة إلى تصميم الصورة.
افحص اكتشاف صورة الواجهة
راجع هل عنوان الصورة موجود في HTML الأولي، أم يحتاج تشغيل JavaScript أو تحميل ملف CSS قبل ظهوره. للصورة المهمة في أعلى الصفحة، اختبر أولوية التحميل واستراتيجية اكتشاف المورد وفق بنية الصفحة. لا تضع lazy loading على صورة LCP دون مراجعة أثره، ولا ترفع أولوية كل الصور؛ فالتنافس على الشبكة قد يضر المورد الذي تحاول تقديمه.
إذا كانت الصورة متجاوبة، راجع المورد الذي اختاره المتصفح فعلًا على الهاتف. قد يكون srcset موجودًا لكن sizes يعلن مساحة أكبر من المعروضة، فيحمّل جهاز صغير صورة لا يحتاجها. أي preload تضيفه يجب أن يتوافق مع اختيار الصورة حتى لا يحمّل المتصفح نسختين. اختبر سلامة التصميم والدقة بعد تغيير الأبعاد، وليس الرقم فقط.
جرّب تغييرًا واحدًا واحتفظ بطريقة الرجوع
في تجربة توضيحية، يبدأ تنزيل الصورة بعد تنفيذ مكوّن الواجهة. قد يختبر الفريق جعل المورد قابلاً للاكتشاف مبكرًا، ثم يقارن بدء الطلب ووقت ظهور العنصر. إن تحسن بدء التحميل لكن بقي LCP مرتفعًا، فراجع تأخير الرسم. لا تعلن أن التغيير عالج كل المشكلة لأن حجم الملف أو توقيت الطلب تحسن وحده.
احتفظ بالنسخة السابقة ودوّن التغيير الذي اختبرته. راجع أعلى الصفحة على الهاتف والكمبيوتر، ومظهر النص، وحركة العناصر أثناء التحميل. إن كانت الواجهة تستخدم فيديوًا زخرفيًا، فلا تجعل اختباره يحجب مراجعة العنصر الذي يقيسه المتصفح بالفعل.
فرّق بين المختبر وتجربة الزوار
توضح وثائق Core Web Vitals دور بيانات المستخدمين الفعلية في تقييم تجربة الصفحة. الاختبار المختبري مفيد للتشخيص السريع، لكنه لا يمثل كل الأجهزة والاتصالات. بعد نشر تغيير ناجح فنيًا، راقب بيانات الزيارات المتاحة مع مرور الوقت، واحتفظ بسجل الإصدارات للمقارنة.
أدخل التشخيص ضمن تطوير المواقع والمتاجر، وتابع القياسات عبر الصيانة التقنية. القرار الجيد مبني على الجزء الذي يؤخر العنصر وعلى تجربة التصميم بعد التعديل، لا على ضغط صورة عشوائي أو مقارنة درجتين في ظروف مختلفة.
