يشير هذا المصطلح إلى دليل مفصّل حول كيفية تقسيم سرعة LCP وتحديد المجالات التي يجب تحسينها.
سرعة عرض أكبر محتوى مرئي (LCP) هو أحد مقاييس مؤشرات أداء الويب الأساسية الثلاثة، ويمثّل سرعة تحميل المحتوى الرئيسي على صفحة الويب. على وجه التحديد، يقيس LCP الوقت منذ أن يبدأ المستخدم في تحميل الصفحة حتى يتم عرض أكبر صورة أو مقطع نصي ضمن إطار العرض.
لتقديم تجربة جيدة للمستخدم، يجب أن تسعى المواقع الإلكترونية إلى أن تكون سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) تبلغ 2.5 ثانية أو أقل لما لا يقل عن% 75 من زيارات الصفحة.
يمكن أن يؤثر عدد من العوامل في مدى سرعة تحميل المتصفّح لصفحة الويب وعرضها، وقد يكون للتأخيرات في أي منها تأثيرًا كبيرًا على سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP).
من النادر أن يؤدي إصلاح سريع لجزء واحد من الصفحة إلى تحسين ذي مغزى لمقياس LCP. لتحسين سرعة LCP، عليك مراجعة عملية التحميل بأكملها والتأكّد من تحسين جميع الخطوات.
فهم مقياس LCP
قبل تحسين سرعة LCP، يجب أن يسعى المطوّرون إلى معرفة ما إذا كانوا يواجهون مشكلة في سرعة LCP ومدى تأثيرها.
يمكن قياس سرعة LCP من خلال عدد من الأدوات، ولكن ليس جميعها بالطريقة نفسها. لفهم سرعة LCP للمستخدمين الفعليين، يجب أن ننظر إلى هذه التجربة التي يختبرها المستخدمون الفعليون، وليس إلى ما تعرضه أداة مُختبَرة مثل Lighthouse أو الاختبارات المحلية. تقدّم هذه الأدوات المستنِدة إلى المختبرات معلومات وفيرة لشرحها ومساعدتك في تحسين مقياس LCP، ولكن عليك العلم بأنّ الفحوصات المخبرية وحدها قد لا تمثّل بشكل كامل تجربة المستخدمين الفعلية.
يمكن عرض بيانات LCP استنادًا إلى المستخدمين الحقيقيين من خلال أدوات مراقبة المستخدم الفعلي (RUM) المثبَّتة على أحد المواقع الإلكترونية، أو باستخدام تقرير تجربة المستخدم في Chrome الذي يجمع بيانات مجهولة المصدر من مستخدمي Chrome الفعليين لملايين المواقع الإلكترونية.
استخدام بيانات CrUX LCP في "إحصاءات PageSpeed"
توفّر أداة إحصاءات PageSpeed إمكانية الوصول إلى بيانات CrUX في القسم العلوي بعنوان اكتشاف ما يواجهه المستخدمون الحقيقيون. تتوفّر بيانات أكثر تفصيلاً ومستنِدة إلى المختبر في القسم السفلي بعنوان تشخيص مشاكل الأداء. وإذا كانت بيانات تقرير تجربة المستخدم على Chrome متاحة لموقعك الإلكتروني، ركِّز دائمًا على بيانات المستخدمين الحقيقية أولاً.
تعرض "إحصاءات PageSpeed " ما يصل إلى أربع بيانات مختلفة من CrUX:
- بيانات الأجهزة الجوّالة لعنوان URL هذا
- بيانات الكمبيوتر المكتبي لعنوان URL هذا
- بيانات الأجهزة الجوّالة في صفحة المصدر بالكامل
- بيانات الكمبيوتر المكتبي لكامل بيانات المصدر
يمكنك التبديل بين هذه الخيارات من خلال عناصر التحكّم في أعلى وأعلى يسار هذا القسم. إذا كان عنوان URL لا يتضمّن بيانات كافية لعرضه على مستوى عنوان URL، لكنّه يحتوي على بيانات للمصدر، ستعرض "إحصاءات PageSpeed" بيانات المصدر دائمًا.
قد يكون مقياس LCP بالنسبة إلى المصدر الكامل مختلفًا جدًا عن قيمة LCP لصفحة فردية بناءً على كيفية تحميل سرعة LCP على تلك الصفحة مقارنةً بالصفحات الأخرى على ذلك المصدر. وقد يتأثر أيضًا بكيفية انتقال الزوار إلى هذه الصفحات. يميل المستخدمون الجدد إلى زيارة الصفحات الرئيسية، وبالتالي قد يتم تحميلها غالبًا باعتبارها "باردة" بدون أي محتوى مخزَّن مؤقتًا، وبالتالي غالبًا ما تكون الصفحات الأبطأ على الموقع الإلكتروني.
يمكن أن يساعدك الاطّلاع على الفئات الأربع المختلفة لبيانات تقرير تجربة المستخدم على Chrome في معرفة ما إذا كانت مشكلة سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) خاصة بهذه الصفحة أم مشكلة أكثر عمومية على مستوى الموقع الإلكتروني. وبالمثل، يمكن أن تعرِض أنواع الأجهزة التي تتضمّن مشاكل في سرعة LCP.
استخدام المقاييس التكميلية CrUX في "إحصاءات PageSpeed"
على المستخدمين الذين يريدون تحسين سرعة عرض أكبر محتوى مرئي (LCP) استخدام توقيتَي سرعة عرض أكبر جزء من المحتوى على الصفحة (FCP) والوقت المستغرق حتى أول بايت (TTFB)، وهما مقياسان تشخيص جيدان يمكن أن يوفّرا إحصاءات قيّمة حول سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP).
TTFB هو الوقت الذي يبدأ فيه الزائر في الانتقال إلى صفحة (على سبيل المثال، النقر على رابط)، حتى يتم استلام وحدات البايت الأولى من مستند HTML. إنّ ارتفاع مؤشر TTFB قد يجعل تحقيق سرعة عرض أكبر جزء من المحتوى على الصفحة 2.5 ثانية أمرًا صعبًا أو قد يكون مستحيلاً.
يمكن أن يعود السبب في ارتفاع عدد كبير من النقرات على الشبكة إلى حدوث عمليات إعادة توجيه متعددة من جانب الخادم، أو زيارة الزوّار بعيدًا عن أقرب خادم للموقع الإلكتروني، أو الزائرين في ظروف سيئة للشبكة، أو عدم القدرة على استخدام المحتوى المخزَّن مؤقتًا بسبب معلَمات طلب البحث.
بعد بدء عرض الصفحة، قد يكون هناك عرض مبدئي (على سبيل المثال، لون الخلفية)، يليه بعض المحتوى الذي يظهر (على سبيل المثال، عنوان الموقع الإلكتروني). يتم قياس مظهر المحتوى الأولي من خلال مقياس "سرعة عرض المحتوى على الصفحة". إنّ الفرق بين مقياس "سرعة عرض المحتوى على الصفحة" والمقاييس الأخرى قد يكون معبرًا للغاية.
قد يشير وجود دلتا كبير بين TTFB وFCP إلى أنّ المتصفّح يحتاج إلى تنزيل الكثير من مواد العرض التي تحظر العرض. وقد تكون أيضًا إشارة إلى ضرورة إكمال الكثير من العمل لعرض أي محتوى ذي معنى، وهي علامة كلاسيكية على موقع إلكتروني يعتمد بشكل كبير على العرض من جهة العميل.
عند عرض قيمة دلتا كبيرة بين سرعة عرض أكبر محتوى مرئي (FCP) وسرعة عرض أكبر جزء من المحتوى على الصفحة (LCP)، يعني ذلك أنّ مورد سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) غير متاح على الفور للمتصفِّح لمنح الأولوية له (على سبيل المثال، النصوص أو الصور التي تتم إدارتها من خلال JavaScript بدلاً من إتاحتها في محتوى HTML الأولي)، أو إلى أنّ المتصفّح يكمل عملاً آخر قبل أن يتمكن من عرض محتوى سرعة عرض أكبر جزء من المحتوى على الصفحة.
استخدام بيانات PageSpeed Insights Lighthouse
يقدّم قسم Lighthouse في "إحصاءات PageSpeed" بعض الإرشادات لتحسين سرعة LCP، ولكن عليك أولاً التحقّق مما إذا كان مقياس LCP المحدّد متوافقًا على نطاق واسع مع بيانات المستخدمين الحقيقية التي يوفّرها تقرير تجربة المستخدم على Chrome. في حال عدم توافق Lighthouse مع CrUX، من المحتمل أن يقدِّم تقرير CrUX صورة أكثر دقة عن تجربة المستخدم. يجب أن تكون بيانات تقرير CrUX خاصة بصفحتك، وليست للمصدر الكامل، قبل اتخاذ إجراء بشأنها.
إذا أظهرت أداة Lighthouse وCrUX قيم LCP التي تحتاج إلى تحسين، يمكن أن يقدّم قسم Lighthouse إرشادات قيّمة حول طرق تحسين سرعة LCP. يمكنك استخدام فلتر LCP لعرض عمليات التدقيق ذات الصلة بمقياس LCP فقط على النحو التالي:
بالإضافة إلى فرص التحسين التي يمكن تحسينها، تتوفّر معلومات بيانات التشخيص التي قد توفّر المزيد من المعلومات للمساعدة في تشخيص المشكلة. تعرض بيانات التشخيص سرعة عرض أكبر محتوى مرئي تحليلاً مفيدًا للتوقيتات المختلفة التي تضمّنت سرعة عرض أكبر محتوى مرئي:
سنتعمق في هذه الأجزاء الفرعية بعد ذلك.
تقسيم LCP
قد يكون تحسين سرعة LCP مهمة أكثر تعقيدًا عندما لا توفِّر لك "إحصاءات PageSpeed" إجابة عن كيفية تحسين هذا المقياس. مع المهام المعقدة، من الأفضل بشكل عام تقسيمها إلى مهام أصغر وأكثر سهولة في الإدارة ومعالجة كل منها على حدة.
ويستعرض هذا القسم منهجية تقسيم سرعة LCP إلى الأقسام الفرعية الأكثر أهمية لها ثم تقديم توصيات محدّدة وأفضل الممارسات حول كيفية تحسين كل جزء.
عادةً ما تتضمّن معظم عمليات تحميل الصفحات عددًا من طلبات الشبكة، ولكن بهدف تحديد الفرص المتاحة لتحسين سرعة LCP، عليك البدء بالتحقّق من نوعين فقط:
- مستند HTML الأولي
- مورد 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).
عند تحسين سرعة LCP، من المفيد محاولة تحسين هذه الأجزاء الفرعية بشكلٍ فردي. ولكن من المهم أيضًا أن تضع في اعتبارك أنه من الضروري تحسين كل هذه العوامل. وفي بعض الحالات، لن يؤدي التحسين المطبَّق على أحد الأجزاء إلى تحسين سرعة LCP، بل يؤدي فقط إلى تحويل الوقت المحفوظ إلى جزء آخر.
على سبيل المثال، في العرض الإعلاني بدون انقطاع في الشبكة السابق، إذا قلّلت حجم ملف الصورة عن طريق ضغطه أكثر أو التبديل إلى تنسيق أكثر ملاءمة (مثل AVIF أو WebP)، سيؤدي ذلك إلى تقليل مدة تحميل المورد، ولكنه لن يحسّن سرعة LCP لأنّ الوقت سينتقل إلى الجزء الفرعي تأخير عرض العنصر:
والسبب في ذلك هو أنّه في هذه الصفحة يكون عنصر LCP مخفيًا إلى أن ينتهي تحميل رمز JavaScript، ثم يتم الكشف عن كل المعلومات في الوقت نفسه.
يساعدك هذا المثال في توضيح النقطة التي تحتاج إلى تحسين كل هذه الأجزاء الفرعية من أجل تحقيق أفضل نتائج سرعة LCP.
الأوقات المثالية للأجزاء الفرعية
لتحسين كل جزء فرعي من سرعة LCP، من المهم فهم التقسيم المثالي لهذه الأجزاء الفرعية في صفحة محسّنة بشكل جيد.
من بين الأجزاء الفرعية الأربعة، يحتوي اسمان على كلمة "تأخير". هذا دليل على أنك تريد أن تقترب هذه الأوقات من الصفر قدر الإمكان. ويتضمن الجزآن الآخران طلبات الشبكة، والتي تستغرق بطبيعتها بعض الوقت.
يُرجى العِلم أنّ تقسيمات الوقت هذه عبارة عن إرشادات وليست قواعد صارمة. إذا كانت النسب المئوية لمقياس LCP على صفحاتك تتخطى 2.5 ثانية بشكل متّسق، لا يهمّ ذلك. ولكن إذا كنت تقضي الكثير من الوقت غير الضروري في أيٍّ من جانبَي "التأخير"، سيكون من الصعب جدًا تحقيق الهدف 2.5 ثانية باستمرار.
في ما يلي الطرق الجيدة للتفكير في تحليل وقت سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP):
- يجب قضاء معظم وقت سرعة LCP في تحميل مستند HTML ومصدر سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP).
- في حال عدم تحميل أحد هذين المصدرَين قبل سرعة LCP، يكون ذلك فرصة للتحسين.
كيفية تحسين كل جزء
بعد أن فهمت كيف يجب تقسيم كل وقت من الأجزاء الفرعية لسرعة عرض أكبر محتوى مرئي (LCP) على صفحة تم تحسينها بشكل جيد، يمكنك البدء في تحسين صفحاتك الخاصة.
ستقدم الأقسام الأربعة التالية اقتراحات وأفضل الممارسات حول كيفية تحسين كل جزء. ويتم تقديم هذه الاقتراحات بالترتيب، بدءًا من التحسينات التي يُرجّح أن يكون لها أكبر تأثير.
1- إزالة تأخير تحميل الموارد
والهدف من هذه الخطوة هو ضمان بدء تحميل مورد سرعة عرض أكبر جزء من المحتوى على الصفحة في أقرب وقت ممكن. في حين أنّ المورد النظري يمكن بدء تحميل الموارد مباشرة بعد وضع 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 في صفحتك. ومع ذلك، فإنّ ضبط أولوية عالية بأكثر من صورة أو صورتَين يجعل إعداد الأولوية غير مفيد في تقليل سرعة عرض أكبر جزء من المحتوى على الصفحة.
يمكنك أيضًا تقليل أولوية الصور التي قد تكون في وقت مبكر من ردّ المستند ولكنها لا تكون مرئية بسبب التصميم، مثل الصور في شرائح لوحة العرض الدوّارة التي لا تظهر عند بدء التشغيل:
<img fetchpriority="low" src="/path/to/carousel-slide-3.webp">
يمكن أن يؤدي عدم منح الأولوية لموارد معينة إلى توفير سعة أكبر لنقل البيانات للموارد التي تحتاج إليها أكثر — ولكن كن حذرًا. تحقَّق دائمًا من أولوية الموارد في "أدوات مطوري البرامج" واختبِر التغييرات باستخدام الأدوات الاختبارية والميدانية.
بعد تحسين أولوية مورد سرعة عرض أكبر جزء من المحتوى على الصفحة ووقت الاكتشاف، من المفترض أن يظهر العرض الإعلاني بدون انقطاع في الشبكة على النحو التالي (مع بدء مورد سرعة عرض أكبر جزء من المحتوى على الصفحة في نفس وقت المورد الأول):
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 أو تضمينه لحظر عرض محتوى 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 هو أنه يتطلب وقتًا إضافيًا للمعالجة من قِبل الخادم، مما قد يؤدي إلى إبطاء معدل TTFB. وعلى الرغم من ذلك عادةً ما تكون هذه الوسيلة مناسبة لأن أوقات معالجة الخادم تكون تحت سيطرتك، في حين أن إمكانات الشبكة والجهاز لدى المستخدمين ليست كذلك.
يُعرف خيار مماثل لإنشاء المواقع الإلكترونية الثابتة باسم إنشاء المواقع الإلكترونية الثابتة (SSG) أو العرض المُسبَق. هذه هي عملية إنشاء صفحات HTML خطوة بخطوة بدلاً من إنشاء الصفحات عند الطلب. وإذا كان العرض المُسبَق ممكنًا مع البنية الأساسية، يكون بشكلٍ عام اختيارًا أفضل للأداء.
تقسيم المهام الطويلة
حتى إذا كنت قد اتّبعت النصائح السابقة، وتبيّن أنّ رمز JavaScript لا يمنع عرض العناصر وليس مسؤولاً عن عرض العناصر، قد يؤخّر سرعة LCP أيضًا.
السبب الأكثر شيوعًا لحدوث ذلك هو عندما تحمِّل الصفحات ملفات JavaScript كبيرة، والتي تحتاج إلى تحليل وتنفيذها على سلسلة التعليمات الرئيسية للمتصفّح. وهذا يعني أنّه حتى في حال تنزيل مورد الصورة بالكامل، قد يظل عليك الانتظار حتى ينتهي تنفيذ نص برمجي غير ذي صلة قبل أن يتم عرضه.
تعرض جميع المتصفحات حاليًا الصور في سلسلة التعليمات الرئيسية، ما يعني أنّ أي شيء يحظر سلسلة التعليمات الرئيسية قد يؤدي أيضًا إلى تأخير غير ضروري في عرض العنصر.
3- تقليل مدة تحميل الموارد
تهدف هذه الخطوة إلى تقليل الوقت المستغرق في نقل وحدات بايت المورد عبر الشبكة إلى جهاز المستخدم. وبشكل عام، هناك ثلاث طرق لإجراء ذلك:
- قلّل حجم المورد.
- تقليل المسافة التي يجب أن يقطعها المورد.
- تقليل التنافس على معدل نقل البيانات للشبكة.
- حذف وقت الشبكة تمامًا.
تقليل حجم المورد
سيكون مورد LCP للصفحة (في حال توفّره) صورة أو خطًا للويب. تتناول الأدلة التالية قدرًا كبيرًا من التفاصيل حول كيفية تقليل حجم كلٍ منهما:
تقليل المسافة التي يجب أن يقطعها المورد
بالإضافة إلى تقليل حجم المورد، يمكنك أيضًا تقليل أوقات التحميل عن طريق جعل الخوادم أقرب ما يكون إلى المستخدمين من ناحية الموقع الجغرافي. وأفضل طريقة لإجراء ذلك هي استخدام شبكة توصيل المحتوى (CDN).
شبكات توصيل المحتوى (CDN) للصور على وجه الخصوص مفيدة للغاية لأنّها لا تقلّل المسافة التي يجب أن يقطعها المورد فقط، بل تعمل أيضًا على تقليل حجم المورد بشكل عام، ما يؤدي تلقائيًا إلى تنفيذ جميع الاقتراحات السابقة المتعلقة بخفض الحجم.
تقليل التنافس على معدل نقل البيانات للشبكة
حتى إذا قمت بتقليل حجم المورد والمسافة التي ينبغي أن يقطعها، فقد يستغرق تحميل المورد وقتًا طويلاً إذا كنت تقوم بتحميل العديد من الموارد الأخرى في نفس الوقت. وتُعرف هذه المشكلة باسم تزايد الطلب على الشبكات.
إذا اخترت قيمة عالية في fetchpriority لمورد سرعة عرض أكبر جزء من المحتوى على الصفحة وبدأت تحميله في أقرب وقت ممكن، سيبذل المتصفّح قصارى جهده لمنع الموارد ذات الأولوية الأقل من التنافس معه. ومع ذلك، في حال تحميل العديد من الموارد ذات fetchpriority العالي أو تحميل الكثير من الموارد بشكل عام، قد يؤثر ذلك في سرعة تحميل مورد LCP.
التخلص من وقت الشبكة تمامًا
وأفضل طريقة لتقليل مدة تحميل الموارد هي استبعاد الشبكة بالكامل من هذه العملية. إذا كنت تعرض مواردك من خلال سياسة فعّالة للتحكّم في ذاكرة التخزين المؤقت، سيحصل الزوّار الذين يطلبون هذه الموارد للمرة الثانية على عرضها من ذاكرة التخزين المؤقت، ما يؤدي إلى التخلص من مدة تحميل الموارد.
إذا كان مورد LCP عبارة عن خط على الويب، بالإضافة إلى تقليل حجم الخط على الويب، عليك أيضًا التفكير فيما إذا كنت بحاجة إلى حظر العرض على تحميل موارد الخطوط على الويب. في حال ضبط قيمة font-display لأي قيمة أخرى غير auto أو block، سيظهر النص دائمًا أثناء التحميل، ولن يتم حظر سرعة LCP في أي طلب شبكة إضافي.
وأخيرًا، إذا كان مورد سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) صغيرًا، قد يكون من المنطقي تضمين الموارد كعنوان URL للبيانات، ما سيؤدي أيضًا إلى إزالة طلب الشبكة الإضافي. ومع ذلك، يؤدي استخدام عناوين URL للبيانات إلى تنبيهات لأنّه لا يمكن تخزين الموارد مؤقتًا، وفي بعض الحالات يمكن أن يؤدي ذلك إلى تأخّر عرض البيانات بسبب التكلفة الإضافية لفك الترميز.
4. تقليل الوقت للوصول إلى البايت الأول
الهدف من هذه الخطوة هو تقديم رمز HTML الأولي في أسرع وقت ممكن. تأتي هذه الخطوة في النهاية لأنّه غالبًا ما يكون المطوّرون الذين لديهم أقل قدر من التحكّم فيهم. ومع ذلك، فهي أيضًا واحدة من أهم الخطوات لأنها تؤثر بشكل مباشر على كل خطوة تأتي بعدها. لا يمكن أن يحدث أي شيء على الواجهة الأمامية إلى أن ترسل الخلفية هذا البايت الأول من المحتوى، لذا فإن أي شيء يمكنك فعله لتسريع TTFB سيحسن كل مقياس تحميل آخر أيضًا.
من الأسباب الشائعة لبطء TTFB في موقع إلكتروني سريع الاستجابة وصول الزائرين من خلال عمليات إعادة توجيه متعددة، مثل وصولهم من الإعلانات أو الروابط المختصرة. قلل دائمًا من عدد عمليات إعادة التوجيه التي يجب أن ينتظرها الزائر.
ومن الأسباب الشائعة الأخرى تعذُّر استخدام المحتوى المُخزَّن مؤقتًا من خادم حافة شبكة توصيل المحتوى (CDN)، ويجب توجيه جميع الطلبات من جديد إلى خادم المصدر. يمكن أن يحدث ذلك في حال استخدام الزائرين معلَمات عناوين URL الفريدة لإجراء الإحصاءات، حتى لو لم يؤدوا إلى صفحات مختلفة.
للحصول على إرشادات محدّدة عن تحسين TTFB، يمكنك الرجوع إلى دليل تحسين TTFB.
مراقبة تفاصيل LCP في JavaScript
إنّ معلومات التوقيت لجميع الأجزاء الفرعية لسرعة عرض أكبر محتوى مرئي (LCP) التي تمت مناقشتها سابقًا متوفّرة لك في JavaScript من خلال مجموعة من واجهات برمجة التطبيقات للأداء التالية:
تتمثل فائدة احتساب قيم التوقيت هذه في 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 معقّدة، ويمكن أن يتأثر توقيتها بعدد من العوامل. في المقابل، إذا كنت تعتقد أنّ تحسين سرعة عرض أكبر جزء من المحتوى على الصفحة تتمحور في الأساس حول تحسين تحميل مورد سرعة عرض أكبر جزء من المحتوى على الصفحة، يمكن أن يساعد ذلك في تبسيط الأمور بشكل كبير.
يمكن تلخيص عملية تحسين سرعة LCP في أربع خطوات:
- تأكَّد من بدء تحميل مورد LCP في أقرب وقت ممكن.
- تأكَّد من إمكانية عرض عنصر LCP فور انتهاء تحميل المورد.
- قلِّل وقت تحميل مورد LCP قدر الإمكان بدون التأثير في الجودة.
- أرسِل مستند HTML الأولي في أسرع وقت ممكن.
إذا كان بإمكانك اتّباع هذه الخطوات على صفحاتك، يجب أن تكون واثقًا من أنّك تقدّم تجربة تحميل مثالية للمستخدمين، ويجب أن يظهر ذلك في نتائج سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) الفعلية.