تحسين سرعة عرض أكبر جزء من المحتوى على الصفحة

دليل تفصيلي حول كيفية تقسيم مقياس LCP وتحديد المجالات الرئيسية التي يجب تحسينها

Philip Walton

Barry Pollard

تاريخ النشر: 30 أبريل 2020، تاريخ آخر تعديل: 31 مارس 2025

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

لتقديم تجربة جيدة للمستخدم، يجب أن تسعى المواقع الإلكترونية إلى أن تكون قيمة LCP بمعدّل 2.5 ثانية أو أقلّ لما لا يقل عن% 75 من زيارات الصفحة.

يمكن أن تؤثّر عدة عوامل في سرعة تحميل المتصفّح لصفحة ويب وعرضها، ويمكن أن يكون للتأخير في أيّ من هذه العوامل تأثير كبير في سرعة عرض أكبر محتوى مرئي.

من النادر أن يؤدّي إصلاح سريع لجزء واحد من الصفحة إلى تحسُّن مُجدٍ في سرعة LCP. لتحسين سرعة LCP، عليك مراجعة عملية التحميل بأكملها والتأكّد من تحسين جميع خطوات العملية.

فهم مقياس سرعة عرض أكبر محتوى مرئي (LCP)

قبل تحسين مقياس LCP، على المطوّرين محاولة معرفة ما إذا كانت لديهم مشكلة في هذا المقياس، ومدى هذه المشكلة.

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

يمكن عرض بيانات LCP المستندة إلى المستخدمين الفعليين من أدوات "مراقبة المستخدم الفعلي" (RUM) المثبَّتة على موقع إلكتروني، أو باستخدام تقرير تجربة المستخدم على Chrome (CrUX) الذي يجمع بيانات مجهولة الهوية من مستخدمي Chrome الفعليين لملايين المواقع الإلكترونية.

استخدام بيانات LCP من تقرير تجربة المستخدم على Chrome في أدوات مطوّري البرامج في Chrome

تعرض لوحة "الأداء" في "أدوات مطوّري البرامج في Chrome" تجربة LCP المحلية بجانب مقياس LCP في CrUX للصفحة أو المصدر في عرض المقاييس المباشرة، وفي الإحصاءات الخاصة بتتبُّع الأداء، بما في ذلك تفصيل لأوقات الأجزاء الفرعية من LCP (سنشرحها قريبًا).

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

استخدام بيانات LCP من CrUX في "إحصاءات PageSpeed"

توفّر إحصاءات PageSpeed إمكانية الوصول إلى بيانات CrUX في القسم العلوي الذي يحمل العنوان التعرّف على تجربة المستخدمين. تتوفّر بيانات أكثر تفصيلاً مستندة إلى المختبر في القسم السفلي الذي يحمل العنوان تشخيص مشاكل الأداء. إذا كانت بيانات CrUX متاحة لموقعك الإلكتروني، ركِّز دائمًا على بيانات المستخدمين الفعليين أولاً.

تعرض "إحصاءات PageSpeed" ما يصل إلى أربعة أنواع مختلفة من بيانات CrUX:

• بيانات الأجهزة الجوّالة الخاصة بعنوان URL هذا
• بيانات هذا العنوان على أجهزة الكمبيوتر
• بيانات الجوّال الخاصة بـ Origin بأكملها
• بيانات الكمبيوتر للمصدر بأكمله

يمكنك تفعيل هذه الخيارات أو إيقافها في عناصر التحكّم في أعلى هذا القسم وفي أعلى يساره. إذا لم يتضمّن عنوان URL بيانات كافية لعرضها على مستوى عنوان URL، ولكنّه يتضمّن بيانات للمصدر، تعرض "إحصاءات PageSpeed" دائمًا بيانات المصدر.

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

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

استخدام المقاييس التكميلية لتقرير تجربة المستخدم على Chrome في إحصاءات PageSpeed

على من يريد تحسين سرعة عرض أكبر محتوى مرئي (LCP) أن يستخدم أيضًا توقيتات سرعة عرض أول محتوى مرئي (FCP) ومدة تحميل أول بايت (TTFB)، وهما مقياسان تشخيصيان جيدان يمكن أن يقدّما إحصاءات قيّمة حول سرعة عرض أكبر محتوى مرئي.

