في السابق، كان من الصعب على مطوّري برامج الويب قياس مدى سرعة تحميل المحتوى الرئيسي لصفحة الويب وظهوره للمستخدمين. ولا تعمل المقاييس القديمة مثل load أو DOMContentLoaded بشكل جيد لأنّها لا تتطابق بالضرورة مع ما يراه المستخدم على الشاشة. أمّا مقاييس الأداء الأحدث التي تركّز على المستخدم، مثل سرعة عرض المحتوى على الصفحة (FCP)، فتستفيد فقط من بداية تجربة التحميل. إذا كانت الصفحة تعرض شاشة بداية أو مؤشر تحميل، لن تكون هذه اللحظة ذات صلة بموضوع البحث بالنسبة إلى المستخدم.
في الماضي، اقترحنا مقاييس أداء مثل سرعة عرض أوّل محتوى (FMP) ومؤشر السرعة (SI) (كلاهما متوفّران في Lighthouse) للمساعدة في تسجيل المزيد من تجربة التحميل بعد اكتمال عملية التحميل، ولكن هذه المقاييس معقّدة ويصعب شرحها وغالبًا ما تكون خاطئة، ما يعني أنّها ما زالت لا يمكنها تحديد وقت تحميل المحتوى الرئيسي للصفحة.
استنادًا إلى المناقشات التي جرت في مجموعة عمل الويب W3C والأبحاث التي تم إجراؤها في Google، تبيَّن لنا أنّ الطريقة الأكثر دقة لقياس وقت تحميل المحتوى الرئيسي للصفحة هي النظر في وقت عرض العنصر الأكبر.
ما هو مقياس LCP؟
يشير مقياس LCP إلى الوقت الذي تستغرقه أكبر صورة أو نص مرئي في إطار العرض مقارنةً بالوقت الذي انتقل فيه المستخدم إلى الصفحة لأول مرة.
ما هي نتيجة مقياس LCP الجيدة؟
لتقديم تجربة جيدة للمستخدم، يجب أن تسعى المواقع الإلكترونية إلى الحصول على "سرعة عرض أكبر محتوى مرئي" تبلغ 2.5 ثانية أو أقل. لضمان تحقيق هذا الاستهداف لمعظم المستخدمين، يُعدّ الحد الأدنى الجيد الذي يمكن قياسه هو الشريحة المئوية الخامسة والسبعين لعمليات تحميل الصفحات، والمقسّمة على جميع الأجهزة الجوّالة وأجهزة الكمبيوتر المكتبي.
ما العناصر التي يتم اعتبارها؟
كما هو محدّد حاليًا في سرعة عرض أكبر محتوى مرئي وواجهة برمجة التطبيقات (API)، وأنواع العناصر يتم أخذها في الاعتبار ضمن "سرعة عرض أكبر محتوى مرئي":
- عناصر
<img>(يتم استخدام وقت العرض الأول للإطار للمحتوى المتحرك، مثل ملفات GIF أو صور PNG المتحركة) - عناصر
<image>داخل عنصر<svg> - عناصر
<video>(يتم استخدام وقت تحميل صورة الملصق أو وقت عرض الإطار الأول في الفيديوهات، أيهما أقرب) - عنصر مع صورة خلفية تم تحميله باستخدام الدالة
url()، (على عكس تدرج CSS) - عناصر مستوى الحظر التي تحتوي على عُقد نصية أو عناصر نصية ثانوية أخرى على مستوى التضمين
لاحظ أن تقييد العناصر بهذه المجموعة المحدودة كان مقصودًا لإبقاء الأمور بسيطة في البداية. ويمكن إضافة عناصر إضافية (مثل دعم <svg> الكامل) في المستقبل عند إجراء المزيد من الأبحاث.
بالإضافة إلى مراعاة بعض العناصر فقط، تستخدم قياسات سرعة عرض أكبر محتوى مرئي (LCP) إرشادات لاستبعاد بعض العناصر التي من المرجّح أن يراها المستخدمون باعتبارها "غير محتوى". بالنسبة إلى المتصفِّحات المستنِدة إلى Chromium، تشمل هذه الإصدارات ما يلي:
- العناصر ذات التعتيم 0 والتي تكون غير مرئية للمستخدم
- يشير هذا المصطلح إلى العناصر التي تغطي إطار العرض بالكامل، والتي يُرجّح اعتبارها خلفية وليس محتوى.
- صور العناصر النائبة أو الصور الأخرى ذات القصور المنخفض، والتي على الأرجح لا تعكس المحتوى الحقيقي للصفحة
ومن المرجّح أن تواصل المتصفّحات تحسين هذه المؤشرات لضمان مطابقة توقّعات المستخدمين حول المحتوى الأكبر المحتوى.
تقدّم هذه الألعاب "المحتوى الباعث على الرضا" وقد تختلف المؤشرات عن تلك التي يستخدمها مقياس سرعة عرض المحتوى على الصفحة (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 مما يؤدي إلى تغيير العنصر الأكبر. في المثال الثاني، يتم تغيير التنسيق والمحتوى الذي كان الأكبر حجمًا في السابق تتم إزالته من إطار العرض.
غالبًا ما يكون التحميل المتأخر أكبر من المحتوى المتوفّر على الصفحة، ولكن هذا لا يحدث بالضرورة. يوضِّح المثالان التاليان سرعة عرض أكبر جزء من المحتوى على الصفحة (LCP) التي تحدث قبل تحميل الصفحة بالكامل.
في المثال الأول، يتم تحميل شعار Instagram في وقت مبكر نسبيًا ويظل العنصر الأكبر حتى مع عرض محتوى آخر بشكل تدريجي. في مثال صفحة نتائج "بحث Google"، العنصر الأكبر هو فقرة من النص يتم عرضها قبل انتهاء تحميل أي من الصور أو الشعار. نظرًا لأن جميع الصور الفردية أصغر من هذه الفقرة، فستظل العنصر الأكبر خلال عملية التحميل.
كيفية قياس سرعة عرض أكبر محتوى مرئي
يمكن قياس LCP في المختبر أو في المجال، وهو متاح في الأدوات التالية:
الأدوات الميدانية
- تقرير تجربة المستخدم على Chrome
- PageSpeed Insights
- تقرير Search Console (تقرير "مؤشرات أداء الويب الأساسية")
- مكتبة JavaScript
web-vitals
أدوات التمرين المعملي
قياس LCP في JavaScript
لقياس سرعة عرض أكبر محتوى مرئي (LCP) في JavaScript، يمكنك استخدام bigst Contentful Paint API. يوضح المثال التالي كيفية إنشاء 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 لآخر إدخال تم إطلاقه هي قيمة سرعة عرض أكبر محتوى مرئي، ولكن هذا لا يحدث دائمًا. ليست كل إدخالات largest-contentful-paint صالحة لقياس LCP.
يسرد القسم التالي الاختلافات بين التقارير التي تقدّمها واجهة برمجة التطبيقات وكيفية احتساب المقياس.
الاختلافات بين المقياس وواجهة برمجة التطبيقات
- سترسِل واجهة برمجة التطبيقات
largest-contentful-paintإدخال للصفحات التي يتم تحميلها في علامة تبويب في الخلفية، ولكن يجب تجاهل هذه الصفحات عند احتساب مقياس LCP. - ستواصل واجهة برمجة التطبيقات إرسال إدخالات
largest-contentful-paintبعد تشغيل الصفحة في الخلفية، ولكن يجب تجاهل هذه الإدخالات عند احتساب سرعة عرض أكبر محتوى مرئي (لا يمكن مراعاة العناصر إلا إذا كانت الصفحة في المقدّمة طوال الوقت). - لا تُبلِغ واجهة برمجة التطبيقات عن إدخالات
largest-contentful-paintعند استعادة الصفحة من ميزة "التخزين المؤقت للصفحات"، ولكن يجب قياس مقياس LCP في هذه الحالات لأنّ المستخدمين تظهر لهم كزيارات مختلفة للصفحة. - لا تراعي واجهة برمجة التطبيقات العناصر ضمن إطارات iframe، لكنّ المقياس يأخذها في الاعتبار لأنّها جزء من تجربة المستخدم على الصفحة. في الصفحات التي تتضمّن مقياس LCP ضمن إطار iframe، مثل صورة ملصق على فيديو مضمّن، سيظهر هذا الاختلاف بين CrUX وRUM. لقياس مقياس LCP بشكل صحيح، عليك مراعاة ذلك. يمكن للإطارات الفرعية استخدام واجهة برمجة التطبيقات للإبلاغ عن إدخالات
largest-contentful-paintالخاصة بها إلى الإطار الرئيسي لتجميع البيانات. - تقيس واجهة برمجة التطبيقات سرعة عرض أكبر محتوى مرئي (LCP) من بدء التنقّل، ولكن بالنسبة إلى الصفحات المعروضة مُسبقًا، يجب قياس LCP من
activationStartلأنّ ذلك يتوافق مع وقت سرعة عرض أكبر جزء من المحتوى على النحو الذي يراه المستخدم.
بدلاً من تذكُّر كل هذه الاختلافات الطفيفة، يمكن للمطوّرين استخدام web-vitals مكتبة JavaScript لقياس سرعة عرض أكبر جزء من المحتوى على الصفحة (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) في المجال واستخدام البيانات الاختبارية للتعمّق فيها وتحسينها.
مراجع إضافية
- الدروس المستفادة من مراقبة الأداء في Chrome من إعداد آني سوليفان على مقالة performance.now() (2019)
سجلّ التغييرات
من حين لآخر، يتم اكتشاف أخطاء في واجهات برمجة التطبيقات المستخدمة لقياس المقاييس، وأحيانًا في تعريفات المقاييس نفسها. نتيجةً لذلك، يجب إجراء تغييرات في بعض الأحيان، وقد تظهر هذه التغييرات كتحسينات أو تراجعات في التقارير الداخلية ولوحات البيانات.
لمساعدتك على إدارة هذه المقاييس، سيتم عرض جميع التغييرات التي تطرأ على تنفيذ هذه المقاييس أو تعريفها في سجلّ التغييرات هذا.
إذا كانت لديك ملاحظات بشأن هذه المقاييس، يمكنك تقديمها في مجموعة Google الخاصة بملاحظات مؤشرات أداء الويب.