Element Timing API

The Element Timing API lets a page explicitly mark important content so the browser can report when that content becomes visible. Frontend engineers can use these entries to measure user-visible rendering milestones beyond navigation and resource timings.

Element Timing is an opt-in browser performance API for measuring the rendering of selected elements. An element can be marked with the `elementtiming` attribute, and a `PerformanceObserver` can then receive `PerformanceElementTiming` entries of type `element`.

The reported entry includes timing information such as `renderTime` and, where applicable, `loadTime`. It also identifies the marked content and provides information such as its rendered intersection rectangle, allowing performance tooling to connect a timing measurement with what the user actually saw.

A common use case is measuring important images or text rather than treating page load as a single milestone. For example, a team might mark a hero image or an important piece of above-the-fold content and calculate how quickly that specific content becomes rendered.

Element Timing complements other performance APIs. Resource Timing describes network/resource activity, Paint Timing exposes standardized paint milestones, and Largest Contentful Paint identifies the largest relevant content painted in the viewport. Element Timing is more explicit: the application chooses which content deserves measurement.

Because the API is observer-based, production instrumentation should register the observer early enough to avoid missing relevant entries and should account for browser support. The `elementtiming` attribute is instrumentation metadata; it does not by itself make an element visually important or change layout behavior.

Key points

• Mark selected content with the `elementtiming` attribute.
• Observe `element` entries with `PerformanceObserver`.
• `PerformanceElementTiming` exposes rendering-related timing and element information.
• Use it for application-defined user-visible milestones such as important images or text.
• It complements, rather than replaces, LCP, Paint Timing, and Resource Timing.

Interview questions

What problem does the Element Timing API solve?

It lets developers measure when specific important content becomes visible instead of relying only on broad page or navigation timings. The page marks supported content with `elementtiming`, then observes `element` performance entries. This is useful for measuring application-specific milestones such as a hero image rendering. It gives performance tooling a direct connection between a timing measurement and selected content.

How do you observe Element Timing entries?

Use `PerformanceObserver` and observe entries with the `element` entry type. The callback receives a `PerformanceObserverEntryList`, from which the application can inspect each `PerformanceElementTiming` entry. Using `buffered: true` can allow the observer to receive qualifying entries that occurred before observation was registered, subject to browser behavior and API support. Instrumentation should generally be initialized early in the page lifecycle.

What information does a PerformanceElementTiming entry provide?

An entry can identify the marked content and expose rendering-related timing such as `renderTime`. Depending on the content and browser, it can also expose `loadTime`, geometry information, and intrinsic image dimensions where applicable. The exact useful fields depend on what kind of content was instrumented. The important distinction is that the entry describes a selected content rendering milestone rather than merely a network request.

How would you use Element Timing in a real frontend performance system?

I would first identify user-visible content whose rendering represents a meaningful product milestone, then instrument that content consistently. A `PerformanceObserver` would collect the entries and normalize their timing and identifying metadata before sending aggregated measurements to analytics. I would segment results by factors such as page type, device class, and connection characteristics rather than looking only at a global average. I would also compare these measurements with LCP and resource data to distinguish slow delivery from slow rendering or other bottlenecks.

When would you choose Element Timing instead of relying only on LCP?

I would use Element Timing when the product has an important content milestone that is not adequately represented by the largest qualifying element. LCP is standardized and useful for cross-site comparison, but it does not let an application arbitrarily nominate every business-critical visual. Element Timing allows explicit instrumentation of selected content, making it useful for product-specific performance goals. I would normally keep LCP as a complementary standardized metric rather than replacing it.