element-timing
element-timing copied to clipboard
WICG
Support canvas element for element timing
As discussed shortly in the WebPerfWG meeting on 7/2/2020 I'm filing this as an issue for the project.
Current element timing spec (as of 7/5/2020) does not support HTML canvas ( <canvas> ) as an element type which can be tracked.
There is an important use case where mostly static user content is created using HTML Canvas elements. The static content creation may be expensive and done on a Canvas which is not added to the DOM body or perhaps even computed using a WebWorker with OffscreenCanvas context.
Without being able to use element timing performance metrics it is non-trivial (if not impossible) to get accurate timing measurements on when the Canvas element has be painted and displayed to the user. A "workaround" is to try capture the time on the next rAF after the canvas element was added to the DOM.
I propose to add HTML Canvas element to the supported DOM element types. After a canvas element has been added to the DOM and rendered it would be tracked the same way the spec defines how to measure the timing of other supported elements.
It probably should not measure every canvas paint after it has been added to the DOM since this may turn out to be too noisy - especially for animation rich usages. I would like to thing that Canvas element has some similarity to Image element so I wonder how much harder it would be to add it to a specification.
An example of simple usage could be like this:
var canvas = document.createElement("canvas");
canvas.setAttribute("elementtiming", "my-canvas-timing");
var ctx = canvas.getContext("2d");
// draw something on the canvas (can be very complex drawing sequence)
ctx.fillRect(10, 10, 200, 200);
const observer = new PerformanceObserver((list) => {
let perfEntries = list.getEntriesByType("element");
const canvasTiming = perfEntries.filter(e => e.identifier === "my-canvas-timing")[0];
console.log(canvasTiming);
});
observer.observe({type: 'element', buffered: true});
// add canvas to the DOM and time when it has been painted
document.body.appendChild(canvas);
Are there any limitations, downsides for this proposal?
This seems reasonable to me, although it would be great to hear from some Element Timing API users (or potential users) that this would be useful to them.
More broadly I would love to see all types of content considered for FCP be used by element timing (and specifically then LCP).
I originally filed https://bugs.chromium.org/p/chromium/issues/detail?id=1122168 but was redirected here as LCP follows this spec :)
I agree we should reconsider this since some sites rely on canvas to produce their main content.
No, sorry :( @MatRivard do you have some use-cases you could share? I think having concrete developers and sites interested in using this will help prioritize it more.
No worries @npm1, thank you for the quick response. Not extremely pressing, we were just testing on the landing page below and noticed the performance error in lighthouse within chrome dev tools while running an audit. Would be nice to be able to see LCP and performance score for pages using SVGs. By no means an urgent issue :) thank you!
https://www.gridworkdigital.com/
SVG is pretty complex so I filed https://github.com/WICG/element-timing/issues/56 to track that separately!