كيفية إصلاح LCP على الهاتف المحمول: دليل خطوة بخطوة

ما الذي يقيسه LCP فعليًا

Largest Contentful Paint هو الزمن من بداية التنقل حتى انتهاء عرض أكبر صورة أو أكبر كتلة نصية داخل أول مساحة عرض. ليس الصفحة بأكملها، ولا كل عنصر، ولا "التحميل الكامل": بل عنصر واحد، وهو الأكبر الذي يراه الزائر دون تمرير.

العتبة هي 2.5 ثانية أو أقل للحصول على تقييم جيد. وما بين 2.5 و4.0 ثانية يُعد "يحتاج إلى تحسين"، وما فوق 4.0 ثوانٍ يُعد ضعيفًا. والأهم أن الرقم المعتمد هو المئين 75 لعمليات تحميل الصفحات الفعلية على الهاتف المحمول، لا نتيجة اختبار واحد على حاسوبك المحمول. فالصفحة التي تُحمَّل في 1.2 ثانية لديك وفي 5 ثوانٍ لدى زائر على هاتف Android متوسط الفئة هي صفحة فاشلة، لأن الزائر هو من يقيس Google تجربته.

من المفيد تقسيم LCP إلى أجزائه الأربعة، لأن الإصلاح يعتمد كليًا على الجزء البطيء: زمن الاستجابة الأول (TTFB)، والتأخير قبل أن يبدأ المتصفح في جلب مورد العنصر، وطول مدة تنزيل ذلك المورد، والتأخير قبل عرضه نهائيًا. ومعظم الإصلاحات تستهدف الجزء الثاني.

INP وCLS باختصار

تتضمن مؤشرات Core Web Vitals ثلاث مقاييس، والـ LCP واحد منها فقط. يقيس Interaction to Next Paint سرعة الاستجابة: المدة التي تستغرقها الصفحة لتتفاعل بشكل مرئي مع نقرة أو لمسة، عبر تفاعلات الزيارة. والقيمة الجيدة هي 200 ميلي ثانية أو أقل عند المئين 75. وقد حلّ هذا المقياس محل First Input Delay في مارس 2024، ومن الصعب التلاعب به أكثر بكثير، لأنه يتعلق بالمهام الطويلة على الخيط الرئيسي لا بمدخل واحد مبكر. أما Cumulative Layout Shift فيقيس مقدار تحرك الصفحة تحت إصبع القارئ، والقيمة الجيدة هي 0.1 أو أقل.

تتفاعل هذه المقاييس الثلاثة، ولهذا فإن إصلاح أحدها بمعزل عن الآخرين قد يزيد آخر سوءًا. فتأجيل تحميل ورقة أنماط قد يحسّن الـ LCP ويُحدث وميضًا لمحتوى غير منسّق؛ وإزالة أحد الانزياحات تعني غالبًا حجز مساحة، وقد يدفع ذلك أكبر عنصر إلى وقت لاحق. قِس المقاييس الثلاثة بعد كل تغيير.

الخطوة الأولى: تحديد عنصر LCP قبل إجراء أي تغيير

لا يمكنك إصلاح الـ LCP دون معرفة العنصر الذي يُقاس، وهو غالبًا ليس العنصر الذي تفترضه. فالأكثر شيوعًا هو الصورة الرئيسية، وأحيانًا صورة خلفية، وكثيرًا ما يكون h1 أو فقرة نصية كبيرة عندما يُعرض النص قبل اكتمال تحميل الصورة. وفي صفحة تُعرض من جهة العميل، يكون عنصر LCP غالبًا شيئًا يكاد لا وجود له في مصدر HTML.

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

احصل على الإجابة من PageSpeed Insights، الذي يحدد عنصر LCP في تشخيصاته، أو اقرأها مباشرة في المتصفح:

new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const last = entries[entries.length - 1];
  console.log(last.element, Math.round(last.startTime), 'ms');
}).observe({ type: 'largest-contentful-paint', buffered: true });