يشير TTFB إلى الوقت المستغرَق منذ أن يبدأ الزائر في الانتقال إلى صفحة (مثلاً، النقر على رابط) وحتى يتم تلقّي وحدات البايت الأولى من مستند HTML. يمكن أن يؤدي ارتفاع TTFB إلى صعوبة تحقيق LCP يبلغ 2.5 ثانية أو حتى استحالة ذلك.

قد تكون مدة تحميل أول بايت (TTFB) طويلة بسبب عمليات إعادة توجيه متعددة من الخادم، أو بسبب بُعد المسافة بين الزوّار وأقرب خادم للموقع الإلكتروني، أو بسبب سوء حالة الشبكة لدى الزوّار، أو بسبب عدم إمكانية استخدام المحتوى المخزّن مؤقتًا بسبب مَعلمات طلب البحث.

بعد بدء عرض الصفحة، قد يظهر طلاء أولي (مثل لون الخلفية)، يتبعه ظهور بعض المحتوى (مثل رأس الموقع الإلكتروني). يتم قياس ظهور المحتوى الأولي باستخدام مقياس "سرعة عرض أوّل محتوى مرئي". يمكن أن يكون الفرق بين مقياس FCP والمقاييس الأخرى دلالة واضحة.

قد يشير الفرق الكبير بين مقياسَي TTFB وFCP إلى أنّ المتصفّح يحتاج إلى تنزيل الكثير من مواد العرض التي تحظر العرض. ويمكن أن يشير ذلك أيضًا إلى أنّ الموقع الإلكتروني يحتاج إلى إكمال الكثير من العمل لعرض أي محتوى مفيد، وهو مؤشر كلاسيكي على أنّ الموقع الإلكتروني يعتمد بشكل كبير على العرض من جهة العميل.

يشير الفرق الكبير بين مقياسَي FCP وLCP إلى أنّ مصدر LCP إما غير متاح على الفور للمتصفّح لتحديد أولويته (على سبيل المثال، النصوص أو الصور التي تتم إدارتها بواسطة JavaScript بدلاً من توفّرها في HTML الأولي)، أو أنّ المتصفّح يكمل أعمالاً أخرى قبل أن يتمكّن من عرض محتوى LCP.

استخدام بيانات Lighthouse في "إحصاءات PageSpeed"

يقدّم قسم Lighthouse في إحصاءات PageSpeed بعض الإرشادات لتحسين سرعة عرض أكبر محتوى مرئي (LCP)، ولكن عليك أولاً التحقّق مما إذا كانت سرعة عرض أكبر محتوى مرئي (LCP) المقدَّمة تتوافق بشكل عام مع بيانات المستخدمين الحقيقيين التي يوفّرها تقرير تجربة المستخدم على Chrome. إذا كان هناك اختلاف بين Lighthouse وCrUX، من المرجّح أنّ CrUX يقدّم صورة أكثر دقة عن تجربة المستخدم. تأكَّد من أنّ بيانات CrUX تخص صفحتك وليس المصدر الكامل قبل اتّخاذ أي إجراء بشأنها.

إذا أظهر كلّ من Lighthouse وتقرير تجربة المستخدم على Chrome قيمًا لمقياس سرعة عرض أكبر محتوى مرئي (LCP) تحتاج إلى تحسُّن، يمكن أن يقدّم قسم Lighthouse إرشادات قيّمة حول طرق تحسين مقياس سرعة عرض أكبر محتوى مرئي (LCP). استخدِم فلتر LCP لعرض عمليات التدقيق ذات الصلة بمقياس LCP فقط، وذلك باتّباع الخطوات التالية:

بالإضافة إلى فرص التحسين، تتوفّر معلومات تشخيصية قد تقدّم المزيد من المعلومات للمساعدة في تشخيص المشكلة. تعرض أداة تشخيص عنصر سرعة عرض أكبر محتوى مرئي تقسيمًا مفيدًا لمختلف التوقيتات التي شكّلت مقياس LCP:

