---
title: "Container timing (Help Center / Settings / Custom timing)"
ai_context: "Use this article for questions about RUMvision Container Timing, the experimental `containertiming` HTML attribute, component-level performance, section render timing and measuring when larger parts of a page become visibly available to users. It explains how RUMvision collects Container Timing entries as custom metrics, how Container Timing differs from Element Timing, and why it is useful for progressively rendered or client-side rendered components. Relevant for questions about hero sections, product variant selectors, checkout summaries, search results, cookie notices, recommendations, reviews, third-party widgets, React or Vue components, SPA rendering and JavaScript-populated sections. It also covers multiple paint entries for the same container, configuring `data-container-timing-until`, stopping after a number of entries or interactions, stopping at LCP, choosing timing fields such as `presentationTime`, `startTime` or `paintTime`, subtracting FCP, and excluding child content with `containertiming-ignore`. Relevant search terms include Container Timing API, `containertiming`, component timing, component render time, section paint timing, progressive rendering, client-side rendering, component visibility, when a component appears, custom component metrics, PerformanceObserver container entries, `presentationTime`, `paintTime`, `startTime`, `containertiming-ignore`, skeleton loaders, delayed widgets, SPA component performance, React component timing, Vue component timing, cookie banner timing and measuring UI components independently from Core Web Vitals. The article also explains current browser limitations and that Container Timing is an experimental API available through a Chromium Origin Trial rather than broadly supported stable browser functionality."
canonical: "https://www.rumvision.com/help-center/settings/custom-performance-timing/container-timing/"
---