حلول ملموسة لكل سبب

تقليل زمن الوصول إلى البايت الأول

أضف ذاكرة تخزين مؤقت لكامل الصفحة حتى لا تصل الطلبات المجهولة إلى التطبيق أبدًا، ثم ذاكرة تخزين مؤقت للكائنات لما يتبقى من استعلامات قاعدة البيانات، ثم ذاكرة تخزين مؤقت طرفية أو CDN في المقدمة. تحقّق من الاستعلامات الطويلة على المسار الحرج للصفحة، ومن قاعدة بيانات أصغر من أن تستوعب مجموعة البيانات العاملة. وعلى خادم يُدار ذاتيًا، يكون TTFB عادةً مشكلة في القرص أو الذاكرة أو الإعداد، ولهذا يندرج العمل على مستوى الاستضافة في المناقشة نفسها. وإذا كانت خطتك تستهلك كل ذاكرتها تحت الحمل العادي، فلن ينقذ المؤشر أي قدر من ضبط الواجهة، والانتقال إلى خطة NVMe KVM بموارد يمكن التنبؤ بها أرخص كلفةً من أشهر من الضبط والتحسين.

إزالة عوائق العرض

ضمّن في الصفحة أنماط CSS اللازمة لأول نافذة عرض، وحمّل الباقي دون إعاقة باستخدام media وonload أو preload مع الاستبدال. أضف defer إلى السكربتات التي لا تحتاج إلى التنفيذ قبل العرض، وasync فقط حيث لا يهم الترتيب فعليًا. راجع كل مدخل في أداة إدارة الوسوم وكل سكربت طرف ثالث: فالأدوات التحليلية وودجات الدردشة والخرائط الحرارية وأدوات اختبار A/B غالبًا ما تكون أكبر تكلفة عرض متبقية، ومعظمها يمكنه الانتظار حتى حدوث تفاعل. استضف خطوطك بنفسك، واستخدم font-display: swap، واقتصر التحميل المسبق على الوزن الوحيد المستخدم في الجزء الظاهر أولًا.

إصلاح الصورة الرئيسية بالشكل الصحيح

حمّلها مسبقًا ليبدأ الطلب أثناء تحليل HTML لا بعد التخطيط، وقدّم AVIF أو WebP مع بديل احتياطي، ووفّر srcset حتى لا ينزّل الهاتف ملفًا بحجم سطح المكتب، وحدّد دائمًا width وheight صريحين أو نسبة أبعاد حتى تُحجز المساحة ولا يحدث أي انزياح.

لا تُؤجّل تحميل صورة LCP

هذا هو الجرح الأكثر شيوعًا الذي يسببه الموقع لنفسه. يضيف أحدهم loading="lazy" إلى كل صورة في الموقع، وهذا صحيح للصور العشرين الواقعة أسفل الشاشة، وضارّ فعليًا للصورة التي يقيسها Google. فالصورة المؤجلة لا تُطلب إلا بعد أن يُنهي المتصفح تخطيط الصفحة ويكتشف أن الصورة قريبة من نافذة العرض، وبذلك أضفت رحلة كاملة من التأخير إلى العنصر الذي كنت في أشد الحاجة إلى سرعته.

أصلح صورة LCP أولًا. وأبقِ التحميل المؤجل في كل ما عداها، حيث يكون مكسبًا حقيقيًا.

إخراج أول شاشة من JavaScript

اعرض من جهة الخادم أو أنشئ مسبقًا الصورة الرئيسية وعنوانها ونصها المرافق بحيث توجد في HTML المُسلَّم. وإذا كان الإطار يحتاج إلى الترطيب، فأبقِ الصورة الرئيسية خارج الشجرة المُرتَّبة وحمّل مسبقًا البيانات التي تحتاجها. وظهور الصورة الرئيسية بعد 3 ثوانٍ لأنها انتظرت حزمة واستدعاء API قرارٌ معماري في العرض لا مشكلة ضبط، ويجب معالجته على ذلك المستوى.

