lighthouse
lighthouse copied to clipboard
GoogleChrome
Fixing "Ensure text remains visible during webfont load" issue causes worse mobile LCP score
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
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:
@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.
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.
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