تتوفّر أيضًا أنواع ومكونات فرعية لموارد LCP في CrUX.

سنتناول هذه الأجزاء الفرعية بالتفصيل في ما يلي.

تفاصيل سرعة عرض أكبر محتوى مرئي (LCP)

قد يكون تحسين سرعة عرض أكبر محتوى مرئي (LCP) مهمة أكثر تعقيدًا عندما لا تقدّم لك أداة إحصاءات PageSpeed إجابة عن كيفية تحسين هذا المقياس. في ما يتعلّق بالمهام المعقّدة، من الأفضل عمومًا تقسيمها إلى مهام أصغر يسهل تنفيذها ومعالجة كل مهمة على حدة.

يعرض هذا القسم منهجية حول كيفية تقسيم مقياس LCP إلى أجزائه الفرعية الأكثر أهمية، ثم تقديم اقتراحات وأفضل الممارسات المحددة حول كيفية تحسين كل جزء.

تتضمّن معظم عمليات تحميل الصفحات عادةً عددًا من طلبات الشبكة، ولكن لأغراض تحديد فرص تحسين مقياس LCP، يجب أن تبدأ بالاطّلاع على طلبَين فقط:

1. مستند HTML الأوّلي
2. مصدر LCP (إن وُجد)

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

لتحديد مورد LCP، يمكنك استخدام أدوات المطوّرين (مثل إحصاءات PageSpeed التي تمّت مناقشتها سابقًا أو أدوات مطوّري البرامج في Chrome أو WebPageTest) لتحديد عنصر LCP. من هناك، يمكنك مطابقة عنوان URL (مرة أخرى، إذا كان ذلك منطبقًا) الذي تم تحميله بواسطة العنصر في مخطط تسلسلي للشبكة لجميع الموارد التي تم تحميلها بواسطة الصفحة.

على سبيل المثال، يعرض التصوّر التالي هذه الموارد مميّزة في مخطط تسلسلي للشبكة من عملية تحميل نموذجية للصفحة، حيث يتطلّب عنصر LCP طلب صورة لعرضه.

للحصول على صفحة محسّنة بشكل جيد، عليك أن تبدأ تحميل طلب مورد LCP في أقرب وقت ممكن، وأن تعرض عنصر LCP بأسرع ما يمكن بعد انتهاء تحميل مورد LCP. للمساعدة في توضيح ما إذا كانت صفحة معيّنة تتّبع هذا المبدأ أم لا، يمكنك تقسيم إجمالي وقت سرعة عرض أكبر محتوى مرئي إلى الأجزاء الفرعية التالية:

مدة تحميل أول بايت (TTFB)

الوقت المنقضي منذ أن يبدأ المستخدم تحميل الصفحة إلى أن يتلقّى المتصفّح أول بايت من استجابة مستند HTML.

مهلة تحميل الموارد

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

مدة تحميل المورد

مدة تحميل مورد LCP نفسه. إذا كان العنصر LCP لا يتطلّب تحميل مورد لعرضه، يكون هذا الوقت 0.

مهلة عرض العناصر

الوقت بين انتهاء تحميل مورد LCP وعرض عنصر LCP بالكامل

يمكن تقسيم قيمة سرعة عرض أكبر محتوى مرئي (LCP) لكل صفحة إلى هذه الأجزاء الفرعية الأربعة. ولا يوجد تداخل أو فجوة بينهما. ويشكّل مجموعها وقت عرض أكبر جزء من المحتوى على الصفحة (LCP) الكامل.

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

على سبيل المثال، في مخطط تسلسل الشبكة السابق، إذا قلّلت حجم ملف الصورة من خلال ضغطه بشكل أكبر أو التبديل إلى تنسيق أكثر فعالية (مثل AVIF أو WebP)، سيؤدي ذلك إلى تقليل مدة تحميل المورد، ولكن لن يؤدي ذلك في الواقع إلى تحسين سرعة عرض أكبر محتوى مرئي لأنّ الوقت سينتقل ببساطة إلى الجزء الفرعي تأخير عرض العنصر:

