גרסת מקור לניסיון של Container Timing

Barry Pollard

Jason Williams

José Dapena Paz

תאריך פרסום: 1 במאי 2026

החל מ-Chrome 148,‏ Chrome משיק גרסת מקור לניסיון של Container Timing performance API.

מדדים כמו Largest Contentful Paint ‏ (LCP) מספקים סקירה כללית של הזמן שבו סביר להניח שהמשתמש יראה את הדף כ'נטען', על סמך זמן הצגת התוכן הגדול ביותר. עם זאת, יכול להיות שבעלי אתרים יתעניינו גם במועד הטעינה של חלקים מסוימים בדף, ולא רק בחלק ה "גדול ביותר".

Element Timing מאפשר לאתרים לתייג רכיבים באמצעות מאפיין elementtiming כדי להבין מתי הם נטענים, בין אם הם רכיב ה-LCP ובין אם לא. עם זאת, כמו LCP, הוא מוגבל למדידת זמני העיבוד של רכיבים בודדים.

התזמון של קונטיינרים מרחיב את הרעיון של תזמון רכיבים כדי למדוד 'בלוקים של תוכן' (או 'קונטיינרים'). כך תוכלו להבין מתי רכיב שלם היה זמין למשתמש, כמו ווידג'טים, כרטיסים, קטעי תוכן, סרגלי צד וכו'. הוא מספק מידע נוסף על הביצועים של אתרים שרוצים לקבל תובנות נוספות.

התכונה Container Timing, שפותחה על ידי Bloomberg והוטמעה ב-Chrome על ידי Igalia, זמינה מאחורי דגל למשתמשי Chrome ולדפדפנים אחרים שמבוססים על Chromium. היא זמינה גם לאתרים לבדיקה בשטח באמצעות גרסת מקור לניסיון.

גרסת מקור לניסיון היא אחד השלבים האחרונים בהשקת API. במהלך גרסת המקור לניסיון, מפתחים יכולים להפעיל את התכונה באתרים שלהם לפני שהיא מושקת כברירת מחדל, כדי לבדוק אותה ולעדכן את הצוות אם היא פועלת כמצופה ומועילה. בנוסף, המפתחים יכולים להציע שינויים בעיצוב של ממשק ה-API לפני ההשקה.

איך Container Timing API פועל

בדומה ל-Element Timing, ‏ Container Timing פועל על ידי הוספת מאפיין (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, תוכלו לראות את הפעולה הזו גם בסרטון הבא:

אילו עדכונים נספרים ב-Container Timing?

המטרה של Container Timing היא לתעד את הרגע שבו הקונטיינר נטען עם כל רכיבי הצאצא. המדד לא נועד למדוד כל ציור עתידי – הרבה מהם עשויים להגיע הרבה יותר מאוחר כשהמשתמש מקיים אינטראקציה עם הקונטיינר או הדף. לכן, בדומה ל-LCP ולתזמון רכיבים, תזמון מאגרי תגים תלוי ב'טעינות של תוכן', והוא גם לא פולט רשומות חדשות של טעינות עבור רכיבים שכבר נספרו כרכיבים עם טעינה של תוכן.

לדוגמה, אם קומפוננטת container מוצגת בהתחלה רק עם צבע רקע, או שהיא מכילה רק רכיבים ללא תוכן (למשל, מסכי skeleton), לא ייפלט רכיב container עד שיוסף תוכן לקומפוננטה.

לדוגמה, אם מעדכנים טקסט ברכיב קיים במאגר התגים, לא תתווסף רשומה חדשה של container לעדכון הזה, כי נלקח בחשבון רק הצגת תמונה ראשונית במסך (FP) של התוכן של רכיב. עם זאת, אם מוסיפים טקסט לרכיב ריק, או אם מוסיפים רכיב חדש נוסף לטקסט הזה, תונפק רשומה חדשה של container כי זה יהיה הצגת תמונה ראשונית במסך (FP) של הרכיב הזה.

תמיכה בתזמון קונטיינרים עם זיהוי תכונות

המאפיין containertiming לא יגרום לבעיות בדפדפנים שלא תומכים בו, ולכן אין צורך בזיהוי תכונות.

ה-PerformanceObserver יתעלם מכל הערכים החדשים, אבל הם עלולים לגרום להצגת אזהרות בכלי הפיתוח, ולכן מומלץ לבצע זיהוי תכונות לפני שמוסיפים אובייקט Observer באמצעות קוד כמו:

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

שיטות מומלצות

כדי להשתמש בתזמון של מאגרי תגים בצורה אופטימלית, מומלץ לפעול לפי השיטות המומלצות הבאות:

• הגדרת מאפיינים מוקדם ככל האפשר: כדי שהמעקב יהיה מלא, צריך להוסיף את המאפיין containertiming במסמך ה-HTML או לפני שהרכיב מתווסף למסמך. אם מוסיפים את המאפיין באמצעות JavaScript אחרי שהדף נטען, יכול להיות שהצביעה לא תתבצע.
• שימוש במזהים בעלי משמעות: כדאי לבחור שמות תיאוריים למאפיין containertiming כדי להקל על הניתוח.
• מיקום אסטרטגי: כדאי להשתמש ב-containertiming בקטעים סמנטיים שחשובים למדדים שלכם, למשל hero-section, product-grid, checkout-form. לא צריך למדוד כל מאגר תגים.
• התעלמות מתוכן לא רלוונטי: אפשר להשתמש ב-containertiming-ignore ברכיבי צאצא שלא אמורים להשפיע על מדדי הרכיב, כמו מודעות או רכיבים דקורטיביים.

איך מפעילים את התכונה Container Timing (תזמון מאגר התגים)?

אפשר להפעיל את Container Timing API מגרסה Chrome 147 באמצעות הדגל chrome://flags/#enable-experimental-web-platform-features ומשורת הפקודה באמצעות הדגל --enable-blink-features=ContainerTiming.

מגרסה Chrome 148, אתרים יכולים להירשם לטוקן של גרסת מקור לניסיון ולהוסיף אותו לדף שלהם כדי להפעיל את התכונה באופן אוטומטי. כך תוכלו לבדוק את ה-API בשטח על משתמשים אמיתיים. אפשר לתעד מדדים של תזמון מאגרי תגים בניתוח נתונים ולנתח אותם כדי לוודא שה-API פועל כמצופה וכדי לקבל תובנות.

משוב ופרטים נוספים

משוב על Container Timing API צריך להישלח כבעיות ב-GitHub.

יש גם מפרט שנמצא בתהליך סטנדרטיזציה. אם אתם רוצים לדעת איך ה-API הזה פועל באופן פנימי, חברת Igalia פרסמה פוסט שמסביר איך ה-API הוטמע מבחינה טכנית.

סיכום

אנחנו שמחים לראות שה-API הזה מתקרב להשקה, ומתרגשים להעביר אותו לידי המפתחים כדי לאפשר להם לקבל תובנות חדשות לגבי בעיות בביצועים. אנחנו מצפים לקבל משוב על ה-API, ואם הכול יתנהל כשורה, נשיק אותו זמן קצר לאחר מכן.