Intent to Implement: ElementTiming for img Elements

[n...@chromium.org]

Contact emails

n...@chromium.org, tdre...@chromium.org  

Explainer

Design doc/Spec

Implementation proposal

No spec nor tag review yet.

Summary

The ElementTiming API will allow developers to know when certain important (as specified by the developer) image elements are first displayed on the screen. It will also enable analytics providers to measure the display time of images that take up a large fraction of the viewport when they first show up.

Motivation

This API will help developers measure the time it takes for important elements to show on the screen. This will let them understand, measure, and improve the user pain when waiting for important elements to be displayed. We are only doing img for now to reduce the complexity and have a reasonable path to standardization.

Risks

Interoperability and Compatibility

I'm considering no public signals from other browser vendors, but... this new feature was discussed during one of the Web Perf Working Group calls. There was no opposition. Edge commented that onload could be fired after the image has rendered and requested we do not use onload as the signal on where to request the next paint.

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: Positive. Example: https://www.stevesouders.com/blog/2015/05/12/hero-image-custom-metrics/

Ergonomics

This will be an addition to the performance timeline and PerformanceObserver. The new ergonomic requirement for this API is the addition of an ‘elementtiming’ attribute so developers can specify the elements they care about.

Activation

This should be easy to use due to being part of the performance timeline and observable via PerformanceObserver.

Debuggability

None required, this is accessible from Javascript.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Link to entry on the feature dashboard

Requesting approval to ship?

No

[Yoav Weiss]

Thanks for working on this! It's an important addition to the platform, which will enable developers to start to keep track of visual performance metrics in the wild. 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/9a6db312-09a6-452c-9917-24bb49ddb062%40chromium.org.

[andy...@google.com]

Have there been any discussion around the privacy and security consideration for this feature?

The first thing that jumps to mind is that images can be registered by default if they occupy a specific amount of the viewport. Is is possible that this opens a new vector of attack on unaware websites, for example for deducing the logged in state of a user? Perhaps there should be a way to disable this behaviour?

I think it's definitely worth looking at this angle as soon as possible in the design/spec process.

Regards,

Andy Paicu

[n...@chromium.org]

Security and privacy are definitely valid concerns for this API and we have had some discussions internally about this. Our main claim is that you could technically polyfill this API by adding the desired element to its own frame and query PaintTiming on that frame. Will open a launch bug so we get proper security review shortly.

Note that this API is frame specific. In particular, you can already read the size of an image in a frame you can execute script in.