Core Web Vitals: what actually moves Largest Contentful Paint
Most LCP advice assumes your largest element is an image. Often it is text — and then the fix is completely different.
Largest Contentful Paint measures when the biggest thing in the viewport finishes rendering. Almost every guide assumes that is the hero image, so almost every guide recommends image optimisation. Check first: on a lot of business sites, the LCP element is the headline, and compressing images will not move the number at all.
Find the element before choosing the fix
Run a lab test and read which element was actually measured. If it is text, your LCP is governed by fonts and by whatever blocks rendering ahead of them. If it is an image, it is governed by discovery time, priority and transfer size. These are different problems with almost no overlapping fixes.
When the LCP element is text
- Preload the specific font files used above the fold, and only those.
- Use font-display: swap so text renders in a fallback immediately rather than waiting.
- Subset fonts to the character range you actually serve — full font files often carry several times the glyphs you need.
- Remove render-blocking CSS and JavaScript ahead of the headline; inline the small amount of CSS needed for the first screen.
When the LCP element is an image
- Make it discoverable in the initial HTML rather than injected by script or set as a CSS background.
- Mark it fetchpriority="high" and never lazy-load it — lazy-loading the hero is the single most common self-inflicted LCP problem.
- Serve modern formats at the size actually displayed, with correct width and height attributes so nothing shifts.
- Check the server response time underneath it. If time to first byte is high, no image work will save you.
The order that saves time
Server response time first, because it is a floor under everything else. Then render-blocking resources. Then the LCP element itself. Then everything else. Working in that order means each fix is measurable; working in the opposite order means several changes and no clear cause.
One caution: Core Web Vitals are scored on real user data, not on the lab test. Lab tools tell you what to fix; field data tells you whether it worked, and it lags by weeks. Fix, then wait, then judge.
The services behind this post.
Frequently asked questions.
No. Passing the thresholds on real user data is what counts; the last few points of a lab score usually cost more than they return.
Field data is reported on a rolling window of several weeks, so expect a lag before the improvement is fully reflected.
Talk to the team that does this every day.
Tell us what you're trying to grow. You'll get a plan, not a pitch.
Contact Us