كيفية الاختبار: بيانات ميدانية مقابل بيانات مخبرية

البيانات الميدانية تأتي من زوار حقيقيين، وتُجمَّع في Chrome User Experience Report وفي تقرير Core Web Vitals في Search Console، وتُعبَّر عنها عند المئين 75 على نافذة متحركة من 28 يومًا، مقسّمة بين الهاتف وسطح المكتب. هذا هو الرقم المهم، لأنه ما عاشته الأجهزة الحقيقية فعليًا، وهو الرقم المعتمد في أي إشارة بحث.

البيانات المخبرية هي تحميل اصطناعي واحد، عادةً عبر Lighthouse داخل PageSpeed Insights، على جهاز سريع مع اتصال محدود وذاكرة تخزين مؤقت فارغة. لا يمكنها أن تخبرك بما يعيشه مستخدموك، لكنها أفضل بكثير في توضيح السبب: فهي تحدد عنصر LCP، وتُدرج الموارد المعيقة، وتعرض مخطط الشلال.

يختلفان لأنهما يقيسان فئتين مختلفتين من البيانات. فبيانات الميدان تحسب متوسطات آلاف الأجهزة والشبكات وحالات التخزين المؤقت، بما في ذلك الزيارات المتكررة التي يكون فيها كل شيء مخزّنًا مؤقتًا؛ أما بيانات المختبر فهي عملية تحميل باردة واحدة على هاتف محاكى. وتستخدم بيانات الميدان أيضًا منطق النسب المئوية، إذ تُعدّ الصفحة ناجحة عندما تكون 75% من عمليات التحميل أقل من 2.5 ثانية حتى لو انتظر ربع زوارك مدة أطول بكثير. اقرأهما معًا: استخدم المختبر لتحديد السبب، ثم تحقق في الميدان من أن الإصلاح غيّر النسبة المئوية 75. توقّع تأخرًا يقارب 28 يومًا قبل أن يصبح الإصلاح ظاهرًا بالكامل، ولا تستنتج أن تغييرًا فشل في اليوم الثالث.

التحفّظ الصادق بشأن Core Web Vitals

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

النصف الآخر من التحفّظ لا يقل أهمية: الموقع السريع ذو المحتوى الهزيل لن يحقق الترتيب أيضًا. وإذا كانت الصفحة تستغرق ثلاث ثوانٍ للتحميل وتجيب عن الاستعلام أفضل من كل ما يسبقها، فغالبًا ستفوز رغم ذلك. أصلح LCP لأن الصفحات البطيئة تفقد الزوار بمعزل عن Google، ولأنه يحسّن التحويل، ولأنه يزيل سببًا سهلًا للحكم بأنك أسوأ من منافس. لا تُصلحه بإفراغ الصفحة من المحتوى الذي جعل زيارتها مجدية، ولا تدع مؤشرًا يفرض تصميم صفحة كانت تحقق التحويل.

الأسئلة الشائعة حول LCP على الهاتف المحمول

لماذا يكون LCP جيدًا على الحاسوب وضعيفًا على الهاتف المحمول؟

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

هل يجب التحميل المسبق لكل صور الصفحة؟

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

نتيجتي في PageSpeed هي 60 لكن بيانات الميدان مطابقة. أيّهما أُصلح؟

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

هل يساعد التحميل الكسول LCP في بعض الحالات؟

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

بعد أي مدة من الإصلاح تتغيّر بيانات CrUX؟

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

ما نصيب الاستضافة من LCP؟

أكثر مما تعترف به معظم أدلة الواجهة الأمامية. فإذا تجاوز زمن الوصول إلى البايت الأول 600 مللي ثانية، فلن يوصلك أي تحسين للصور أو النصوص البرمجية إلى أقل من 2.5 ثانية، لأنك استهلكت حصة كبيرة من الميزانية قبل أن تبدأ الصفحة بالوصول.