Fixing "Ensure text remains visible during webfont load" issue causes worse mobile LCP score

[greyvugrin]

FAQ

• [X] Yes, my issue is not about variability or throttling.
• [X] Yes, my issue is not about a specific accessibility audit (file with axe-core instead).

URL

https://staging.the-atlas.com/projects/using-green-infrastructure-to-green-camden-city

What happened?

We are trying to optimize the LCP score for a universal JS app, using Nuxt (and Vue.js).

On our live site, we have an LCP of 3.5s for some pages.

One of the suggestions from https://pagespeed.web.dev/ on our staging site was to fix the webfont FOIT issue ("Ensure text remains visible during webfont load").

After implementing the fix (adding font-display: swap; to our CSS), we saw an improvement in the Desktop score for LCP (1.6s -> 1.1s).

But for mobile, it went significantly up. From 3.7s to 9s.

We were confused about the outcome on mobile, so tried reverting the change and re-testing on staging. Same result.

What did you expect?

We expected to see an improvement on the mobile side as well, or at least not a huge decrease in the site score for that metric.

What have you tried?

We tried removing the code and retesting, to ensure it was not a fluke related to variability.

We did see a better outcome when using Lighthouse 9.4.0 via Chrome Devtools - this showed us 1.8s for the LCP, after the change.

How were you running Lighthouse?

PageSpeed Insights

Lighthouse Version

9.3.0

Chrome Version

No response

Node Version

No response

OS

Mac

Relevant log output

No response

[adamraine]

I am seeing a large LCP value (~14s) when running on DevTools in M100 with mobile settings Report.

On DevTools in M102 (Canary) I'm getting a much lower LCP (~1s) Report.

It looks like the difference is caused by the two reports having different LCP elements. Perhaps upgrading Lighthouse or Chrome in PSI will resolve this.

@greyvugrin what is the reported LCP element when you get an LCP value of ~9s? When I get a high LCP it's this:

[greyvugrin]

@adamraine it's showing the H1 for me on mobile when it has a high LCP, which is the same element as desktop, and the same element that was showing a 3.5s LCP before the change.

Your screenshot seems to be using a different width for the device, so maybe that's affecting things?

Also, it seems to be performing as expected with devtools running 9.4.0, but the Pagespeed Insights page using 9.3.0 is consistently giving the 9s result.

[adamraine]

Your screenshot seems to be using a different width for the device, so maybe that's affecting things?

Yeah that was #13642 which shouldn't affect this. I was able to reproduce on PSI with 9s LCP and the same element since then.

[adamraine]

This might be a bug in Chromium. The attached trace from PSI produces a ~9s LCP after throttling, and it looks like the LCP event is emitted well after the h1 element is initially painted.

https://gist.github.com/adamraine/bb6cbe940a726a4c4a015d90f15e6ca8