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

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

Philip Walton

Barry Pollard

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

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

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

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

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

فهم مقياس LCP

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

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

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

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

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

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

• بيانات الجوّال لـ عنوان URL هذا
• بيانات سطح المكتب لعنوان URL هذا
• بيانات الجوّال لـ المصدر بأكمله
• بيانات الكمبيوتر المكتبي المتعلقة بالمصدر بالكامل

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

تفاصيل مقياس LCP

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

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

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

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

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

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

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

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

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

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

تأخُّر تحميل الموارد

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

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

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

التأخير في عرض العنصر

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

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

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

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

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

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

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

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

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

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

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

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

• يجب أن يتمّ قضاء الغالبية العظمى من وقت LCP في تحميل مستند HTML ومصدر 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 مسبقًا مع أولوية جلب عالية، على سبيل المثال:

<!-- 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 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 الأوّلي في أسرع وقت ممكن. يتم إدراج هذه الخطوة أخيرًا لأنّها غالبًا ما يكون لدى المطوّرين أقل قدر من التحكّم. ومع ذلك، فهي أيضًا من أهم الخطوات لأنّها تؤثّر بشكل مباشر في كل خطوة تأتي بعدها. لا يمكن أن يحدث أيّ شيء في الواجهة الأمامية إلى أن تُرسِل الواجهة الخلفية أول بايت من المحتوى، لذا فإنّ أيّ إجراء يمكنك اتّخاذه لتسريع وقت استجابة الخادم سيؤدي إلى تحسين كل مقياس تحميل آخر أيضًا.

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

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

للحصول على إرشادات محدّدة عن تحسين TTFB، يُرجى الرجوع إلى دليل تحسين TTFB.

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

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

• أكبر واجهة برمجة تطبيقات لـ Contentful Paint
• Navigation Timing API
• واجهة برمجة تطبيقات Resource Timing

وتتمثّل فائدة احتساب قيم التوقيت هذه في 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 باستخدام "أدوات مطوري البرامج في Chrome"

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

ملخّص

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

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

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

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