There are a couple of limitations to how we capture visual rendering time as the analysis we do is based on the final frame of the filmstrip. Here's a few reasons you might see rendering time slower than you expected:

Layered elements

One limitation of hero rendering times is that they are affected by elements over the top of an image. When doing the visual analysis we use the last frame of the filmstrip as the final state of the page, we then crop down to the area of the image or H1 and use that to search across the filmstrip and find which time first matches that final state of the page.

This means that when elements are layered over the top of each other the rendering time we capture is for the combination of visual elements.

Moving elements

When looking for a visual match for rendering times we also take into account its position on screen so if an element moves around the screen that can delay the time we report.

Elements that move around in the page as it renders can be distracting for users so may want to look at stopping the H1 moving around which would also improve the rendering time we capture.

Hero Element Timing

Default metrics are important to have – not least because they're based on universal page elements, which means you can use them to compare your site to your competitors. But chances are you want to get a more nuanced look at hero elements that are unique to your site, your pages, and your users. This is where Hero Element Timing comes in. 

Hero Element Timing – which is based on the Hero Element Timing API – lets you select and annotate specific hero elements on your pages, such as search boxes, image carousels, and blocks of text.

Right now, you can follow the instructions in the API spec to annotate your pages, and see the results in your SpeedCurve results. (As a bonus, when browsers inevitably catch up and adopt the spec, you'll be ahead of the game.)

<div elementtiming=”foobar” class=”...” >
Did this answer your question?