Should content-set be used for text-based LCP entries

[sohomdatta1]

Currently, the specification implies that for a particular element on a HTML page, only one LCP entry will be generated. This is done by making use of a "content-set" that tracks elements that already have been included in LCP entries. (lcp-content-set reference in the specifications)

However, due to this, only the initial/first size of the element is reported via the LCP API which can be wrong/smaller/slower than their actual size to the user. I've outlined a scenarios below:

Scenario

Considering the following HTML and CSS.

index.html

<div class="large-text">Some kind of banner text</div>
<link rel="stylsheet" href="/css/style.css"></link>

/css/style.css

.large-text {
  font-size: 10em;
}

For this example, there are two seperate paints being done by the browser. The first paints the text in it's fallback/default size, and the second one (occuring after the CSS is loaded) paints the text to the desired size of 10em. However, we are only reporting the results of the first paint via the API leading to a much smaller LCP value than what is experienced by the user.

Additionally if the element rehydrates (is replaced by the same element via JS), the LCP is reported again for that particular paint, despite there being no visible shift/repaint for the user. Because the LCP entry is reported at a much later point, this might cause pages to be reported as being much slower than they actually are to the user.

---

References

• crbug.com/1309025
• crbug.com/1213220
• crbug.com/1237754
• crbug.com/1310995

[yoavweiss]

IMO, it makes sense for us to keep track of those extra paints of already painted elements.
For the rehydration case, wouldn't the element be re-rendered in the same size, resulting in no LCP reporting?

/cc @philipwalton @mmocny @clelland

[clelland]

Agreed -- rendered text size can change drastically, even if the CSS style is set early, in the case of web fonts loading slowly, for instance.
Should we also be reconsidering a text node as an LCP candidate if its content changes?

For the rehydration case (assuming that an element is replaced by itself,) I think the problem is with the current model. Because we don't update LCP when the node changes size, but we do update if a node is inserted into the DOM, we're reporting the new size potentially much later than we should be. (On re-insert, rather than at resize time)

[clelland]

Chrome is planning on experimenting with this change -- semantically, it seems like the right thing to do: if style or content changes trigger a new paint, and that paint is the largest one so far, then that should potentially count as LCP.

The experiment is to make sure that this doesn't have undue effects on the metrics in the wild; if it look like this pattern is common enough, and the timing differences are drastic enough, then we might have to consider whether a more limited scope is worth pursuing initially.