ويحدث ذلك لأنّه في هذه الصفحة، يكون عنصر LCP مخفيًا إلى أن ينتهي تحميل رمز JavaScript، ثم يتم الكشف عن كل شيء مرة واحدة.

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

أوقات الأجزاء الفرعية المثالية

لتحسين كل جزء فرعي من LCP، من المهم فهم التقسيم المثالي لهذه الأجزاء الفرعية على صفحة محسّنة بشكل جيد.

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

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

في ما يلي طريقة جيدة للتفكير في تقسيم وقت LCP:

• يجب أن يتم قضاء الغالبية العظمى من وقت عرض أكبر محتوى مرئي (LCP) في تحميل مستند HTML ومصدر LCP.
• في أي وقت قبل اكتمال مقياس LCP، إذا كان أحد هذين المَوردَين لا يتم تحميله، يكون ذلك فرصة للتحسين.

كيفية تحسين كل جزء

بعد أن فهمت كيفية تقسيم أوقات الأجزاء الفرعية من LCP في صفحة محسّنة بشكل جيد، يمكنك البدء في تحسين صفحاتك.

ستقدّم الأقسام الأربعة التالية اقتراحات وأفضل الممارسات حول كيفية تحسين كل جزء. ويتم عرضها بالترتيب، بدءًا من التحسينات التي من المحتمل أن يكون لها أكبر تأثير.

1. إزالة مهلة تحميل الموارد

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

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

بشكل عام، هناك عاملان يؤثران في سرعة تحميل مورد LCP:

• عند العثور على المرجع
• تحدّد هذه السمة الأولوية التي يتم منحها للمورد.

التحسين عند العثور على المورد

لضمان بدء تحميل مورد LCP في أقرب وقت ممكن، من المهم أن يتمكّن ماسح التحميل المُسبق في المتصفّح من العثور على المورد في استجابة مستند HTML الأولية. على سبيل المثال، في الحالات التالية، يمكن للمتصفّح اكتشاف مورد LCP من خلال فحص استجابة مستند HTML:

• عنصر LCP هو عنصر <img>، وتتوفّر سمتا src أو srcset في ترميز HTML الأوّلي.
• يتطلّب عنصر LCP صورة خلفية CSS، ولكن يتم تحميل هذه الصورة مسبقًا باستخدام <link rel="preload"> في ترميز HTML (أو باستخدام عنوان Link).
• عنصر LCP هو عقدة نصية تتطلّب خط ويب لعرضها، ويتم تحميل الخط باستخدام <link rel="preload"> في ترميز HTML (أو باستخدام عنوان Link).

في ما يلي بعض الأمثلة التي لا يمكن فيها العثور على مورد LCP من خلال فحص استجابة مستند HTML:

• عنصر LCP هو <img> تتم إضافته بشكل ديناميكي إلى الصفحة باستخدام JavaScript.
• يتم تحميل عنصر LCP بشكل غير متزامن باستخدام مكتبة JavaScript تخفي سمات src أو srcset (غالبًا ما تكون data-src أو data-srcset).
• يتطلّب عنصر LCP صورة خلفية بتنسيق CSS.

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

للتخلّص من تأخير تحميل الموارد غير الضرورية، يجب أن يكون من الممكن العثور على مورد LCP من مصدر HTML. في الحالات التي تتم فيها الإشارة إلى المورد من ملف CSS أو JavaScript خارجي فقط، يجب التحميل المُسبَق لمورد LCP بأولوية جلب عالية fetch priority، على سبيل المثال:

<!-- Load the stylesheet that will reference the LCP image. -->
<link rel="stylesheet" href="/path/to/styles.css">

<!-- Preload the LCP image with a high fetchpriority so it starts loading with the stylesheet. -->
<link rel="preload" fetchpriority="high" as="image" href="/path/to/hero-image.webp" type="image/webp">

تحسين الأولوية الممنوحة للمورد

