مرحلة التجربة والتقييم لميزة "توقيت الحاويات"

Barry Pollard

Jason Williams

José Dapena Paz

تاريخ النشر: 01 مايو 2026

سيطلق Chrome مرحلة تجربة وتقييم من الإصدار 148 من Chrome لواجهة برمجة التطبيقات Container Timing API.

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

تتيح Element Timing للمواقع الإلكترونية ترميز العناصر باستخدام السمة elementtiming لمعرفة وقت تحميلها، سواء كانت عنصر LCP أم لا. ومع ذلك، كما هو الحال مع مقياس LCP، يقتصر هذا المقياس على قياس أوقات عرض العناصر الفردية.

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

تتوفّر ميزة "توقيت الحاويات"، التي طوّرتها شركة Bloomberg ونفّذتها شركة Igalia في Chrome، خلف علامة لمستخدمي Chrome والمتصفّحات الأخرى المستندة إلى Chromium، كما تتوفّر للمواقع الإلكترونية لاختبارها ميدانيًا من خلال مرحلة التجربة والتقييم.

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

طريقة عمل Container Timing API

تعمل ميزة "توقيت الحاوية"، مثل ميزة "توقيت العنصر"، من خلال إضافة سمة (containertiming) إلى عناصر HTML المختلفة للإشارة إلى المتصفّح بأنّه يجب قياس هذه العناصر:

<div containertiming="my-component">
  <h2>Title</h2>
  <div>...</div>
</div>

تتيح لك PerformanceObserver بعد ذلك مراقبة عمليات الطلاء داخل هذا الحاوية بالطريقة نفسها التي يتم بها مراقبة مقاييس الأداء الأخرى:

<script>
  const observer = new PerformanceObserver((entryList) => {
    for (const entry of entryList.getEntries()) {
      console.log("Container painted:", entry.identifier);
      console.log("First render:", entry.firstRenderTime);
      console.log("Latest paint:", entry.startTime);
      console.log("Painted area:", entry.size);
      console.log("Last painted element:", entry.lastPaintedElement);
    }
  });
  observer.observe({ type: "container", buffered: true });
</script>

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

يمكن بعد ذلك إعادة إرسال مقاييس الأداء هذه إلى خدمة الإحصاءات لتتبُّعها وتحليلها.

يمكن أيضًا تجاهل الحاويات الفرعية باستخدام السمة containertiming-ignore:

<div containertiming="main-content">

  <main>...</main>
  
  <!-- This aside and its children will be ignored -->
  <aside containertiming-ignore>...</aside>

</div>

عرض توضيحي

يوضّح CodePen التالي طريقة عمل Container Timing API:

يمكنك أيضًا مشاهدة ذلك في الفيديو التالي إذا كان المتصفّح لا يتوافق مع Container Timing API:

ما هي التحديثات التي يتم احتسابها في "توقيت الحاوية"؟

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

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

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

إتاحة توقيت الحاوية الذي يرصد الميزات

لن تتسبّب السمة containertiming في حدوث مشاكل للمتصفّحات غير المتوافقة، لذا لا يلزم رصد الميزات.

سيتجاهل PerformanceObserver أي إدخالات جديدة، ولكن يمكن أن يتسبّب في ظهور تحذيرات في "أدوات مطوّري البرامج"، لذا من أفضل الممارسات رصد الميزات قبل إضافة مراقب باستخدام رمز مثل:

if (typeof PerformanceContainerTiming !== "undefined") {
  // Container Timing is supported
}

أفضل الممارسات

في ما يلي بعض أفضل الممارسات التي يجب اتّباعها للاستفادة من ميزة "توقيت الحاوية" على النحو الأمثل:

• ضبط السمات مبكرًا: أضِف السمة containertiming في مستند HTML أو قبل إضافة العنصر إلى المستند لإجراء عملية تتبُّع كاملة. قد تؤدي إضافة السمة لاحقًا باستخدام JavaScript إلى عدم عرض بعض اللوحات.
• استخدام معرّفات ذات مغزى: اختَر أسماء وصفية للسمة containertiming لتسهيل عملية الإحصاءات.
• الموضع الاستراتيجي: طبِّق containertiming على الأقسام الدلالية المهمة لمقاييسك، مثل hero-section وproduct-grid وcheckout-form. ليس من الضروري قياس كل حاوية.
• تجاهُل المحتوى غير ذي الصلة: استخدِم containertiming-ignore على العناصر الفرعية التي لا يجب أن تؤثّر في مقاييس المكوّن، مثل الإعلانات أو العناصر الزخرفية.

كيف يمكن تفعيل "توقيت الحاوية"؟

يمكن تفعيل Container Timing API من الإصدار 147 من Chrome باستخدام العلامة chrome://flags/#enable-experimental-web-platform-features ومن سطر الأوامر باستخدام العلامة --enable-blink-features=ContainerTiming.

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

الملاحظات والمزيد من التفاصيل

يجب إرسال الملاحظات حول Container Timing API على شكل مشاكل في GitHub.

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

الخاتمة

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