يمكن أن يكون تحسين سرعة عرض أكبر محتوى مرئي (LCP) للصفحة أمرًا معقّدًا، إذ ينطوي ذلك غالبًا على عدة عناصر متغيّرة ومفاضلات. تتناول هذه المشاركة البيانات الميدانية من عمليات تحميل الصفحات الفعلية على الويب لتحديد المواضع التي يجب أن يركز فيها المطوّرون جهودهم في التحسين.
نصيحة LCP الكلاسيكية: تقليل حجم الصور
في معظم الصفحات على الويب، يكون عنصر LCP صورة. من الطبيعي إذًا افتراض أنّ أفضل طريقة لتحسين مقياس LCP هي تحسين صورة LCP.
في السنوات الخمس أو نحو ذلك التي تم فيها تقديم LCP، كان هذا غالبًا هو النص الرئيسي للنصيحة. تأكَّد من أنّ حجم صورك مناسب ومضغوط بشكل كافٍ، ويمكنك استخدام تنسيق صور من القرن الحادي والعشرين. تتضمّن أداة Lighthouse أيضًا ثلاثة عمليات تدقيق مختلفة لتقديم هذه الاقتراحات.
ويعود سبب شيوع هذه النصيحة إلى أنّه من السهل قياس عدد البايتات الزائدة واقتراح أدوات ضغط الصور. وقد يكون من السهل أيضًا تنفيذها، وذلك استنادًا إلى مسارات الإنشاء والنشر.
إذا كان الأمر كذلك، يُرجى إجراء ذلك. إنّ إرسال عدد أقل من البايتات إلى المستخدمين يُعدّ أمرًا جيدًا في معظم الأحيان. هناك العديد من المواقع الإلكترونية على الويب التي لا تزال تعرض صورًا كبيرة جدًا بدون داعٍ، ويمكن حلّ هذه المشكلة من خلال ضغط الصور بشكل أساسي.
ومع ذلك، عندما بدأنا في الاطّلاع على بيانات الأداء الميداني للمستخدمين في Chrome لمعرفة الوقت الذي يتم عادةً خلاله قياس LCP، تبيّن لنا أنّ وقت تنزيل الصور لا يشكّل أبدًا عائقًا.
بدلاً من ذلك، تشكّل أجزاء أخرى من LCP مشكلة أكبر بكثير.
تفاصيل المكوّنات الفرعية لمقياس LCP
لفهم أكبر الفرص المتاحة لتحسين سرعة LCP، اطّلعنا على البيانات الواردة من الأجزاء الفرعية لسرعة LCP، كما هو موضّح في مقالة تحسين سرعة LCP.
على الرغم من أنّ كل صفحة وإطار عمل قد يتّبعون نهجًا مختلفًا لتحميل وعرض ما يصبح عنصر LCP للصفحة، يمكن تقسيم كل صفحة إلى الأجزاء الفرعية التالية:
اقتباس من هذه المقالة: الأجزاء الفرعية هي:
- مدة تحميل أول بايت (TTFB)
- الوقت المنقضي منذ بدء المستخدم تحميل الصفحة إلى أن يتلقّى المتصفّح أول بايت من استجابة مستند HTML
- مهلة تحميل الموارد
- الوقت بين وقت استجابة خادم الويب ووقت بدء المتصفّح في تحميل مورد LCP إذا كان
عنصر LCP لا يتطلّب تحميل الموارد لعرضه، تكون هذه الفترة
0
. - مدة تحميل المورد
- مدة الوقت المستغرَق في تحميل مورد LCP نفسه. إذا كان عنصر LCP
لا يتطلّب تحميل مورد لعرضه، تكون هذه الفترة
0
. - مهلة عرض العناصر
- الوقت المستغرَق بين انتهاء تحميل مورد LCP وعرض عنصر LCP بالكامل
بيانات أداء التنقّل الفعلي
تقييم LCP | مدة تحميل أول بايت (بالملي ثانية) | وقت استجابة تحميل الصور (بالملي ثانية) | مدة تحميل الصورة (بالملي ثانية) | تأخُّر العرض (بالملي ثانية) |
---|---|---|---|---|
جيد | 600 | 350 | 160 | 230 |
بحاجة إلى تحسين | 1,360 | 720 | 270 | 310 |
سيئ | 2,270 | 1,290 | 350 | 360 |
في هذه المشاركة، استخدمنا بيانات من عمليات التنقّل في الصفحات التي تتضمّن مقياس LCP لصورة مورد فرعي في Chrome للاطّلاع على الأجزاء الفرعية لمقياس LCP. لقد اطّلعنا على هذا النوع من البيانات من قبل، ولكن لم نتحقّق من بيانات الحقل لمعرفة الوقت الذي يقضيه المستخدمون الفعليون في انتظار ظهور LCP للصفحة.
كما هو الحال مع "مؤشرات أداء الويب الأساسية"، أخذنا الشريحة المئوية الـ 75 (p75) من كل جزء فرعي من LCP لكل مصدر في مجموعة بيانات CrUX، ما أدّى إلى توزيع أربعة من قيم p75 (واحد لكل جزء فرعي). لتلخيص هذه التوزيعات، أخذنا متوسّط هذه القيم على مستوى جميع مصادر البيانات لكل جزء فرعي من أجزاء LCP الأربعة.
أخيرًا، نقسم مصادر الزيارات إلى مجموعات استنادًا إلى ما إذا كانت لديها قيمة"جيّد" أو "بحاجة إلى تحسين" أو "بطيء" لمقياس LCP في الشريحة المئوية الـ 75. يساعد ذلك في إظهار ما يميز مصدرًا يحقّق قيمة جيدة لمقياس LCP عن مصدر يحقّق قيمة سيئة له.
هل يمكنك تقليل حجم صورة LCP؟ هذه المرة مع بيانات
مدة التحميل هي مقياس للوقت الذي يستغرقه جلب مورد LCP، وفي هذه الحالة، الصورة. تكون هذه المدة عادةً متناسبة مع عدد البايتات في الصورة، وبالتالي كل نصائح الأداء التي تهدف إلى تقليل هذا العدد من البايتات.
عند الاطّلاع على الوقت المستغرَق في الرسوم البيانية السابقة، يُلاحظ أنّه لا يتمّ إنفاق الكثير من الوقت في مدة تحميل الصور. في الواقع، هو أقصر جزء فرعي من LCP في جميع مجموعات LCP. تطول مدة التحميل لمصادر LCP ذات الأداء السيئ مقارنةً بمصادر LCP ذات الأداء الجيد، ولكن لا يُنفق الوقت بشكل كبير في هذه العملية.
تستغرق معظم المواقع التي تحقّق أداءً ضعيفًا في مقياس LCP أقل من% 10 من وقت p75 LCP في تنزيل صورة LCP.
نعم، يجب التأكّد من تحسين صورك، ولكن هذا ليس سوى جزء واحد من تحسين مقياس LCP. ويتضح من هذه البيانات أنّه بالنسبة إلى المصدر العادي على الويب، فإنّ المكاسب المحتملة بالمللي ثانية لمقياس LCP بشكل عام صغيرة بغض النظر عن مدى تطوّر مخطط الضغط.
مفاجأة أخيرة: في السابق، كان يتم عادةً تحميل مدة التحميل البطيئة على الأجهزة الجوّالة وجودة شبكات الجوّال. في السابق، كان من المتوقّع أن يستغرق الهاتف العادي وقتًا أطول بعدة مرات لتنزيل الصورة نفسها التي يتم تنزيلها على جهاز كمبيوتر مكتبي باستخدام اتصال سلكي. وتشير البيانات إلى أنّ هذا الوضع قد تغيّر. بالنسبة إلى المواقع التي تحقّق أداءً ضعيفًا في مقياس LCP، يكون متوسّط مدة تحميل الصورة في الربع العلوي من المائة (p75) أبطأ بنسبة% 20 فقط على الأجهزة الجوّالة مقارنةً بأجهزة الكمبيوتر المكتبي.
مدة تحميل أول بايت (TTFB)
بالنسبة إلى عمليات التنقّل التي تُجري طلبًا على الشبكة، سيستغرق وقت استجابة خادم TTFB بعض الوقت دائمًا. يستغرق إجراء عملية بحث في نظام أسماء النطاقات وبدء عملية اتصال بعض الوقت. ولا يمكنك التغلب على قوانين الفيزياء: يجب أن ينتقل الطلب عبر العالم الواقعي عبر الأسلاك والكابل البصري للوصول إلى الخادم، ثم يجب أن يقطع الرد الرحلة نفسها. حتى متوسّط المواقع الجغرافية التي تحقّق قيمة جيدة لمقياس LCP يقضي أكثر من نصف ثانية في وقت الاستجابة للصفحة عند بلوغ النسبة المئوية 75.
ومع ذلك، يشير التباين في وقت الاستجابة للصفحة بين مصادر LCP الجيدة والسيئة إلى فرص التحسين. بالنسبة إلى نصف مصادر البيانات على الأقل التي تحقّق أداءً ضعيفًا في LCP، يضمن وقت استجابة خادم الويب (TTFB) الذي يبلغ 2,270 ملي ثانية في الربع العلوي من 75% وحده تقريبًا أنّ وقت استجابة LCP في الربع العلوي من 75% لا يمكن أن يكون أسرع من الحدّ الأدنى "الجيد" الذي يبلغ 2.5 ثانية. وحتى الانخفاض النسبي المعتدل في هذا الوقت سيؤدي إلى تحسين كبير في LCP.
قد لا تتمكّن من التغلب على قوانين الفيزياء، ولكن هناك إجراءات يمكن اتّخاذها. على سبيل المثال، إذا كان المستخدمون غالبًا في موقع جغرافي مختلف جدًا عن خوادمك، يمكن أن تجعل شبكة توصيل المحتوى (CDN) المحتوى أقرب إليهم.
لمزيد من المعلومات، يمكنك الاطّلاع على دليل تحسين وقت استجابة خادم الويب.
مهلة تحميل الموارد، السبب الرئيسي في بطء LCP
إذا كان من الممكن تحسين وقت الاستجابة للصفحة ولكنّ أيّ تحسينات مرتبطة بالقوانين الفيزيائية، يمكن إزالة تأخّر تحميل الموارد، والذي يرتبط عمليًا فقط ببنية العرض.
يقيس هذا الجزء الفرعي الوقت المستغرَق منذ وصول أول بايت من استجابة HTML (TTFB) إلى أن يبدأ المتصفّح طلبًا لصورة LCP. لقد ركّزنا لعدة سنوات على الوقت الذي يستغرقه تنزيل صور LCP، ولكننا غالبًا ما تجاهلنا الوقت الذي ضاع قبل أن يُطلب من المتصفّح بدء التنزيل.
يقضي الموقع الإلكتروني المتوسط الذي يعرض أداءً ضعيفًا لمقياس LCP وقتًا أطول بمقدار أربع مرات تقريبًا في الانتظار لبدء تنزيل صورة LCP مقارنةً بالوقت الذي يستغرقه تنزيلها فعليًا، وينتظر 1.3 ثانية بين وقت استجابة خادم الويب ووقت طلب الصورة. وهذا يمثّل أكثر من نصف ميزانية LCP التي تبلغ 2.5 ثانية في جزء فرعي واحد.
سلاسل التبعيات هي سبب شائع لتأخُّر التحميل. في الجانب البسيط، يتم تحميل صفحة لجدول أسلوب، والذي يضبط صورة خلفية بعد أن يُعدّ المتصفّح التنسيق، ما سيؤدي في النهاية إلى ظهور مقياس "سرعة عرض أكبر محتوى مرئي" (LCP). ويجب تنفيذ كل هذه الخطوات قبل أن يبدأ المتصفّح في تنزيل صورة LCP.
باستخدام بيانات الزحف العلنية في HTTP Archive التي تسجّل سلسلة "المشغِّل" لطلبات الشبكة من مستند HTML إلى صورة LCP، يمكنك الاطّلاع على الارتباط الواضح بين طول سلسلة الطلبات وبطء سرعة عرض أكبر محتوى مرئي.
والهدف هو إبلاغ المتصفّح في أقرب وقت ممكن بأكبر محتوى مرئي (LCP) حتى يتمكّن من بدء تحميله، حتى قبل أن يتوفّر مكان له في تنسيق الصفحة. تتوفّر بعض الأدوات لتنفيذ ذلك، مثل علامة <img>
الكلاسيكية في لغة HTML حتى يتمكن الماسح الضوئي لميزة "التنزيل المُسبَق" من العثور عليها بسرعة وبدء تنزيلها، أو علامة <link rel="preload">
(أو عنوان HTTP) للصور التي لن تكون <img>
.
من المهم أيضًا مساعدة المتصفّح في تحديد الموارد التي يجب تحديد أولوياتها. وينطبق ذلك بشكل خاص إذا كانت صفحتك تُجري الكثير من الطلبات أثناء تحميل الصفحة، لأنّ المتصفّح لن يعرف غالبًا ما سيكون عليه عنصر LCP إلى أن يتم تحميل العديد من هذه الموارد وتنفيذ التنسيق. من خلال إضافة تعليق توضيحي إلى عنصر LCP المحتمَل باستخدام سمة fetchpriority="high"
(والحرص على تجنُّب loading="lazy"
)، يُوضّح للمتصفّح بدء تحميل المورد على الفور.
اطّلِع على مزيد من النصائح حول تحسين وقت التحميل.
تأخُّر العرض
يقيس تأخُّر العرض الوقت الذي يستغرقه المتصفّح لتحميل صورة LCP وجاهزيتها، ولكن يحدث تأخُّر قبل عرضها على الشاشة لأسباب معيّنة. في بعض الأحيان، تكون هذه مهمة طويلة تمنع سلسلة التعليمات الرئيسية من العمل عندما تكون الصورة جاهزة، وفي حالات أخرى قد يكون خيارًا في واجهة المستخدم لعرض عنصر مخفي.
بالنسبة إلى المصدر المعتاد على الويب، لا يبدو أنّ هناك فرصة كبيرة لتأخير العرض، ولكن أثناء التحسين، يمكنك أحيانًا إنشاء تأخير في العرض من الوقت الذي تمّ إنفاقه سابقًا في الأجزاء الفرعية الأخرى. على سبيل المثال، إذا بدأت صفحة في تحميل صورة LCP مسبقًا لتصبح متاحة بسرعة، لن يكون هناك تأخير طويل في التحميل، ولكن إذا لم تكن الصفحة نفسها جاهزة لعرض الصورة، مثل ملفّ أسلوب كبير يمنع العرض أو تطبيق لعرض المحتوى من جهة العميل يجب أن ينتهي من تحميل كلّ JavaScript قبل أن يتمكّن من عرض أيّ محتوى، سيظلّ LCP أبطأ من المطلوب، وسيظهر الوقت الذي تمّ انتظاره الآن على أنّه تأخّر في العرض. لهذا السبب، غالبًا ما يكون للعرض من جهة الخادم أو لغة HTML الثابتة ميزة عندما يتعلق الأمر بقياس LCP.
إذا كان المحتوى الخاص بك متأثرًا، يمكنك الاطّلاع على مزيد من النصائح حول تحسين وقت عرض المحتوى.
ضَع علامة في المربّع بجانب كل هذه الأجزاء الفرعية.
من الواضح أنّه لتحسين مقياس LCP بفعالية، على المطوّرين النظر في تحميل الصفحة بشكلٍ شامل، وليس التركيز فقط على تحسين الصور. تحقَّق من كل جزء من الوقت المستغرَق في LCP، لأنّه من المرجّح أن تكون هناك فرص أكبر بكثير للتحسين.
لجمع هذه البيانات في الميدان، تتضمّن الإصدار المخصص لإسناد الأداء في مكتبة web-vitals أوقات ظهور الأجزاء الفرعية لمقياس LCP. لا يتضمّن تقرير تجربة مستخدمي Chrome (CrUX) جميع هذه البيانات بعد، ولكنّه يتضمّن إدخالات لكلّ من وقت الاستجابة للصفحة ووقت عرض المحتوى الرئيسي، ما يشكّل بداية جيدة. نأمل أن نضيف البيانات المستخدَمة في هذه المشاركة إلى CrUX في المستقبل، لذا تابِعنا للحصول على المزيد من الأخبار حول ذلك.
لاختبار الأجزاء الفرعية لمقياس LCP على الجهاز، جرِّب إضافة Web Vitals أو مقتطف JavaScript في هذه المقالة. يتضمن Lighthouse أيضًا تفاصيل عن تدقيق "سرعة عرض أكبر جزء من المحتوى على الصفحة". يمكنك الاطّلاع على المزيد من النصائح المتعلّقة بالجزء الفرعي لـ LCP في لوحة "الأداء" في أدوات مطوّري البرامج، والتي ستتوفّر قريبًا.