حتى إذا كان من الممكن اكتشاف مورد LCP من ترميز HTML، قد لا يزال لا يبدأ التحميل في وقت مبكر مثل المورد الأول. يمكن أن يحدث ذلك إذا لم تتعرّف إرشادات الأولوية في أداة فحص التحميل المُسبَق للمتصفّح على أنّ المورد مهم، أو إذا رأت أنّ موارد أخرى أكثر أهمية.

على سبيل المثال، يمكنك تأخير صورة LCP باستخدام HTML إذا ضبطت loading="lazy" على العنصر <img>. يعني استخدام التحميل الكسول أنّه لن يتم تحميل المورد إلا بعد أن يؤكّد التنسيق أنّ الصورة تظهر في إطار العرض، وبالتالي قد يبدأ التحميل في وقت لاحق مما كان سيحدث في حال عدم استخدام هذه الطريقة.

حتى بدون التحميل الكسول، لا تحمّل المتصفحات الصور في البداية بأعلى أولوية لأنّها ليست من الموارد التي تحظر العرض. يمكنك إعطاء تلميح للمتصفّح بشأن الموارد الأكثر أهمية باستخدام السمة fetchpriority للموارد التي يمكن أن تستفيد من أولوية أعلى:

<img fetchpriority="high" src="/path/to/hero-image.webp">

ننصحك بتعيين fetchpriority="high" على عنصر <img> إذا كنت تعتقد أنّه من المحتمل أن يكون عنصر LCP في صفحتك. ومع ذلك، إذا تم ضبط أولوية عالية لأكثر من صورة أو اثنتين، لن يكون ضبط الأولوية مفيدًا في تقليل مقياس LCP.

يمكنك أيضًا خفض أولوية الصور التي قد تظهر في بداية ردّ المستند ولكنّها غير مرئية بسبب التنسيق، مثل الصور في شرائح لوحة العرض الدوّارة التي لا تظهر عند بدء التشغيل:

<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">

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

بعد تحسين أولوية مورد LCP ووقت اكتشافه، من المفترض أن يبدو العرض بدون انقطاع على شبكتك على النحو التالي (مع بدء مورد LCP في الوقت نفسه الذي يبدأ فيه المورد الأول):

2. إزالة مهلة عرض العناصر

الهدف من هذه الخطوة هو التأكّد من أنّ عنصر LCP يمكن عرضه على الفور بعد انتهاء تحميل المورد، بغض النظر عن وقت حدوث ذلك.

السبب الرئيسي لعدم إمكانية عرض عنصر LCP فور انتهاء تحميل المورد هو حظر العرض لسبب آخر:

• يتم حظر عرض الصفحة بالكامل بسبب أوراق الأنماط أو النصوص البرمجية المتزامنة في <head> التي لا تزال قيد التحميل.
• انتهى تحميل مورد LCP، ولكن لم تتم إضافة عنصر LCP إلى DOM بعد (ينتظر تحميل بعض رموز JavaScript).
• يتم إخفاء العنصر بواسطة رمز برمجي آخر، مثل مكتبة اختبار A/B التي لا تزال تحدّد التجربة التي يجب أن يشارك فيها المستخدم.
• تم حظر سلسلة التعليمات الرئيسية بسبب المهام الطويلة، ويجب أن تنتظر عملية العرض إلى أن تكتمل هذه المهام الطويلة.

توضّح الأقسام التالية كيفية معالجة الأسباب الأكثر شيوعًا لتأخّر عرض العناصر غير الضرورية.

تقليل أوراق الأنماط التي تحظر عرض المحتوى أو تضمينها

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

لحلّ هذه المشكلة، يمكنك إجراء أحد الإجراءَين التاليَين:

• تضمين ورقة الأنماط في HTML لتجنُّب طلب الشبكة الإضافي
• تقليل حجم ورقة الأنماط

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

في معظم الحالات، أفضل طريقة لضمان عدم حظر ورقة الأنماط لعرض عنصر LCP هي تقليل حجمها ليكون أصغر من مصدر LCP. من المفترض أن يضمن ذلك عدم حدوث اختناق في معظم الزيارات.

في ما يلي بعض الاقتراحات لتقليل حجم ورقة الأنماط:

