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

دليل مفصّل حول كيفية تقسيم 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.

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

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

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

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

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

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

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

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

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

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

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

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

تفاصيل LCP

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

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

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

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

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

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

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

• أكبر Contentful Paint API
• 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 معقّد، ويمكن أن يتأثّر توقيته بعدد من العوامل. ولكن إذا كنت تعتقد أنّ تحسين LCP يدور في الأساس حول تحسين تحميل مورد LCP، يمكن أن يبسّط ذلك الأمور بشكل كبير.

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

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

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