Re: [w3ctag/design-reviews] Element Timing API (images and text) (#326)

> I believe David was referring to whether you track when the first frame loaded or when all the frames did (think .GIF file)

First paint after the image is loaded and fully decoded.

> Also could it be used as a way to detect resource blockers, like if the measured time is too short, it is likely that the original picture was replaced by a 1x1 transparent gif, or something like that. Is there a mitigation against this?

A resource blocker returning a 1x1 GIF is easily detectable by looking at the intrinsic size of the image. And even if it returns the same size, the image onload can be used to time whether it is the trivial image or the expensive image. In other words, Element Timing is not needed to detect the resource blocker. The mitigation is that we return a rounded rendering timestamp (nearest 8ms).

> Have you thought about rate limiting the feature? So that you cannot use it on each load, or by introducing some time before you can measure again?

No. As a developer, I would expect that an element with elementtiming attribute will be exposed always. Then there is the question of whether entries from implicit registration (right now, occupying a large portion of the viewport) are expensive to compute. For that, we need further investigation to determine whether or not this causes any performance problem. If it does, I'd prefer changing the criteria for implicit registration so that it is faster to compute, rather than rate limiting.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/326#issuecomment-495333903