Largest Contentful Paint (LCP)

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

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

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

ما هو LCP؟

يشير مقياس LCP إلى الوقت الذي تستغرقه أكبر صورة أو مقطع نصي في إطار العرض مقارنةً بالوقت الذي انتقل فيه المستخدم إلى الصفحة لأول مرة.

ما هي درجة LCP الجيدة؟

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

ما العناصر التي يتم أخذها في الاعتبار؟

كما هو موضح حاليًا في سرعة عرض أكبر جزء من المحتوى على الصفحة، تشمل أنواع العناصر التي يتم اعتبارها "سرعة عرض أكبر جزء من المحتوى على الصفحة" ما يلي:

• عناصر <img> (يتم استخدام وقت عرض اللقطة الأولى للمحتوى المتحرك، مثل ملفات GIF أو ملفات PNG المتحركة)
• عناصر <image> داخل عنصر <svg>
• عناصر <video> (يتم استخدام وقت تحميل صورة الملصق أو وقت عرض اللقطة الأولى للفيديوهات، أيّهما أسبق)
• عنصر مع صورة خلفية تم تحميله باستخدام الدالة url()، (بدلاً من تدرج CSS)
• العناصر على مستوى الحظر التي تحتوي على عُقد نصية أو عناصر نصية ثانوية أخرى على المستوى المضمّن

لاحظ أن تقييد العناصر بهذه المجموعة المحدودة كان مقصودًا لتبسيط الأمور في البداية. وقد تتم إضافة عناصر إضافية في المستقبل (مثل الدعم الكامل لـ <svg>) عند إجراء المزيد من الأبحاث.

إلى جانب مراعاة بعض العناصر فقط، تستخدم قياسات سرعة عرض أكبر جزء من المحتوى على الصفحة إشارات استدلالية لاستبعاد عناصر معيّنة من المرجَّح أن يعتبرها المستخدمون "غير غنية بالمحتوى". وبالنسبة إلى المتصفحات المستندة إلى Chromium، تشمل هذه المتصفحات ما يلي:

• العناصر التي تبلغ تعتيمها 0 ولا تظهر للمستخدم
• العناصر التي تغطي إطار العرض الكامل، والتي تُعتبر على الأرجح خلفية بدلاً من محتوى
• صور عناصر نائبة أو صور أخرى ذات قصور منخفض، والتي من المرجَّح ألا تعكس المحتوى الحقيقي للصفحة

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

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

كيف يتم تحديد حجم العنصر؟

عادةً ما يكون حجم العنصر الذي يتم الإبلاغ عنه لمقياس LCP هو الحجم المرئي للمستخدم في إطار العرض. وإذا كان العنصر يمتد خارج إطار العرض أو إذا كان أي من العناصر قد تم اقتصاصه أو كان يحتوي على overflow غير مرئي، لا يتم احتساب هذه الأجزاء ضمن حجم العنصر.

بالنسبة إلى عناصر الصور التي تم تغيير حجمها من الحجم الأساسي، يكون الحجم الذي يتم الإبلاغ عنه هو الحجم المرئي أو الحجم الأساسي، أيهما أصغر.

في العناصر النصية، يأخذ LCP في الاعتبار أصغر مستطيل يمكن أن يحتوي على جميع العُقد النصية.

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

متى يتم الإبلاغ عن سرعة LCP؟

غالبًا ما يتم تحميل صفحات الويب على مراحل، ونتيجةً لذلك، من الممكن أن يتغيّر العنصر الأكبر في الصفحة.

لمعالجة إمكانية التغيير هذه، يرسل المتصفّح عنصر PerformanceEntry من النوع largest-contentful-paint لتحديد أكبر عنصر محتوى بعد رسم المتصفّح للإطار الأول. وبعد ذلك، بعد عرض الإطارات اللاحقة، سيتم نقل PerformanceEntry أخرى في أي وقت عندما يتغير عنصر المحتوى الأكبر في المحتوى.