Breadcrumbs: [Home](https://www.rumvision.com/?format=md) > [Help Center](https://www.rumvision.com/help-center/?format=md) > [Settings](https://www.rumvision.com/help-center/settings/?format=md) > [Custom timing](https://www.rumvision.com/help-center/settings/custom-performance-timing/?format=md) > Container timing

# Container timing

**In short:** Add the `containertiming` attribute to important sections or components to collect when their visible content is painted as custom metrics in RUMvision.

Container Timing is useful when you want to measure a complete section or component rather than one specific image or text element.

By adding a `containertiming` attribute, you tell the browser which container you want to observe. As visible content inside that container is painted, the browser can expose timing entries that RUMvision collects as metrics.

 ```
containertiming="product-variants"
```

Unlike Element Timing, Container Timing can continue producing entries when more visible content is added to the same component later. This makes it particularly useful for dynamic interfaces and client-side rendered content.

For a more detailed introduction, implementation examples and current browser support, see our [Container Timing blog article](https://www.rumvision.com/blog/container-timing-measuring-when-components-actually-appear/?format=md).

## What you can collect

RUMvision supports **Container Timing** as a custom metric.

[![organisation-container-timing.png](https://www.rumvision.com/file/upload/img/help-center/organisation-settings/organisation-container-timing.png)](https://www.rumvision.com/file/upload/img/help-center/organisation-settings/organisation-container-timing.png)

The metric represents when visible content inside a configured container was painted.

For example:

 ```
containertiming="checkout-summary"
```

You can then create a Container Timing custom timing in RUMvision using:

 ```
checkout-summary
```

RUMvision will observe entries with that identifier and make the resulting timing available as a metric in your charts and analysis.

## How Container Timing differs from Element Timing

Element Timing is designed for specific supported elements, such as images or text-containing elements.

Container Timing instead allows you to mark a broader section of the page by wrapping multiple elements in a div or section, and mark that as hero:

 ```
section containertiming="hero"
```

This lets you measure the component as a whole rather than choosing one individual child element.

Another important difference is that Element Timing is effectively a one-shot signal for an element. Container Timing can emit additional entries when more content inside the marked container is painted later.

That makes Container Timing especially useful for components that render progressively.

## Choosing good containers

Use Container Timing for components that are both visible to users and meaningful to the user experience.

Good examples include:

- hero sections;
- product variant selectors;
- checkout summaries;
- search results;
- cookie notices;
- recommendations;
- reviews;
- third-party widgets.
 
Choose stable and recognizable identifiers such as:

 ```
containertiming="hero"  containertiming="product-variants"  containertiming="checkout-summary"  containertiming="consent-banner"
```

Avoid identifiers that contain product IDs, user-specific values or other highly dynamic information. This would create many different values and make the resulting data harder to analyse.

## Client-side rendered components

Container Timing is not limited to server-rendered HTML.

It can also be used for components that are populated by JavaScript later in the pagelifecycle. This makes it useful for React, Vue and other client-side rendered applications, as well as components loaded by third-party scripts.

The important requirement is that the `containertiming` attribute exists **before the paint you want to measure happens**.

Adding the attribute after the relevant content was already painted will not retroactively create the missing timing entry.

## Progressive rendering

A marked container can produce multiple timing entries.

For example, a product component might first render its title and price, while product variants or availability information appear later.

Container Timing can report these subsequent paints as new entries.

This creates an important question: **which entry represents the moment that component is useful or complete for your visitors?**

RUMvision provides additional configuration for controlling which entry is ultimately collected.

## Controlling when RUMvision stops tracking

You can use the `data-container-timing-until` attribute to further configure how RUMvision handles Container Timing entries.

For example:

 ```
containertiming="product-variants" data-container-timing-until='{"entries":1}'
```

RUMvision supports configuration such as:

- `entries` to stop after a specific number of Container Timing entries;
- `interactions` to stop after a number of user interactions;
- interaction-specific limits for events such as clicks or key presses;
- `lcp` to stop collecting once LCP has occurred;
- `subtract` to subtract another timing, such as FCP;
- `value` to choose which numeric timing value from the Container Timing entry should be reported.
 
This lets you adapt the metric to the behaviour of the component you are measuring.

## Choosing the timing value

Container Timing entries can expose multiple timing values.

By default, RUMvision uses `presentationTime` when available and falls back to `startTime`.

You can override this using the `value` configuration:

 ```
containertiming="product-variants" data-container-timing-until='{"value":"paintTime"}'
```

This can be useful when you specifically want to collect another numeric field from the Container Timing entry.

## Measuring time after FCP

An absolute component render time does not always tell the complete story.

For example, if the whole page starts rendering late, a component may also receive a high Container Timing value even though that component itself was not responsible for most of the delay.

You can therefore subtract another metric such as FCP:

 ```
containertiming="consent-banner" data-container-timing-until='{"subtract":"fcp"}'
```

This allows you to analyse how much additional time passed between FCP and the component becoming visible.

That can make the metric more actionable when investigating delayed components.

## Ignoring content inside a container

Not every visible update inside a component is necessarily relevant.

For example, a cookie notice may contain buttons or controls that should not affect the timing you care about.

You can exclude such elements using `containertiming-ignore`, for example on buttons:

 ```
button containertiming-ignore
```

This can also be useful for placeholders, skeleton loaders or other UI elements that should not contribute to the component timing.

## Example use cases

Container Timing is especially useful for components whose availability matters to the user but which are not reliably represented by Core Web Vitals.

For example:

- A product variant selector can determine when a visitor is able to choose a product configuration.
- A search result grid can represent the actual moment search becomes useful.
- A checkout summary can indicate when a customer has enough information to continue.
- A cookie notice can block access to the page while not consistently becoming the LCP element.
- A third-party widget can be measured independently from the rest of the page.
- Recommendations or reviews loaded through JavaScript can be measured when they actually become visible.
 
This helps answer a more specific question than page-level metrics alone:

> When did this particular part of the page actually become visible to the user?

## Browser support

Container Timing is still an experimental API.

At the time of writing, it is available through a Chromium Origin Trial rather than as a broadly supported stable web platform feature.

This means collected Container Timing data should currently be treated as experimental field data. API behaviour, timing fields and browser support can still change as the specification evolves.

For current implementation details, Origin Trial information and examples, see our [Container Timing blog article](https://www.rumvision.com/blog/container-timing-measuring-when-components-actually-appear/?format=md).