Lighthouse LCP/FCP Discrepancy - Local vs. Production vs. Real-World #16387
-
|
Hi everyone, I'm facing a very perplexing issue with Lighthouse reporting drastically inflated LCP and FCP times, while real-world performance is excellent. I've exhausted most standard troubleshooting steps and suspect something is specifically confusing Lighthouse. Here's the breakdown:
The page loads instantly on any device I test, both locally and in production. Key Points:
My suspicion: Something is causing Lighthouse to misinterpret the page's loading process. Questions:
Thanks in advance for your help! |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
|
This topic comes up a lot. Different performance numbers are not unexpected when the environments you are testing are different. It's hard to say exactly would be causing such a huge difference in LCP without looking at the page. You may find the following resources helpful: https://github.com/GoogleChrome/lighthouse/blob/main/docs/variability.md |
Beta Was this translation helpful? Give feedback.
-
|
Thank you Adam.
I suspect some of it might be because slow CPU and high latency is
simulated with lighthouse. It doesn't completely explain it.
I also noticed that I have about 80 small chunks. I suspect it's difficult
for lighthouse to process these effectively.
…On Mon, Mar 17, 2025, 5:43 PM Adam Raine ***@***.***> wrote:
This topic comes up a lot. Different performance numbers are not
unexpected when the environments you are testing are different.
It's hard to say exactly would be causing such a huge difference in LCP
without looking at the page. You may find the following resources helpful:
https://github.com/GoogleChrome/lighthouse/blob/main/docs/variability.md
https://github.com/GoogleChrome/lighthouse/blob/main/docs/throttling.md
—
Reply to this email directly, view it on GitHub
<#16387 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADBNDTEWBOTQFAEJO6JYCWT2U5FXVAVCNFSM6AAAAABZFQRQTSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTENJTGEYTCNI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
It's worth remembering that you'll see VERY different results testing your dev mode localhost with http 1 and no SSL. It really isn't worth comparing those two environments because they're so fundamentally different from each other. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @benschwarz thank you for the feedback. I suspect lighthouse has trouble with large number of small chunks (which is not the case for modern browsers). |
Beta Was this translation helpful? Give feedback.
-
|
@TomerHeber If you're referring to 80 small HTTP requests — they're loaded by Chrome, so there shouldn't be much overhead for Lighthouse itself, except when it comes to processing the trace recorded from Chrome's devtools API protocol. If there's a lot of events (JS activity), the trace can get larger, but that isn't going to directly effect the performance metrics. The differences you're observing are more than likely the diff between measuring localhost vs prod. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @benschwarz , I decreased the number of chunks by half and can confirm I'm getting better results. Thank you for the assistance. https://pagespeed.web.dev/analysis/https-urlert-com/sccceus0a1?form_factor=mobile |
Beta Was this translation helpful? Give feedback.
@TomerHeber If you're referring to 80 small HTTP requests — they're loaded by Chrome, so there shouldn't be much overhead for Lighthouse itself, except when it comes to processing the trace recorded from Chrome's devtools API protocol. If there's a lot of events (JS activity), the trace can get larger, but that isn't going to directly effect the performance metrics. The differences you're observing are more than likely the diff between measuring localhost vs prod.