على سبيل المثال، في صفحة تحتوي على نص وصورة جزء رئيسي، قد يعرض المتصفّح النص فقط في البداية، وعندها يرسل المتصفّح إدخال largest-contentful-paint الذي من المحتمل أن تشير السمة element إليه إلى <p> أو <h1>. لاحقًا، عند انتهاء تحميل صورة الجزء الرئيسي، سيتم إرسال إدخال largest-contentful-paint ثانٍ وستشير خاصية element إلى <img>.

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

بالإضافة إلى الصور والخطوط التي يتم تحميلها متأخرًا، قد تضيف الصفحة عناصر جديدة إلى DOM عند توفُّر محتوى جديد. إذا كان أي من هذه العناصر الجديدة أكبر من حجم العنصر السابق الذي يتضمّن أكبر محتوى، سيتم أيضًا الإبلاغ عن عنصر PerformanceEntry جديد.

في حال إزالة أكبر عنصر من عناصر المحتوى من إطار العرض أو حتى من نموذج العناصر في المستند (DOM)، يظل العنصر الأكبر حجمًا من عناصر المحتوى ما لم يتم عرض عنصر أكبر من هذا المحتوى.

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

لأغراض التحليل، يجب الإبلاغ فقط عن آخر PerformanceEntry تم إرسالها إلى خدمة الإحصاءات.

وقت التحميل مقابل وقت العرض

لأسباب تتعلّق بالأمان، لا يتم عرض الطابع الزمني لعرض الصور في الصور من مصادر متعددة والتي لا تتضمّن العنوان Timing-Allow-Origin. بل يتم فقط عرض وقت التحميل الخاص بها (لأنّه يتم الكشف عنها من خلال العديد من واجهات برمجة تطبيقات الويب الأخرى).

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

ننصح دائمًا بضبط العنوان Timing-Allow-Origin عندما يكون ذلك ممكنًا، وذلك لكي تكون المقاييس أكثر دقة.

كيف يتم التعامل مع تغييرات تخطيط العناصر وحجمها؟

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

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

أمثلة

إليك بعض الأمثلة على حالات "سرعة عرض أكبر جزء من المحتوى على الصفحة" على بعض المواقع الإلكترونية الرائجة:

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

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

في المثال الأول، يتم تحميل شعار Instagram في وقت مبكر نسبيًا ويظل العنصر الأكبر حتى مع عرض المحتوى الآخر تدريجيًا. في مثال صفحة نتائج "بحث Google"، العنصر الأكبر هو فقرة نص يتم عرضها قبل انتهاء تحميل أي صورة أو شعار. ونظرًا لأن جميع الصور الفردية أصغر من هذه الفقرة، فإنها تظل العنصر الأكبر طوال عملية التحميل.

طريقة قياس سرعة LCP

يمكن قياس سرعة LCP في المختبر أو في المجال، وهو متاح في الأدوات التالية:

الأدوات الميدانية

• تقرير تجربة المستخدم في Chrome
• PageSpeed Insights
• Search Console (تقرير "مؤشرات أداء الويب الأساسية")
• مكتبة JavaScript web-vitals

أدوات المختبر

• أدوات مطوري البرامج في Chrome
• Lighthouse
• PageSpeed Insights
• WebPageTest

قياس سرعة LCP في JavaScript

لقياس سرعة عرض أكبر جزء من المحتوى على الصفحة في JavaScript، يمكنك استخدام أكبر واجهة برمجة تطبيقات لعرض المحتوى. يوضِّح المثال التالي كيفية إنشاء PerformanceObserver ينتظر استقبال إدخالات largest-contentful-paint ويسجِّلها في وحدة التحكُّم.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('LCP candidate:', entry.startTime, entry);
  }
}).observe({type: 'largest-contentful-paint', buffered: true});

في المثال أعلاه، يمثّل كل إدخال largest-contentful-paint تم تسجيله المرشح الحالي لمقياس LCP. وبشكل عام، تكون قيمة startTime لآخر إدخال مُنبثق هي قيمة LCP، إلا أنّ هذا لا يحدث دائمًا. ليست كل إدخالات largest-contentful-paint صالحة لقياس LCP.

يسرد القسم التالي الاختلافات بين ما تقارير واجهة برمجة التطبيقات وكيفية حساب المقياس.

الاختلافات بين المقياس وواجهة برمجة التطبيقات

