GoogleChrome / GoogleChrome/lighthouse
Fixing "Ensure text remains visible during webfont load" issue causes worse mobile LCP score
- Dominant language
- JavaScript
- Stars
- 30.8k
- Forks
- 9.8k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 19
Description
### FAQ
- [X] Yes, my issue is not about [variability](https://github.com/GoogleChrome/lighthouse/blob/master/docs/variability.md) or [throttling](https://github.com/GoogleChrome/lighthouse/blob/master/docs/throttling.md).
- [X] Yes, my issue is not about a specific accessibility audit (file with [axe-core](https://github.com/dequelabs/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_
Contributor guide
Assessment
This issue has not been assessed yet.