المفاهيم الخاطئة الشائعة حول كيفية تحسين LCP | مدونة | web.dev
يمكن أن يكون تحسين أكبر رسم محتوى (LCP) للصفحة معقدًا، وغالبًا ما يتضمن أجزاء متحركة ومقايضات متعددة. تتناول هذه المقالة البيانات الميدانية من عمليات تحميل الصفحات الحقيقية عبر الويب لتحديد المكان الذي يجب على المطورين تركيز جهود التحسين فيه.
نصيحة LCP الكلاسيكية: قلل حجم صورك!
بالنسبة لمعظم الصفحات على الويب، يكون عنصر LCP عبارة عن صورة. من الطبيعي أن نفترض أن أفضل طريقة لتحسين LCP هي تحسين صورة LCP الخاصة بك.
في السنوات الخمس أو نحو ذلك منذ تقديم LCP، كانت هذه هي النصيحة الرئيسية في كثير من الأحيان. تأكد من أن حجم صورك مناسب وضغطها بدرجة كافية، وربما تستخدم تنسيق صور القرن الحادي والعشرين أثناء تواجدك هناك. لدى Lighthouse أيضًا ثلاث عمليات تدقيق مختلفة لتقديم هذه الاقتراحات.
عمليات تدقيق تحسين الصورة الثلاثة في تقرير Lighthouse.
جزء من سبب هذه النصيحة الشائعة هو أنه من السهل قياس وحدات البايت الزائدة ومن السهل اقتراح أدوات ضغط الصور. اعتمادًا على مسارات البناء والنشر لديك، قد يكون من السهل أيضًا تنفيذها.
إذا كان الأمر كذلك، افعل ذلك! يعد إرسال وحدات بايت أقل إلى المستخدمين بمثابة فوز دائمًا. هناك كثير المواقع على الويب التي لا تزال تعرض صورًا كبيرة الحجم دون داعٍ والتي يمكن إصلاحها حتى بالضغط الأساسي.
ومع ذلك، عندما بدأنا في النظر في بيانات الأداء الميداني للمستخدمين في Chrome لمعرفة المكان الذي يقضيه عادةً وقت LCP، وجدنا أن وقت تنزيل الصور لا يمثل عنق الزجاجة أبدًا.
بدلاً من ذلك، تمثل الأجزاء الأخرى من LCP مشكلة أكبر بكثير.
انهيار الجزء الفرعي LCP
لفهم أكبر مجالات الفرص لتحسين LCP، نظرنا إلى البيانات من الأجزاء الفرعية لـ LCP، كما هو موضح في Optimize 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. لقد نظرنا إلى هذا النوع من البيانات من قبل، ولكن ليس من البيانات الميدانية أبدًا لمعرفة أين يقضي المستخدمون الحقيقيون وقتهم أثناء انتظار LCP للصفحة.
كما هو الحال مع Core Web Vitals، أخذنا النسبة المئوية الخامسة والسبعين (p75) لكل جزء فرعي من LCP لكل أصل في مجموعة بيانات CrUX، مما أدى إلى أربع توزيعات لقيم p75 (واحدة لكل جزء فرعي). لتلخيص هذه التوزيعات، أخذنا متوسط تلك القيم عبر جميع الأصول لكل جزء من الأجزاء الفرعية الأربعة لـ LCP.
أخيرًا، قمنا بتقسيم الأصول إلى مجموعات بناءً على ما إذا كانت تتمتع بـ LCP “جيد” أو “بحاجة إلى تحسين” أو “ضعيف” عند النسبة المئوية الخامسة والسبعين. يساعد هذا في إظهار ما يميز الأصل ذو LCP الجيد مقابل الأصل ذي LCP الضعيف.
تقليل حجم صورة LCP الخاصة بك؟ هذه المرة مع البيانات
مدة التحميل هي مقياس للمدة التي يستغرقها جلب مورد LCP، في هذه الحالة، صورة. هذه المرة عادة ما تكون متناسبة مع عدد البايتات في الصورة، ومن هنا جاءت كل نصائح الأداء لتقليل هذا العدد من البايتات.
عند النظر إلى أين يمضي الوقت في الرسوم البيانية السابقة، فإن الشيء الوحيد الذي يبرز هو أنه لا يوجد الكثير من الوقت الذي يتم إنفاقه في مدة تحميل الصورة. في الواقع، إنه أقصر جزء فرعي من LCP، في جميع مجموعات LCP. تكون مدة التحميل أطول بالنسبة لأصول LCP الضعيفة مقارنة بأصول LCP الجيدة، ولكن هذا لا يزال ليس المكان الذي يتم فيه قضاء الوقت إلى حد كبير.
تقضي غالبية الأصول ذات LCP الضعيف أقل من 10% من وقت P75 LCP الخاص بها في تنزيل صورة LCP.
نعم، يجب عليك التأكد من تحسين صورك، ولكن هذا مجرد جزء واحد من تحسين LCP. ومن الواضح من هذه البيانات أنه بالنسبة للأصل النموذجي على الويب، فإن المكاسب المحتملة بالمللي ثانية لـ LCP بشكل عام صغيرة بغض النظر عن مدى تعقيد نظام الضغط.
مفاجأة أخيرة: كان يتم إلقاء اللوم عادةً على فترات التحميل البطيئة على الأجهزة المحمولة وجودة شبكات الهاتف المحمول. ربما توقعنا ذات مرة أن يستغرق الهاتف العادي وقتًا أطول عدة مرات لتنزيل نفس الصورة مثل جهاز سطح المكتب على اتصال سلكي. تشير البيانات إلى أن هذا لم يعد هو الحال. بالنسبة للأصول ذات LCP الضعيف، يكون متوسط مدة تحميل الصورة p75 أبطأ بنسبة 20% فقط على الهاتف المحمول مقارنة بسطح المكتب.
الوقت حتى البايت الأول (TTFB)
بالنسبة للتنقلات التي تتطلب طلب شبكة، سيستغرق TTFB دائمًا بعض الوقت. يستغرق الأمر وقتًا لإجراء بحث DNS وبدء الاتصال. ولا يمكنك التغلب على الفيزياء: يجب أن ينتقل الطلب عبر العالم الحقيقي عبر الأسلاك والكابلات الضوئية للوصول إلى الخادم، ثم يجب أن تقوم الاستجابة بالرحلة مرة أخرى. حتى الأصل المتوسط ذو LCP الجيد يقضي أكثر من نصف ثانية على TTFB عند النسبة المئوية الخامسة والسبعين.
ومع ذلك، فإن التفاوت في TTFB بين أصول LCP الجيدة والفقيرة يظهر فرصة للتحسين. بالنسبة لنصف الأصول على الأقل ذات LCP الضعيف، فإن p75 TTFB يبلغ 2270 مللي ثانية وحيد يضمن تقريبًا أن p75 LCP لا يمكن أن يكون أسرع من عتبة 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 الأبطأ.
علاقة سلاسل الطلب التابعة مع LCP.
المفتاح هو السماح للمتصفح بمعرفة ما هو LCP في أسرع وقت ممكن حتى يتمكن من البدء في تحميله، حتى قبل أن يكون هناك مكان له في تخطيط الصفحة. هناك عدد قليل من الأدوات المتاحة لتحقيق ذلك، مثل الكلاسيكية <img> في ملف HTML حتى يتمكن ماسح التحميل المسبق من العثور عليه بسرعة والبدء في تنزيله، أو <link rel="preload"> علامة (أو رأس HTTP) للصور التي لن تكون كذلك <img>ق.
من المهم أيضًا مساعدة المتصفح في تحديد الموارد التي يجب تحديد أولوياتها. وينطبق هذا بشكل خاص إذا كانت صفحتك تقدم الكثير من الطلبات أثناء تحميل الصفحة، حيث أن المتصفح غالبًا لن يعرف ما سيكون عليه عنصر LCP إلا بعد تحميل العديد من هذه الموارد وحدث التخطيط. شرح عنصر LCP المحتمل باستخدام a fetchpriority="high" السمة (والتأكد من تجنب loading="lazy") يوضح للمتصفح أن يبدأ تحميل المورد على الفور.
اقرأ المزيد من النصائح حول تحسين تأخير التحميل.
تأخير العرض
يقيس تأخير العرض الوقت الذي يبدأ منذ تحميل المتصفح لصورة LCP وجاهزيتها، ولكن لسبب ما، هناك تأخير قبل ظهورها على الشاشة. في بعض الأحيان تكون هذه مهمة طويلة تحظر سلسلة المحادثات الرئيسية عندما تكون الصورة جاهزة، وفي حالات أخرى قد يكون اختيار واجهة المستخدم للكشف عن عنصر مخفي.
بالنسبة للأصل النموذجي على الويب، لا يبدو أن هناك فرصة كبيرة لتأخير العرض، ولكن أثناء التحسين، يمكنك أحيانًا يخلق جعل التأخير خارج الوقت الذي تم إنفاقه مسبقًا في الأجزاء الفرعية الأخرى. على سبيل المثال، إذا بدأت الصفحة في التحميل المسبق لصورة LCP بحيث تكون متاحة بسرعة، فلن يكون هناك تأخير طويل في التحميل، ولكن إذا لم تكن الصفحة نفسها جاهزة لعرض الصورة – مثل ورقة أنماط كبيرة تمنع العرض أو تطبيق العرض من جانب العميل الذي يجب أن ينتهي من تحميل كل JavaScript الخاص به قبل أن يتم عرض أي شيء – سيظل LCP أبطأ مما ينبغي، وسيظهر الآن الوقت المستغرق في الانتظار على أنه تأخير عرض. هذا هو السبب في أن العرض من جانب الخادم أو HTML الثابت غالبًا ما يكون له ميزة عندما يتعلق الأمر بـ LCP.
إذا تأثر المحتوى الخاص بك، فاقرأ المزيد من النصائح حول تحسين تأخير العرض.
تحقق من كل تلك الأجزاء الفرعية
من الواضح أنه لتحسين LCP بشكل فعال، يحتاج المطورون إلى النظر إلى تحميل الصفحة بشكل كلي، وليس التركيز فقط على تحسين الصور. تحقق من كل جزء من الوقت لـ LCP، لأنه من المحتمل أن تكون هناك فرص أكبر بكثير للتحسين.
لجمع هذه البيانات في الميدان، يتضمن بناء إسناد مكتبة مؤشرات الحيوية على الويب توقيتات لأجزاء LCP الفرعية. لا يتضمن تقرير تجربة مستخدم Chrome (CrUX) كل هذه البيانات حتى الآن، ولكنه يحتوي على إدخالات لـ TTFB وLCP، لذا فهي البداية. نأمل أن نقوم بتضمين البيانات المستخدمة لهذا المنشور في CrUX في المستقبل، لذا ترقبوا المزيد من الأخبار حول ذلك.
لاختبار أجزاء LCP الفرعية محليًا، جرّب ملحق Web Vitals أو مقتطف JavaScript في هذه المقالة. تتضمن Lighthouse أيضًا تفاصيل عملية تدقيق “أكبر عنصر طلاء محتوى”. ابحث عن المزيد من النصائح المتعلقة بالأجزاء الفرعية لـ LCP في لوحة أداء DevTools، والتي ستتوفر قريبًا.
