Next.js: Largest Contentful Paint (LCP) issues

[rileytomasek]

Bug report

Describe the bug

Sites built with next.js are suffering from slow LCP on mobile devices. It appears that the page is loading fast and then something is causing a repaint much later in the load cycle, which is causing the LCP to count then, instead of when it was originally displayed. This is problematic for SEO.

To Reproduce

1. Got to a website built with next.js like https://vercel.com/
2. Run a Lighthouse performance audit in Chrome
3. Click the view trace button and observe the screenshot timeline. The element that claims to be causing the LCP shows up on the screen long before the reported LCP value.

Expected behavior

The LCP time should be from when the LCP actually occurs the first time. Something seems to be triggering the LCP much later, without making a visible change.

Screenshots

System information

• OS: macOS
• Browser: Chrome

Additional context

• These results are also consistent with what PageSpeed Insights reports.
• The same issue can also be seen on other next.js powered sites like: https://standardresume.co/
• This issue only seems to happen when testing mobile. The desktop reports show the LCP as the first time the page loads as seen in the screenshot timeline.

[awareness481]

I'm not sure how this realistically affects performance (I got 91 for vercel.com on Lighthouse) but the lower than usual performance score is caused by https://github.com/vercel/next.js/issues/16932

[rileytomasek]

It's important for SEO. Google is now reporting LCP values in Search Console and less than 2.5 seconds is considered a passing score.

[prateekbh]

This is due to a change in lighthouse.
Currently the way lighthouse works is that it fetches the trace on unthrottled network. Then simulate throttling on top of it.

What this means is that trace is taken on your high speed network and then simulations are done on top of it. This makes the numbers more in line with what you'd see on pagespeed insight etc. But as a side effect, when you click view trace you see the original/unthrottled network trace.

^ thats the reason why the two numbers doesn't match.

If you want to actually verify that its not the case uncheck the Simulate throttling checkbox and re-run the trace. now the numbers and the trace should match exactly.

[rileytomasek]

Thanks, @prateekbh. Being able to see the stack trace with accurate times confirms that this isn't a next.js issue. Seems like there is some room for improvement in the Chrome UI to avoid confusion here. I can't be the only person looking at traces to debug lighthouse reports.

[prateekbh]

@rileytomasek yes the feedback was received by the team and changes are on their way: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2339861