I've had a few people reach out to me recently asking for help with LCP issues where they are looking at optimising the wrong thing. They were asking what frontend improvements they could make when that was not the problem.
Yup it's time for another long thread to try to explain...
🧵 1/17
Yup it's time for another long thread to try to explain...
🧵 1/17
Comments
I give a workflow here: https://web.dev/articles/optimize-lcp#understanding_your_lcp_metric where I use the real user from CrUX in PSI to understand it more.
2/17
Oh 3.9 seconds is a bad LCP all right 😢 Should we dive right into the code? Look at Lighthouse? Do a trace in DevTools?
No! - understand the issue first! PSI is giving you so many more clues here.
PSI gets this real user data from CrUX but it often doesn't have URL-specific data and so falls back to the origin-level data when that happens. And for some sites it doesn't even have that!
We can see the TTFB is 2.7 secs. That's a major red flag! 🚩 TTFB is the 1st thing that happens to your page, so if it's 2.7 secs, then you've no chance of getting a 2.5 secs green LCP!
As @csswizardry.com once said "While a good TTFB doesn’t necessarily mean you will have a fast website, a bad TTFB almost certainly guarantees a slow one."
6/17
1) It takes too long to send a request to your server
2) You server takes too long to respond
But which it is (and why!) can be tricky to figure out and there's a few possible reasons for each of those categories.
7/17