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