Barry suggests the following tricks to get around the CDN’s cache:
Test the slow page by adding a URL parameter (like adding “?XYZ” to the end of the URL).
Test a page that isn’t commonly requested.
He also suggests a tool that can be used to test specific countries:
“You can also check if it’s particularly countries that are slow—particularly if you’re not using a CDN—with CrUX and @alekseykulikov.bsky.social ‘s Treo is one of the best tools to do that with.
You can run a free test here: treo.sh/sitespeed and scroll down to the map and switch to TTFB.
If particular countries have slow TTFBs, then check how much traffic is coming from those countries. For privacy reasons, CrUX doesn’t show you traffic volumes, (other than if it has sufficient traffic to show), so you’ll need to look at your analytics for this.”
Regarding slow connections from specific geographic areas, it’s useful to understand that slow performance in certain developing countries could be due to the popularity of low-end mobile devices. And it bears repeating that CrUX doesn’t reveal which countries poor scores are coming from, which means bringing in Analytics to help with identifying countries with slow traffic.
5. Fix What Can Be Repeated
Barry ended his discussion by advising that an issue can only be fixed once it’s been verified as repeatable.
He advised:
“For server issues, is the server underpowered?
Or the code just too complex/inefficient?
Or database needing tuning?
For slow connections from some places do you need a CDN?
Or investigate why so much traffic from there (ad-campaign?)
If none of those stand out, then it could be due to redirects, particularly from ads. They can add ~0.5s to TTFB – per redirect!
Try to reduce redirects as much as possible:
– Use the correct final URL to avoid needing to redirect to www or https.
– Avoid multiple URL shortener services.”
Takeaways: How To Optimize For Largest Contentful Paint
Google Chrome’s Barry Pollard offered five important tips.
1. PageSpeed Insights (PSI) data may offer clues for debugging LCP issues, plus other nuances discussed in this article that help make sense of the data.
2. The PSI TTFB (Time to First Byte) data may point to why a page has poor LCP scores.
3. Lighthouse lab tests are useful for debugging because the results are repeatable. Repeatable results are key to accurately identifying the source of a LCP problems which then enable applying the right solutions.
4. CDNs can mask the true cause of LCP issues. Use the Barry’s trick described above to bypass the CDN and fetch a true lab score that can be useful for debugging.
5. Barry listed six potential causes for poor LCP scores:
Server performance
redirects
code
database
Slow connections specific due to geographic location
Slow connections from specific areas that are due to specific reasons like ad campaigns.
Read Barry’s post on Bluesky:
I’ve had a few people reach out to me recently asking for help with LCP issues
Featured image by Shutterstock/BestForBest