To improve Largest Contentful Paint (LCP), find which of its four parts is slow, then fix that part. Google's target is 2.5 seconds or less. Most slow pages lose time to a slow server response or a late-loading hero image, so check those two before touching anything else.
What is LCP and what is a good score?
LCP measures how long it takes for the largest visible element, usually a hero image or a big block of text, to render after the page starts loading. It is one of the three Core Web Vitals. According to Google's LCP optimization guide, a good LCP is 2.5 seconds or less, and anything over 4.0 seconds is poor. The target applies to at least 75% of page visits, so one fast test on your laptop proves little.
Why guessing fails
Most LCP advice is a list of ten tips: compress images, use a CDN, minify code. Each tip fixes one specific delay. If your delay is somewhere else, you can spend a week and move the score by nothing. The better method is to split the load into its parts and fix the biggest one.
The four parts of LCP
The same Google guide breaks LCP into four subparts and gives a rough guide to how the time should be spread:
| Part | What it is | Ideal share |
|---|---|---|
| Time to first byte (TTFB) | Wait for the server to start sending the page | About 40% |
| Resource load delay | Gap before the browser starts fetching the LCP image | Under 10% |
| Resource load duration | Time to download the LCP image or font | About 40% |
| Element render delay | Gap between the file arriving and it appearing | Under 10% |
Google presents these as guidelines, not strict rules. The useful signal is a part far above its share. The two delay parts should be close to zero, so a large number in either one is a bug, not a cost of doing business.
How do you find which part is slow?
- Open the page in Chrome DevTools, run a Performance recording, and look at the LCP marker. Chrome shows the LCP element and the subpart timings.
- Note which element is the LCP element. It is often not the one you assumed.
- Write down the four numbers. Compare each to the table above.
- Fix the largest overage, then measure again.
Lab tests like this are a diagnosis. The score that counts comes from real visits, which you can see in Search Console's Core Web Vitals report once enough traffic has been collected.
Fix a slow server response (TTFB)
A high TTFB can make a 2.5 second LCP almost impossible, because the clock is spent before a single byte of your page arrives. The guide's advice is to reduce server-side redirects and to avoid cache-busting query parameters that stop a CDN from caching the page. A redirect chain adds a full round trip each hop, so see how to fix redirect chains.
Fix a late start on the image (resource load delay)
The browser cannot download what it has not found. If the LCP image is only referenced from CSS or inserted by JavaScript, the browser discovers it late. Two fixes from the guide:
- Put the image in the initial HTML as a normal
imgelement so it is discoverable immediately. - If it must be referenced from a stylesheet or script, add a preload hint with
fetchpriority="high".
Also check for the most common self-inflicted wound: loading="lazy" on the hero image. The guide says plainly to never lazy-load the LCP image, because it delays the load.
Fix a long download (resource load duration)
Here the image is found early but takes too long to arrive. Serve it at the size it is displayed, in a modern format, and from a cache close to the visitor. Set fetchpriority="high" on the one image most likely to be the LCP element. The guide warns that using it on more than one or two images weakens the effect, since high priority only means something when it is rare.
Fix a late paint (element render delay)
If the file is already downloaded but the element still does not appear, something is blocking the render. Usually that is a large stylesheet or script in the head, or a client-side framework that has to run before it can draw the image. Reduce what blocks the first paint, or render the hero in the server HTML.
How do you know it worked?
Re-record the same page and compare the four numbers to your starting numbers. Then wait for field data. Search Console aggregates real visits over a rolling window, so a fix can take weeks to show fully. If you ship a change and the lab number improves but the field number does not, the slow visitors are on different devices or networks than your test.
LCP is one input to page experience, not a replacement for good content. A fast page that does not answer the query will not rank for it. If you also want the page to be read by AI answers, speed helps, but access and clarity matter more; see how to optimize for AI search.
Frequently Asked Questions
What is a good LCP score?
2.5 seconds or less for at least 75% of visits. Over 4.0 seconds is rated poor.
What is the most common cause of a bad LCP?
A slow server response or a hero image that the browser finds late. Measure the four subparts to see which one applies to you, since the fix differs.
Should I lazy-load images to speed up my page?
Lazy-load images below the fold, but never the LCP image. Lazy loading the hero delays it and makes LCP worse.
Does LCP affect rankings?
It is part of Google's Core Web Vitals, which feed into page experience. It is a modest signal, so fix it for visitors first and rankings second.
Why does my lab score differ from Search Console?
A lab test is one load on one device and network. Search Console reports real visits across many devices, so slower phones and connections pull the field number up.