في السابق، كان من الصعب على مطوّري الويب قياس سرعة ظهور المحتوى الرئيسي لصفحة الويب للمستخدمين. ولا تعمل المقاييس القديمة مثل load أو DOMContentLoaded بشكل جيد لأنّها لا تتوافق بالضرورة مع ما يراه المستخدم على الشاشة. أمّا مقاييس الأداء الجديدة التي تركّز على المستخدِم، مثل سرعة عرض المحتوى على الصفحة (FCP)، فلا ترصد سوى بداية تجربة التحميل. إذا كانت الصفحة تعرض شاشة البداية أو مؤشر التحميل، لن تكون هذه اللحظة ملائمة جدًا للمستخدم.
في الماضي، اقترحنا مقاييس أداء مثل سرعة عرض أوّل محتوى (FMP) ومؤشر السرعة (SI) (كلاهما متوفّران في Lighthouse) للمساعدة في تسجيل المزيد من تجربة التحميل بعد اكتمال عملية التحميل، ولكن هذه المقاييس معقّدة ويصعب شرحها وغالبًا ما تكون خاطئة، ما يعني أنّها ما زالت لا يمكنها تحديد وقت تحميل المحتوى الرئيسي للصفحة.
استنادًا إلى المناقشات التي جرت في مجموعة عمل الويب W3C والأبحاث التي تم إجراؤها في Google، تبيَّن لنا أنّ الطريقة الأكثر دقة لقياس وقت تحميل المحتوى الرئيسي للصفحة هي النظر في وقت عرض العنصر الأكبر.
ما هو مقياس LCP؟
يشير مقياس LCP إلى الوقت الذي تستغرقه أكبر صورة أو مقطع نصي أو فيديو مرئي في إطار العرض مقارنةً بالوقت الذي انتقل فيه المستخدم إلى الصفحة لأول مرة.
ما هي نتيجة مقياس LCP الجيدة؟
لتقديم تجربة جيدة للمستخدم، يجب أن تسعى المواقع الإلكترونية إلى أن تكون سرعة عرض أكبر محتوى مرئي 2.5 ثانية أو أقل. لضمان تحقيق هذا الاستهداف لمعظم المستخدمين، يُعدّ الحد الأدنى الجيد الذي يمكن قياسه هو الشريحة المئوية الخامسة والسبعين لعمليات تحميل الصفحات، والمقسّمة على جميع الأجهزة الجوّالة وأجهزة الكمبيوتر المكتبي.
ما العناصر التي يتم اعتبارها؟
كما هو محدّد حاليًا في سرعة عرض أكبر محتوى مرئي وواجهة برمجة التطبيقات، وأنواع العناصر يتم أخذها في الاعتبار ضمن "سرعة عرض أكبر محتوى مرئي":
- عناصر
<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
يمكن قياس LCP في المختبر أو في المجال، وهو متاح في الأدوات التالية:
أدوات الحقل
- تقرير تجربة المستخدم على Chrome
- PageSpeed Insights
- Search Console (تقرير "مؤشرات أداء الويب الأساسية")
web-vitals
مكتبة JavaScript
أدوات المختبر
قياس 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
للقيمة الأخيرة التي تمّ عرضها هي قيمة LCP، ولكنّ هذا ليس صحيحًا دائمًا. ليست كل إدخالات largest-contentful-paint
صالحة لقياس LCP.
يسرد القسم التالي الاختلافات بين التقارير التي تقدّمها واجهة برمجة التطبيقات وكيفية احتساب المقياس.
الاختلافات بين المقياس وواجهة برمجة التطبيقات
- سترسِل واجهة برمجة التطبيقات
largest-contentful-paint
إدخال للصفحات التي يتم تحميلها في علامة تبويب في الخلفية، ولكن يجب تجاهل هذه الصفحات عند احتساب مقياس LCP. - ستواصل واجهة برمجة التطبيقات إرسال إدخالات
largest-contentful-paint
بعد تشغيل الصفحة في الخلفية، ولكن يجب تجاهل هذه الإدخالات عند احتساب سرعة عرض أكبر محتوى مرئي (لا يمكن مراعاة العناصر إلا إذا كانت الصفحة في المقدّمة طوال الوقت). - لا تسجّل واجهة برمجة التطبيقات إدخالات
largest-contentful-paint
عند استعادة الصفحة من ذاكرة التخزين المؤقت للرجوع/التقديم، ولكن يجب قياس سرعة عرض أكبر جزء من المحتوى على الصفحة في هذه الحالات لأنّ المستخدمين يواجهونها كزيارات صفحة مختلفة. - لا تراعي واجهة برمجة التطبيقات العناصر ضمن إطارات 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 الخاصة بملاحظات مؤشرات أداء الويب.