• إزالة CSS غير المستخدَمة: استخدِم "أدوات مطوّري البرامج في Chrome" للعثور على قواعد CSS غير المستخدَمة والتي يمكن إزالتها (أو تأجيلها).
• تأجيل CSS غير المهم: قسِّم ورقة الأنماط إلى أنماط مطلوبة لتحميل الصفحة الأولي، ثم أنماط يمكن تحميلها بشكل غير متزامن.
• تصغير ملفات CSS وضغطها: بالنسبة إلى الأنماط المهمة، احرص على تقليل حجم النقل قدر الإمكان.

تأجيل أو تضمين JavaScript الذي يحظر العرض

من النادر جدًا أن يكون من الضروري إضافة نصوص برمجية متزامنة (نصوص برمجية بدون السمتَين async أو defer) إلى <head> صفحاتك، وسيؤدي ذلك دائمًا تقريبًا إلى تأثير سلبي في الأداء.

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

<head>
  <script src="/path/to/main.js"></script>
</head>

<head>
  <script>
    // Inline script contents directly in the HTML.
    // IMPORTANT: only do this for very small scripts.
  </script>
</head>

استخدام العرض من جهة الخادم

العرض من جهة الخادم (SSR) هو عملية تنفيذ منطق تطبيقك من جهة العميل على الخادم والاستجابة لطلبات مستندات HTML باستخدام ترميز HTML الكامل.

من منظور تحسين مقياس LCP، هناك ميزتان أساسيتان لعرض المحتوى من جهة الخادم:

• ستكون موارد الصور قابلة للاكتشاف من مصدر HTML (كما هو موضّح في الخطوة 1 أعلاه).
• لن يتطلّب محتوى صفحتك طلبات JavaScript إضافية لإكماله قبل أن يتمكّن من العرض.

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

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

تقسيم المهام الطويلة

حتى إذا اتّبعت النصائح الواردة سابقًا، ولم يكن رمز JavaScript يحظر العرض أو مسؤولاً عن عرض العناصر، يمكن أن يؤدي ذلك إلى تأخير مقياس LCP.

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

تعرض جميع المتصفحات اليوم الصور على سلسلة التعليمات الرئيسية، ما يعني أنّ أي شيء يحظر سلسلة التعليمات الرئيسية يمكن أن يؤدي أيضًا إلى تأخير غير ضروري في عرض العناصر.

3- تقليل مدة تحميل الموارد

الهدف من هذه الخطوة هو تقليل الوقت المستغرَق في نقل وحدات البايت الخاصة بالمرجع عبر الشبكة إلى جهاز المستخدم. بشكل عام، هناك أربع طرق لإجراء ذلك:

• يجب تقليل حجم المورد.
• تقليل المسافة التي يجب أن يقطعها المورد
• تقليل التنازع على معدّل نقل البيانات على الشبكة
• إزالة وقت الشبكة بالكامل

تقليل حجم المورد

سيكون مصدر مقياس LCP لصفحة ما (إذا كان لديها مصدر) إما صورة أو خط ويب. تقدّم الأدلة التالية تفاصيل وافية حول كيفية تقليل حجم كلّ من:

• عرض حجم الصورة الأمثل
• استخدام تنسيقات الصور الحديثة
• ضغط الصور
• تصغير حجم خط الويب

تقليل المسافة التي يجب أن تقطعها الموارد

بالإضافة إلى تقليل حجم المورد، يمكنك أيضًا تقليل أوقات التحميل من خلال تقريب خوادمك جغرافيًا من المستخدمين قدر الإمكان. وأفضل طريقة لإجراء ذلك هي استخدام شبكة توصيل المحتوى (CDN).

تُعدّ شبكات توصيل المحتوى (CDN) الخاصة بالصور مفيدة بشكل خاص لأنّها لا تقلّل المسافة التي يجب أن تقطعها الموارد فحسب، بل تقلّل أيضًا حجم الموارد بشكل عام، وتطبّق تلقائيًا جميع اقتراحات تقليل الحجم التي ذكرناها سابقًا.

تقليل التنافس على معدل نقل البيانات على الشبكة

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

