شرح LCP: كيفية تحسينه من أجل SEO

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

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

ما هو LCP وكيف يتم قياسه

Largest Contentful Paint (LCP) هو وقت عرض أكبر عنصر محتوى مرئي في صفحتكم. يمكن أن يكون هذا صورة كبيرة، أو فيديو، أو عنوانًا، أو كتلة نصية. يقيس LCP الفترة من وصول المستخدم إلى صفحتكم حتى يصبح ذلك العنصر مرئيًا. يوفر توثيق Google الخاص بـ LCP معلومات تقنية مفصلة واستراتيجيات تحسين.

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

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

فهم Time to First Byte (TTFB)

Time to First Byte (TTFB) هو الوقت الفاصل بين بداية التنقل ولحظة إرجاع الخادم لأول بايت من مستند HTML. يحدد TTFB الحد الأدنى الذي لا يمكن أن يقل عنه LCP. فإذا كان TTFB ثانيتين، لا يمكن أن يكون LCP أفضل من ثانيتين لأن المتصفح لم يستلم بعد ملف HTML. تقليل TTFB شرط أساسي لتقليل LCP.

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

الأسباب الشائعة لبطء TTFB: كود الواجهة الخلفية غير الفعال، أو استعلامات قاعدة البيانات، أو الحمل الزائد على الخادم. الاستضافة البطيئة تسبب أيضًا ارتفاعًا في TTFB. غالبًا ما تكون الاستضافة المشتركة بطيئة جدًا. قوموا بالترقية إلى VPS أو استضافة سحابية لأداء أفضل. استخدموا CDN لتقليل TTFB من خلال تقديم المحتوى من خوادم قريبة من مستخدميكم.

يعرض PageSpeed Insights قيمة TTFB لديكم في قسم "وقت استجابة الخادم". إذا كان TTFB يمثل اختناقًا، فسيتم تمييزه كأولوية.

تحديد أكبر عنصر محتوى

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

استخدموا Chrome DevTools لتحديد عنصر LCP. افتحوا DevTools، وانتقلوا إلى تبويب Performance، وابدأوا التسجيل، وأعيدوا تحميل الصفحة. في تسجيل Performance، ابحثوا عن علامة "Largest Contentful Paint". مرروا المؤشر فوقها لمعرفة أي عنصر تسبب في LCP. بمجرد معرفة العنصر، قوموا بتحسينه.

غالبًا ما يكون عنصر LCP صورة. الصور كبيرة الحجم وتُحمَّل بعد تحليل HTML. تحسين تحميل الصور له أكبر تأثير على LCP في معظم المواقع. يمكن تحميل الصور الموجودة أسفل الشاشة المرئية بشكل مؤجل (lazy loading)، مما يسرّع LCP للمحتوى الظاهر أعلى الشاشة.

التحميل المسبق للموارد الحيوية

يخبر التحميل المسبق (preload) المتصفح ببدء تنزيل مورد مبكرًا، قبل الحاجة إليه في العرض. قوموا بالتحميل المسبق لصورة LCP أو الموارد الحيوية الأخرى باستخدام وسوم `` في رأس HTML. هذا يخبر المتصفح بـ"بدء تنزيل هذا المورد فورًا".

مثال: `` يخبر المتصفح ببدء تنزيل الصورة الرئيسية فورًا، دون انتظار تحليل CSS. يمكن أن يقلل هذا LCP بمقدار 100 إلى 500 ميلي ثانية حسب حجم المورد.

كونوا حذرين مع التحميل المسبق. فالتحميل المسبق لعدد كبير جدًا من الموارد يهدر عرض النطاق الترددي. قوموا بالتحميل المسبق فقط للموارد الأكثر أهمية (الصورة الرئيسية، الخطوط الحيوية، CSS الأساسي). يشرح دليل Google لتحسين Core Web Vitals أفضل ممارسات التحميل المسبق.

تحسين الصور من أجل LCP

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

اضغطوا الصورة. استخدموا أدوات مثل TinyPNG أو ImageOptim أو Squoosh للضغط دون فقدان الجودة. يمكن أن يقلل ضغط JPEG حجم الملف بمقدار 10 إلى 40 مرة. كل 100 كيلوبايت من حجم الصورة يضيف 100 إلى 200 ميلي ثانية إلى LCP على شبكات 4G. الضغط استثمار عالي العائد.

استخدموا الصيغ الحديثة. يُعد WebP أصغر بنسبة 25 إلى 35% من JPEG. أما AVIF فهو أصغر حتى من ذلك. استخدموا عنصر HTML من نوع `` لتقديم WebP للمتصفحات الحديثة وJPEG للمتصفحات القديمة من أجل التوافق مع الإصدارات السابقة. اختيار الصيغة وحده يمكن أن يحسّن LCP بمقدار 200 إلى 400 ميلي ثانية.

حددوا أبعاد الصورة. يمنع تضمين خاصيتي width وheight حدوث layout shift ويسمح للمتصفح بحجز المساحة قبل تحميل الصورة. هذا لا يحسّن LCP بشكل مباشر، لكنه يحسّن Cumulative Layout Shift (CLS)، وهو مقياس آخر من مقاييس Core Web Vitals.

CSS وJavaScript المعيقان للعرض

يمنع CSS المعيق للعرض المتصفح من عرض الصفحة إلى أن يتم تنزيل CSS وتحليله. تؤخر ملفات CSS الكبيرة عملية العرض. قللوا من CSS المعيق للعرض من خلال تضمين CSS الحيوي مباشرة وتأجيل الباقي.

CSS الحيوي هو CSS اللازم للمحتوى الظاهر أعلى الشاشة. قوموا بتضمين هذا الـCSS مباشرة في وسوم `