[scottfr]

The LCP metric is particularly brittle. It's concerning Google is linking it to search ranking thereby ensuring everyone caters to it.

In our case, our hero image (formerly the LCP element Lighthouse picked up) is an animated image illustrating our product. It starts animating very fast for most of our audience and finishes loading in the background as it continues animating.

However, the Lighthouse LCP timestamp is not the time which the image starts animating, instead it's the time the animated image _completely finishes_ loading. So even though the animation starts almost right away and doesn't stutter, our LCP was several seconds or more.

We "solved" it by making the animation bounding box size slightly smaller and some text boxes on the page slightly larger so the LCP was tied to the text box loading.

[pornel]

There's a similar unsolved LCP issue about progressive images. LCP is currently completely unaware of progressive rendering, so even when an image is rendered at a good-enough quality, it doesn't count as a "paint" at all.

[GordonS]

Wow, it's not even like progressive JPEGs are anything new, they have been around forever (decades?)!

[jerf]

Yes, decades. I saw them in the 90s. They needed that feature to compete on the web during the dial-up era because GIF already had that feature, and it was well-established and featureful.

[FractalHQ]

Unbelievable. I have a website with an intro animation element that loads instantly and lasts 7 seconds. Guess what my LCP is? 7 seconds. The combination of power and neglect from google here is astounding.

[gentleman11]

My lcp is about 0.7 seconds in real life with no cache but 4s on web.dev due to a custom font that actually loads almost instantly (100ms or so). Their metrics are bugged out

[winrid]

You could also split the animation up and seamlessly switch.