درجة Largest Contentful Paint هي واحدة من أكثر المقاييس صدقاً في أداء الويب. لا تهتم بحزم JavaScript التي أعددتها بعناية، ولا بالصور المضغوطة بشكل منفرد. إنها تقيس شيئاً واحداً فقط: كم من الوقت يستغرق ظهور أكبر عنصر مرئي على الصفحة للمستخدم الحقيقي. وعندما يكون هذا الرقم مرتفعاً، يعود السبب الجذري في الغالب إلى البنية التحتية، لا إلى الكود.
هذا ما يجعل LCP أداة تشخيصية مفيدة جداً. فهو يكشف سلسلة التسليم الكاملة، من استجابة الخادم إلى نقل الشبكة وصولاً إلى عرض المتصفح. إذا كان أي حلقة في هذه السلسلة بطيئة، فإن LCP يرصدها. تتخطى معظم أدلة الأداء مباشرة إلى تحسين الصور وتأجيل JavaScript. لكن هذا الدليل يبدأ من حيث تكمن الاختناقات الحقيقية عادةً.
ما الذي يقيسه LCP فعلاً
يتتبع LCP وقت عرض أكبر صورة أو كتلة نصية مرئية في نافذة العرض عند تحميل الصفحة لأول مرة. في معظم المواقع، يكون ذلك صورة بارزة، أو عنواناً كبيراً، أو قسم بانر في الجزء الظاهر من الصفحة.
معايير Google واضحة ومباشرة:
- جيد: أقل من 2.5 ثانية
- يحتاج إلى تحسين: من 2.5 إلى 4 ثوانٍ
- ضعيف: أكثر من 4 ثوانٍ
هذه ليست حدوداً اعتباطية. الصفحات التي يتجاوز تحميلها 3 ثوانٍ تفقد نسبة ملحوظة من الزوار قبل أن يظهر أي محتوى. بالنسبة لمواقع التجارة الإلكترونية، هذا تأثير مباشر على الإيرادات. أما مواقع المحتوى، فيظهر ذلك في معدل الارتداد وعمق الجلسة.
لا يقيس LCP التفاعلية أو استقرار التخطيط - هذا ما يتولاه INP وCLS. لكن لفهم أداء الخادم والاستضافة تحديداً، فإن LCP هو أوضح إشارة لديك.
كيف تؤثر قرارات استضافة Core Web Vitals على LCP
هنا يسير معظم الحديث عن الأداء في الاتجاه الخاطئ. يركز المطورون على تحسينات الواجهة الأمامية دون النظر إلى ما يفعله الخادم قبل أن يكون لأي شيء آخر أهمية.
ينقسم وقت LCP إلى أربع مراحل متميزة:
- الوقت حتى أول بايت (TTFB) - كم من الوقت يستغرق الخادم لبدء الاستجابة
- تأخير تحميل المورد - كم من الوقت ينتظره المتصفح قبل جلب مورد LCP
- وقت تحميل المورد - كم من الوقت يستغرق تنزيل المورد فعلياً
- تأخير عرض العنصر - كم من الوقت يستغرق المتصفح لرسم العنصر بعد وصول المورد
تتحكم بيئة الاستضافة مباشرة في المرحلتين الأولى والثالثة. استجابة الخادم البطيئة تُضخّم TTFB وتُؤخر كل مرحلة أخرى. الخادم الذي يفتقر إلى التخزين المؤقت يولّد تلك الاستجابة البطيئة في كل طلب. والخادم البعيد جغرافياً عن زوارك يضيف زمن استجابة عبر المراحل الأربع في آنٍ واحد.
لا يُصلح أي قدر من ضغط الصور خادماً يستغرق 900ms لتوليد استجابة. الحسابات ببساطة لا تستقيم.
قراءة تفاصيل LCP في PageSpeed Insights
يعرض PageSpeed Insights من Google الآن تفاصيل الأجزاء الفرعية لـ LCP مباشرة في التقرير. قم بإجراء اختبار، وابحث عن قسم Largest Contentful Paint، وستجد تسلسلاً زمنياً مقسماً إلى تلك المراحل الأربع، معبّراً عن كل منها كنسبة مئوية من إجمالي وقت LCP.
هذا التفصيل هو أسرع طريقة لتحديد مكان المشكلة الفعلي:
- TTFB يستهلك أكثر من 40% من وقت LCP: المشكلة على جانب الخادم. ابحث في التخزين المؤقت وسرعة استعلام قاعدة البيانات وموارد الخادم.
- تأخير طويل في تحميل المورد: يكتشف المتصفح مورد LCP متأخراً جداً. يعني عادةً أن الصورة موجودة في CSS أو يتم تحميلها بواسطة JavaScript بدلاً من HTML.
- وقت تحميل طويل للمورد مع TTFB سريع: الملف كبير جداً، أو لا يوجد CDN والخادم بعيد عن الزائر.
- تأخير طويل في العرض: الموارد التي تحجب العرض تعيق المتصفح حتى بعد تنزيل عنصر LCP.
كل تشخيص يشير إلى حل مختلف. لهذا السبب، قراءة التفاصيل أولاً تجنبك تحسين الشيء الخاطئ.
الإصلاحات على مستوى الاستضافة التي تُحرّك LCP أكثر
التخزين المؤقت من جانب الخادم: أكبر رافعة مؤثرة
الحصول على استجابة HTML مخزنة مؤقتاً من الخادم في أقل من 200ms هو أكثر تحسين مؤثر على LCP متاح لمعظم المواقع. عندما يُشغّل كل طلب صفحة دورة تنفيذ PHP كاملة وجولة من استعلامات قاعدة البيانات، سيكون TTFB بطيئاً باستمرار بغض النظر عن أي شيء آخر تفعله.
يخزّن التخزين المؤقت للصفحات ملف HTML جاهزاً يُقدَّم مباشرة دون لمس طبقة التطبيق. بالنسبة لمعظم صفحات المحتوى، يخفض هذا أوقات استجابة الخادم من 600-1200ms إلى أقل من 100ms. التأثير على LCP فوري وكبير.
بالنسبة لمواقع WordPress، يُضيف التخزين المؤقت للكائنات طبقة إضافية. من خلال تخزين نتائج استعلامات قاعدة البيانات في ذاكرة Redis، تعود الاستعلامات المتكررة دون الحاجة إلى الوصول إلى قاعدة البيانات أصلاً. يمكن لذاكرة تخزين مؤقت للكائنات جيدة بمعدل إصابة 80%+ أن تخفض أوقات استجابة الخادم الديناميكية إلى النصف حتى عندما لا يكون التخزين المؤقت الكامل للصفحة ممكناً - في صفحات المستخدمين المسجلين، وصفحات سلة WooCommerce، والمحتوى الشخصي. يمكنك قراءة المزيد حول كيفية عمل هذا على مستوى الخادم في نظرة عامة على التخزين المؤقت.
التحميل المسبق لمورد LCP
حتى مع استجابة خادم سريعة، يتأثر LCP إذا اكتشف المتصفح مورد LCP متأخراً. صورة بارزة مُشار إليها في خاصية خلفية CSS، على سبيل المثال، لن يتم جلبها حتى يقوم المتصفح بتنزيل ورقة الأنماط وتحليلها. هذا يضيف مئات المللي ثانية من التأخير غير الضروري.
تلميح التحميل المسبق في رأس المستند يُصلح هذا:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">هذا يخبر المتصفح بجلب صورة LCP فوراً، بالتوازي مع كل شيء آخر. تنقل سمة fetchpriority="high" الصورة إلى مقدمة قائمة التنزيل. تتقلص مرحلة تأخير تحميل المورد في تفاصيل LCP بشكل ملحوظ.
إذا كنت تستخدم وسم <img> لصورتك البارزة - وهو الأفضل - فتأكد من عدم وجود loading="lazy" عليها. التحميل الكسول على عنصر LCP هو خطأ شائع يجبر المتصفح على تقليل أولوية المورد الأكثر إلحاحاً.
التخلص من الموارد التي تحجب العرض
مرحلة تأخير العرض في LCP تنجم في الغالب عن انتظار المتصفح لـ CSS أو JavaScript المتزامن قبل أن يتمكن من رسم أي شيء. نهجان يعالجان هذا مباشرة.
أولاً، CSS الحرج. يعني ذلك استخراج الأنماط الأدنى اللازمة لعرض المحتوى فوق الطية وتضمينها في <head>. يمكن للمتصفح البدء في العرض فوراً دون انتظار تنزيل ورقات الأنماط الخارجية. ثم يتم تحميل ورقة الأنماط الكاملة بشكل غير متزامن:
<link rel="stylesheet" href="/styles.css" media="print" onload="this.media='all'">ثانياً، تأجيل JavaScript. أي سكريبت غير مطلوب للعرض الأولي يجب تأجيله أو تحميله بـ async. السكريبتات التي تعمل قبل رسم عنصر LCP تؤخر وقت الرسم، حتى لو كان المورد نفسه قد تم تنزيله بالفعل.
الدقة هنا أن تأخير JavaScript قد يُعطل بعض الأشياء. السكريبتات الخارجية وأدوات الدردشة وأدوات التحليل تحتاج أحياناً إلى معالجة دقيقة. الاختبار في بيئة تجريبية قبل النشر في الإنتاج يستحق الوقت.
صيغة الصورة وحجم الملف
إذا كان عنصر LCP صورة - وهو كذلك في معظم مواقع التسويق والمحتوى - فإن مرحلة وقت تحميل المورد تعتمد على حجم الملف. تقديم WebP بدلاً من JPEG يخفض أحجام الملفات بنسبة 25-35% بجودة بصرية مكافئة. يذهب AVIF أبعد من ذلك، محققاً وفورات تصل إلى 40-50% في الغالب، وإن كان دعم المتصفح له أضيق قليلاً.
صورة بارزة بحجم 450KB يمكن أن تكون 180KB بصيغة WebP - هذا يضيف 270KB إضافية إلى وقت تحميل مورد LCP دون سبب. عند سرعة اتصال 10 Mbps نموذجية، هذا 216ms إضافية. على اتصالات الجوال، الوضع أسوأ. تناولنا خيارات الصيغ بعمق في كيف تُقصّر صيغ ضغط الصور مثل WebP وAVIF أوقات التحميل.
حجّم الصورة بشكل صحيح أيضاً. تقديم صورة بعرض 1800px في حاوية بعرض 800px يهدر معدل نقل البيانات في كل طلب. استخدم الصور المتجاوبة مع srcset لتقديم ملفات بالحجم المناسب لكل حجم شاشة.
موقع الخادم وتغطية CDN
المسافة الفعلية بين خادمك وزوارك تضيف زمن استجابة لكل عملية شبكة. خادم في أوروبا يخدم مستخدمين في جنوب شرق آسيا يضيف عادةً 150-250ms من زمن الاستجابة ذهاباً وإياباً قبل نقل بايت واحد. يظهر هذا الزمن في TTFB وفي وقت تحميل المورد.
يحل CDN هذه المشكلة للأصول الثابتة عن طريق تخزينها في عقد حافة أقرب إلى زوارك. صورة LCP مُقدَّمة من عقدة حافة على بُعد 30ms مقارنة بخادمك الأصلي البعيد 180ms هي تحسين بمقدار 150ms في وقت تحميل المورد وحده. على مدار حساب LCP الكامل، هذا مهم. انظر كيف يغير CDN جغرافيا أداء موقعك للاطلاع على نظرة تفصيلية حول كيفية عمل التوزيع عبر الحافة عملياً.
أدوات لتحديد الاختناق الخاص بك
لا تخمّن. استخدم هذه الأدوات للتحقق من أين يذهب الوقت فعلياً قبل البدء في إجراء تغييرات:
- PageSpeed Insights - يجمع بيانات مستخدمي Chrome الحقيقيين (البيانات الميدانية) مع اختبار مختبري جديد. تفصيل الأجزاء الفرعية لـ LCP هو أكثر عرض قابل للتنفيذ متاح.
- لوحة أداء Chrome DevTools - سجّل تحميل الصفحة وابحث عن علامة LCP في الجدول الزمني. يمكنك رؤية بالضبط متى تم رسم العنصر بالنسبة لبداية التنقل وتحديد ما كان يعمل في تلك اللحظة.
- WebPageTest - يعرض عرض الشلال وقت الاتصال وTTFB ووقت التنزيل لكل مورد بشكل فردي. قم بالتصفية لعنصر LCP الخاص بك وتتبعه عبر الجدول الزمني.
- تقرير Core Web Vitals في Google Search Console - يعرض بيانات LCP الحقيقية للمستخدمين مقسمة حسب مجموعات URL. مفيد لاكتشاف ما إذا كان LCP البطيء عاماً أم مقتصراً على أنواع معينة من الصفحات.
كيف تبدو استضافة Core Web Vitals الجيدة عملياً
بيئة الاستضافة المحسّنة لـ LCP لها بعض الخصائص الثابتة. تعود الاستجابات المخزنة مؤقتاً في أقل من 100ms. الأصول الثابتة مضغوطة ومنظمة بإصدارات وتُقدَّم بترويسات تخزين مؤقت طويلة. موارد الخادم - CPU وRAM - مخصصة، وليست مشتركة مع عشرات المستأجرين الآخرين. والخادم قريب من الجمهور، أو يجلب CDN الأصول قريبة بما يكفي.
هذه ليست قرارات تخص الواجهة الأمامية. إنها قرارات بنية تحتية. وإذا لم يكن إعدادك الحالي يحقق ذلك، فإن الانتقال إلى منصة تتولى فيها التخزين المؤقت والضغط وإعداد الخادم على مستوى الاستضافة يُحسّن درجات Core Web Vitals في الاستضافة أكثر مما تستطيع أي حملة تحسين للواجهة الأمامية تحقيقه وحدها.
تفصيل LCP الخاص بك سيخبرك بالضبط في أي جانب من هذا الخط أنت. اقرأ المراحل، وحدد الاختناق، وأصلحه في الطبقة الصحيحة. هكذا تتحرك الدرجة فعلاً.