• سترسل واجهة برمجة التطبيقات إدخالات largest-contentful-paint للصفحات التي يتم تحميلها في علامة تبويب في الخلفية، ولكن يجب تجاهل هذه الصفحات عند احتساب سرعة LCP.
• ستواصل واجهة برمجة التطبيقات إرسال إدخالات largest-contentful-paint بعد عرض الصفحة في الخلفية، ولكن يجب تجاهُل هذه الإدخالات عند احتساب سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) (لا يمكن النظر في العناصر إلا إذا كانت الصفحة في المقدّمة طوال الوقت).
• لا تُبلغ واجهة برمجة التطبيقات عن إدخالات largest-contentful-paint عند استعادة الصفحة من التخزين المؤقت للصفحات، ولكن يجب قياس سرعة عرض أكبر جزء من المحتوى على الصفحة في هذه الحالات لأنّ المستخدمين يواجهونها كزيارات مختلفة للصفحة.
• لا تراعي واجهة برمجة التطبيقات العناصر ضمن إطارات iframe، ولكن المقياس يراعيها لأنّها جزء من تجربة المستخدم على الصفحة. وفي الصفحات التي تتضمّن LCP ضمن iframe، مثل صورة ملصق على فيديو مضمّن، سيظهر ذلك كفرق بين CrUX وRUM. ولقياس سرعة LCP بشكل صحيح، عليك أخذها في الاعتبار. يمكن للإطارات الفرعية استخدام واجهة برمجة التطبيقات لإرسال تقارير إدخالات largest-contentful-paint إلى الإطار الأصلي لتجميعها.
• تقيس واجهة برمجة التطبيقات سرعة LCP من بدء التنقّل، ولكن بالنسبة إلى الصفحات المعروضة مسبقًا يجب قياس سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) بدءًا من activationStart، لأنّ ذلك يتوافق مع وقت سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) الذي لاحظه المستخدم.

بدلاً من تذكُّر كل هذه الاختلافات الطفيفة، يمكن للمطوّرين استخدام مكتبة JavaScript web-vitals لقياس سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) التي تعالج هذه الاختلافات بالنيابة عنك (حيثما أمكن، مع العلم أنّ مشكلة iframe لم يتم تناولها):

import {onLCP} from 'web-vitals';

// Measure and log LCP as soon as it's available.
onLCP(console.log);

يُرجى الرجوع إلى رمز المصدر لـ onLCP() للاطّلاع على مثال كامل عن كيفية قياس LCP في JavaScript.

ماذا لو لم يكن العنصر الأكبر هو الأكثر أهمية؟

في بعض الحالات، لا يكون العنصر (أو العناصر) الأكثر أهمية على الصفحة هو نفسه العنصر الأكبر، وقد يكون المطوّرون أكثر اهتمامًا بقياس أوقات عرض هذه العناصر الأخرى بدلاً من ذلك. ويمكنك إجراء ذلك باستخدام Element Timing API، كما هو موضّح في المقالة عن المقاييس المخصّصة.

طريقة تحسين سرعة LCP

يتوفّر دليل كامل حول تحسين سرعة LCP لإرشادك خلال عملية تحديد توقيتات LCP في المجال واستخدام البيانات المعملية للتوغّل فيها وتحسينها.

مصادر إضافية

• الدروس المستفادة من مراقبة الأداء في Chrome من إعداد آني سوليفان في performance.now() (2019)

سجلّ التغييرات

في بعض الأحيان، يتم اكتشاف أخطاء في واجهات برمجة التطبيقات المستخدمة لقياس المقاييس، وفي بعض الأحيان في تعريفات المقاييس نفسها. نتيجةً لذلك، يجب إجراء تغييرات في بعض الأحيان، وقد تظهر هذه التغييرات على أنّها تحسينات أو تراجع في التقارير ولوحات البيانات الداخلية.

لمساعدتك في إدارة ذلك، سيتم عرض كل التغييرات التي تطرأ على تنفيذ هذه المقاييس أو تعريفها في سجلّ التغييرات هذا.

إذا كانت لديك ملاحظات حول هذه المقاييس، يمكنك تقديمها من خلال مجموعة Google الخاصة بملاحظات حول الإلكترونيات الشخصية.