إذا منحت مورد LCP أولوية عالية fetchpriority وبدأت تحميله في أقرب وقت ممكن، سيبذل المتصفّح قصارى جهده لمنع الموارد ذات الأولوية الأقل من التنافس معه. ومع ذلك، إذا كنت تحمّل العديد من الموارد التي تتضمّن قيمة fetchpriority عالية، أو إذا كنت تحمّل الكثير من الموارد بشكل عام، قد يؤثّر ذلك في سرعة تحميل مورد LCP.

إلغاء وقت الشبكة بالكامل

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

إذا كان المورد الذي يساهم في LCP هو خط ويب، بالإضافة إلى تقليل حجم خط الويب، عليك أيضًا التفكير في ما إذا كنت بحاجة إلى حظر العرض عند تحميل مورد خط الويب. إذا ضبطت قيمة font-display على أي قيمة أخرى غير auto أو block، سيظل النص مرئيًا دائمًا أثناء التحميل، ولن يتم حظر مقياس LCP بسبب طلب شبكة إضافي.

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

4. تقليل مدة تحميل أول بايت

الهدف من هذه الخطوة هو عرض ملف HTML الأوّلي في أسرع وقت ممكن. تم إدراج هذه الخطوة في النهاية لأنّها غالبًا ما تكون الخطوة التي لا يمكن للمطوّرين التحكّم فيها بشكل كبير. ومع ذلك، فهي أيضًا من أهم الخطوات لأنّها تؤثّر بشكل مباشر في كل خطوة تليها. لا يمكن أن يحدث أي شيء في الواجهة الأمامية إلى أن يقدّم الخلفية بايت المحتوى الأول، لذا فإنّ أي إجراء يمكنك اتّخاذه لتسريع مدة تحميل أول بايت (TTFB) سيؤدي أيضًا إلى تحسين كل مقاييس التحميل الأخرى.

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

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

للحصول على إرشادات محدّدة حول تحسين وقت استجابة أول بايت، يمكنك الرجوع إلى دليل تحسين وقت استجابة أول بايت.

مراقبة تفاصيل سرعة عرض أكبر محتوى مرئي (LCP) في JavaScript

تتوفّر لك معلومات التوقيت لجميع الأجزاء الفرعية من LCP التي تمت مناقشتها سابقًا في JavaScript من خلال مجموعة من واجهات برمجة التطبيقات التالية المتعلّقة بالأداء:

• Largest Contentful Paint API
• Navigation Timing API
• Resource Timing API

تحسب العديد من منتجات مراقبة تجربة المستخدم في الوقت الفعلي الأجزاء الفرعية باستخدام واجهات برمجة التطبيقات هذه. تتضمّن مكتبة web-vitals أيضًا توقيتات الأجزاء الفرعية لـ LCP في إنشاء تحديد المصدر، ويمكن الرجوع إلى الرمز الخاص بها لمعرفة كيفية احتساب هذه التوقيتات في JavaScript.

تقيس أدوات مطوّري البرامج في Chrome وLighthouse أيضًا هذه الأجزاء الفرعية كما هو موضّح في لقطات الشاشة السابقة، ما يغنيك عن احتسابها يدويًا في JavaScript عند استخدام هذه الأدوات.

ملخّص

إنّ سرعة عرض أكبر محتوى مرئي (LCP) معقّدة، ويمكن أن يتأثّر توقيتها بعدد من العوامل. ولكن إذا أخذت في الاعتبار أنّ تحسين سرعة LCP يركّز بشكل أساسي على تحسين تحميل مورد LCP، يمكن أن يسهّل ذلك الأمور بشكل كبير.

يمكن تلخيص خطوات تحسين سرعة LCP في أربع خطوات:

1. تأكَّد من بدء تحميل مورد LCP في أقرب وقت ممكن.
2. تأكَّد من إمكانية عرض عنصر LCP فور انتهاء تحميل المورد.
3. قلِّل مدّة تحميل مورد LCP قدر الإمكان بدون التأثير سلبًا في الجودة.
4. عرض مستند HTML الأوّلي بأسرع ما يمكن

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