[Proposal] Element Timing

Nicolas_Pena · 2018-07-06

The Element Timing API provides timing on when elements are displayed. This first proposal is restricted to <img> elements to make it simpler:

github.com

npm1/Element-Timing/blob/master/README.md

# Element Timing V1 Explainer

tdresser@, npm@

Last updated July 5, 2018

The **Element Timing** API enables monitoring when large or developer-specified image elements are displayed on screen.


### Objectives

1.  Inform developers when specific 'hero' elements are first displayed on the screen. To keep the first version of this API simpler and have an easier path towards standardization, we restrict to HTML 'img' elements. Web developers can better understand which are the critical images of their sites, so after annotating them the browser can provide timing information about those elements.
1.  Enable analytics providers to measure display time of key images, without explicit opt in from web developers. In many cases it's not feasible for developers to modify their HTML just to get better performance insights, so it's important to provide basic information even for websites that cannot annotate their elements.


### How do we register images for observation?

There are two ways an image can be registered for observation: via an HTML attribute and when the image takes a large portion of the viewport when it is first displayed.

#### Attributes

This file has been truncated. show original

Garbee · 2018-07-07

What would this do that an Intersection Observer doesn’t allow for? You can use an Intersection Observer to know when a node is in the active viewport. And then do something based on that event. It sounds exactly like what your intended goal is, except far more widely applicable to web applications.

Nicolas_Pena · 2018-07-09

The main reason this is preferred over Intersection Observer is because we want to avoid forcing developers to run Javascript very early in the page load. You’d need to run a script that registers the Intersection Observer very early on for it to work. This would not be required with Element Timing because the PerformanceObserver could be created with a buffered flag that provides values measured before its creation.

Also, IntersectionObserver wouldn’t be ergonomic for this use case: handling the question of when the element has loaded, wanting only the first update for the element, etc.

Nicolas_Pena · 2019-02-21

We are still interested in moving forward with the proposal and have evolved it a bit.

cvazac · 2019-02-22

As part of the origin trial, we prototyped a plugin to collect the new Element Timing data. And we have a few ideas for features built on top of this data.

We anxiously await ET landing in Chrome by default!

Nicolas_Pena · 2019-02-25

Since there seems to be some support to this feature, I’d like to move the repo to WICG and continue incubating it from there. I’ll have a spec to accompany the explainer soon.

yoavweiss · 2019-02-25

Thank you for incubating WICG! The repo has now moved and is at https://github.com/WICG/Element-Timing