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

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

Philip Walton

Barry Pollard

تاريخ النشر: 30 نيسان (أبريل) 2020

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

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

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

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

فهم مقياس LCP

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

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

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

استخدام بيانات LCP في Chrome UX في "أدوات مطوّري البرامج في Chrome"

تعرض لوحة "الأداء" في "أدوات مطوّري البرامج في Chrome" تجربة LCP المحلية بجانب LCP في CrUX للصفحة أو المصدر في عرض المقاييس المباشرة.

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

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

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

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

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

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

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

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

استخدام المقاييس التكميلية لخدمة CrUX في أداة "إحصاءات PageSpeed"

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

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

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

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

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

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

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

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

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

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

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

تفاصيل LCP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. تجنُّب مهلة تحميل الموارد

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

من القواعد الأساسية أن يبدأ تحميل مورد 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 مسبقًا باستخدام أولوية استرجاع عالية، على سبيل المثال:

<!-- 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 لصفحتك. ومع ذلك، فإنّ ضبط أولوية عالية على أكثر من صورة أو صورتَين يجعل ضبط الأولوية غير مفيد في تقليل سرعة عرض أكبر جزء من المحتوى على الصفحة.

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

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

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

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

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

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

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

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

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

تقليل عدد ملفات الأنماط التي تحظر عرض الصفحة أو تضمينها

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

لحلّ هذه المشكلة، يمكنك اتّباع أيّ من الخيارَين التاليَين:

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

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

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

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

• إزالة قواعد CSS غير المستخدمة: استخدِم Chrome DevTools للعثور على قواعد 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، هناك ميزتان أساسيتان لميزة SSR:

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

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

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

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

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

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

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

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

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

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

تقليل حجم المرجع

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

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

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

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

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

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

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

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

إزالة وقت الشبكة بالكامل

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

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

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

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

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

من الأسباب الشائعة لبطء وقت استجابة خادم موقع إلكتروني سريع بشكلٍ عام هو وصول الزوّار من خلال عمليات إعادة توجيه متعدّدة، مثل الإعلانات أو الروابط المختصرة. قلِّل دائمًا عدد عمليات إعادة التوجيه التي يجب أن ينتظرها الزائر.

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

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

مراقبة تفاصيل LCP في JavaScript

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

• أكبر Contentful Paint API
• Navigation Timing API
• Resource Timing API

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

على سبيل المثال، تستخدِم لقطة الشاشة التالية طريقة performance.measure() من User Timing API لإضافة أشرطة إلى مسار "المُدد الزمنية" في لوحة "الأداء" في "أدوات مطوّري البرامج في Chrome".

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

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

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

تم إنشاء كلا العرضَين البيانيَين باستخدام التعليمة البرمجية التالية:

const LCP_SUB_PARTS = [
  'Time to first byte',
  'Resource load delay',
  'Resource load duration',
  'Element render delay',
];

new PerformanceObserver((list) => {
  const lcpEntry = list.getEntries().at(-1);
  const navEntry = performance.getEntriesByType('navigation')[0];
  const lcpResEntry = performance
    .getEntriesByType('resource')
    .filter((e) => e.name === lcpEntry.url)[0];

  // Ignore LCP entries that aren't images to reduce DevTools noise.
  // Comment this line out if you want to include text entries.
  if (!lcpEntry.url) return;

  // Compute the start and end times of each LCP sub-part.
  // WARNING! If your LCP resource is loaded cross-origin, make sure to add
  // the `Timing-Allow-Origin` (TAO) header to get the most accurate results.
  const ttfb = navEntry.responseStart;
  const lcpRequestStart = Math.max(
    ttfb,
    // Prefer `requestStart` (if TOA is set), otherwise use `startTime`.
    lcpResEntry ? lcpResEntry.requestStart || lcpResEntry.startTime : 0
  );
  const lcpResponseEnd = Math.max(
    lcpRequestStart,
    lcpResEntry ? lcpResEntry.responseEnd : 0
  );
  const lcpRenderTime = Math.max(
    lcpResponseEnd,
    // Use LCP startTime (the final LCP time) because there are sometimes
    // slight differences between loadTime/renderTime and startTime
    // due to rounding precision.
    lcpEntry ? lcpEntry.startTime : 0
  );

  // Clear previous measures before making new ones.
  // Note: due to a bug, this doesn't work in Chrome DevTools.
  LCP_SUB_PARTS.forEach((part) => performance.clearMeasures(part));

  // Create measures for each LCP sub-part for easier
  // visualization in the Chrome DevTools Performance panel.
  const lcpSubPartMeasures = [
    performance.measure(LCP_SUB_PARTS[0], {
      start: 0,
      end: ttfb,
    }),
    performance.measure(LCP_SUB_PARTS[1], {
      start: ttfb,
      end: lcpRequestStart,
    }),
    performance.measure(LCP_SUB_PARTS[2], {
      start: lcpRequestStart,
      end: lcpResponseEnd,
    }),
    performance.measure(LCP_SUB_PARTS[3], {
      start: lcpResponseEnd,
      end: lcpRenderTime,
    }),
  ];

  // Log helpful debug information to the console.
  console.log('LCP value: ', lcpRenderTime);
  console.log('LCP element: ', lcpEntry.element, lcpEntry.url);
  console.table(
    lcpSubPartMeasures.map((measure) => ({
      'LCP sub-part': measure.name,
      'Time (ms)': measure.duration,
      '% of LCP': `${
        Math.round((1000 * measure.duration) / lcpRenderTime) / 10
      }%`,
    }))
  );
}).observe({type: 'largest-contentful-paint', buffered: true});

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

ملخّص

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

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

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

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