Largest Contentful Paint (LCP) measures when the largest eligible visible image or text block renders during a page load. A good field LCP is 2.5 seconds or less at the 75th percentile. To fix a slow result, identify the actual LCP element, separate server response from resource discovery, download, and render delays, then change the part that is causing the wait. Verify with comparable lab runs and real-user data.
Before compressing another image, check which element is causing the slow LCP result.
It might be your hero image. It might be the heading above it. You can spend an afternoon reducing an image that the browser was not waiting for in the first place.
Largest Contentful Paint (LCP) measures when the largest eligible piece of visible content renders during a page load. To fix a slow result, find that element, check what holds it up, and test one change against the same conditions.
Start with the URL and device that have the problem. A fast desktop result does not explain a slow mobile page.
What is a good Largest Contentful Paint result?
Google's LCP guidance sets a good experience at 2.5 seconds or less, measured at the 75th percentile of page loads. Review mobile and desktop separately.
| Field LCP | Classification | Practical next step |
|---|---|---|
| 2.5 seconds or less | Good | Keep monitoring important page templates |
| More than 2.5 and up to 4 seconds | Needs improvement | Investigate the slow element and its loading path |
| More than 4 seconds | Poor | Prioritize the affected pages and reproduce the delay |
LCP is a duration, not the overall Lighthouse performance score out of 100. Keep both labels clear when sharing a report.
The LCP element can also change during loading or between viewport sizes. Do not assume the biggest image file is the element the browser reports.
Check whether you are reading field data or a lab test
PageSpeed Insights shows both. Real-user results come from the Chrome User Experience Report, or CrUX. Lighthouse runs a simulated visit to help diagnose the page.
Google's PageSpeed Insights documentation explains that field data covers the previous 28-day collection period. If the exact URL lacks enough samples, the tool may show origin-level results instead. Sometimes neither has enough data.
Record the device and whether the field result describes this URL or the whole origin. Keep the lab measurement in a separate row.
If field data is unavailable, continue with a clearly labelled lab investigation. A missing field result does not establish that the page is fast or slow.
For a before-and-after comparison, keep the runner, viewport, network settings, cache conditions, and consent state consistent. Our website performance comparison guide explains that testing process in more detail.
1. Find the actual LCP element
Open the affected page in Chrome DevTools, record a page load in the Performance panel, and inspect its LCP event. Check the associated element and resource when available. PageSpeed Insights diagnostics can also help identify the element and its loading path.
Write down the element, not just the headline number. For example: “The first product image is the LCP element on this mobile run.” That gives the developer something specific to inspect.
Then check the page at the same viewport. Is the image visible at startup? Does a carousel replace it? Does a heading remain hidden until the app finishes loading?
Keep the trace or report with the URL, device settings, and test time. After a change, confirm whether the same element still determines LCP. If another element becomes the largest candidate, inspect that result before declaring the work complete.
2. Find where the page spends its time
Google's LCP optimization guide breaks image-based LCP into four parts. Use the breakdown to choose the next investigation.
| Part of the wait | What it describes | Question to investigate |
|---|---|---|
| Time to first byte | Time before the first byte of the HTML response arrives | Is the document itself arriving late? |
| Resource load delay | Wait before the LCP resource starts loading after the HTML begins arriving | Could the browser discover the resource earlier? |
| Resource load duration | Time spent loading that resource | Is the delivered image larger or slower than it needs to be? |
| Element render delay | Wait between the resource finishing and the element rendering | What still prevents the content from appearing? |
For a text element without a separate image resource, do not force an image-download explanation onto the trace.
Use the evidence to narrow the task. If the document arrives late, investigate the server path before spending time on an image attribute. If the image finishes early but the page hides it, investigate the rendering work.
The HTML response arrives late
Check the document request before the image request. Compare an anonymous visit with the conditions under which the issue appeared.
Review redirects, cache behavior, application work, and the location serving the response. Test representative pages rather than assuming the homepage explains the whole site.
A useful issue names the slow request and the conditions: which URL, which region or runner, and whether the response came from cache. “Improve backend performance” leaves too much work undefined.
The image becomes discoverable late
Check the HTML the server delivers. If it contains only a placeholder and JavaScript assigns the real image source later, the browser has an extra dependency before it can request that image.
For a likely LCP image, make the source available early and consider a high fetch priority. Google's Fetch Priority guide explains that priority is a hint about relative importance. It does not replace resource discovery or guarantee a particular loading time.
Do not give every image high priority. Choose the resource the initial view needs and inspect the request order after the change.
The image takes too long to download
Check the image response that the browser actually requested. A small thumbnail in the CMS can still produce an oversized delivery URL in the template.
Compare the rendered dimensions with the delivered dimensions. Review responsive image selection, output format, and transfer size. Check the mobile request separately; do not assume it selected the desktop resource.
Keep the image useful. Reduce unnecessary bytes while preserving the detail someone needs to understand the page.
The resource finishes but content stays hidden
Check animations, loading states, and the work required before the page reveals its main content. Compare the completed network request with the point where the element appears in the trace.
If the LCP element is text, inspect font loading. Google's web font loading guide describes how font discovery and rendering behavior can delay visible text. Review the fonts the page uses and how it handles an unavailable font.
Choose a fix you can isolate. Changing the font, hero image, animation, and cache policy together makes it harder to explain which change helped.
3. Give the first important image a usable loading path
Consider a template that stores its hero URL in a custom attribute:
<img
data-src="/images/product-hero.webp"
width="1280"
height="720"
alt="Product dashboard showing the audit results"
>That markup alone does not give the image loader a normal source. A script must copy the value into src before the browser can use it as the image URL.
For an image you have confirmed is important to the initial view, a starting implementation could be:
<img
src="/images/product-hero.webp"
width="1280"
height="720"
loading="eager"
fetchpriority="high"
alt="Product dashboard showing the audit results"
>Keep the responsive sizing and image transformations your page needs. These snippets isolate discovery and priority; they are not a complete responsive image implementation or a measured before-and-after LCP test.
Google's image lazy-loading guidance recommends eager loading for images in the initial viewport, particularly the LCP image. Native lazy loading remains useful for suitable images farther down the page.
For a CSS background or another resource the browser discovers later, investigate whether a targeted preload helps. Check that it requests the resource the page will use. An unnecessary preload can spend bandwidth on the wrong asset.
A source check from two of our published articles
On 3 November 2026, we fetched the initial HTML for our Soft 404 guide and website performance comparison guide. We inspected their cover image markup before any browser rendering.
| Article cover | Image src in initial HTML | Explicit lazy loading | Explicit high fetch priority |
|---|---|---|---|
| Soft 404 guide | Yes | No | No |
| Website performance comparison | Yes | No | No |
Both cover URLs were available in the HTML response. Neither cover used loading="lazy", and neither had an explicit fetchpriority="high" attribute in the inspected markup. We also found no image preload in those responses.
That narrows the investigation. We would not start by accusing a client-side image loader of hiding these particular URLs from the initial HTML.
It does not establish which element becomes LCP. It also does not prove the covers need a preload or higher priority. Their position in the viewport and the browser's request behavior still matter.
Our next check would be a performance trace at the affected viewport, followed by one isolated change if the trace supports it. These are source observations, not measured loading improvements or real-user Core Web Vitals results.
4. Verify the change under the same conditions
Keep a short record that another person can repeat.
| Record | Before the change | After the change |
|---|---|---|
| URL and viewport | Exact page and dimensions | Same page and dimensions |
| Runner and conditions | Device, throttling, cache, and consent state | Same settings, with differences disclosed |
| LCP evidence | Value, element, and trace | New value, element, and trace |
| Change | Specific cause you are testing | Exact deployed change |
Repeat the comparison rather than choosing the fastest single run. Review the spread as well as the typical result. If the suspected resource starts earlier but LCP stays similar, inspect what now takes the time.
Check layout and interaction too. A faster image is not a useful fix if the page shifts beneath a button or makes the product details hard to read.
Review field LCP separately after deployment. A rolling collection window includes visits from before the release, so the field result will not describe only the new version on deployment day.
Does improving LCP guarantee better Google rankings?
No. Google recommends good Core Web Vitals as part of page experience, but a speed improvement does not guarantee a ranking or traffic increase. See Google's Core Web Vitals and Search guidance.
Keep the result precise: “The tested page's lab LCP improved under these conditions” is a different claim from “Organic traffic increased because of this change.” The second needs separate evidence.
For the wider technical review, use our technical SEO checklist. If JavaScript delivery is holding back the page's content, follow the JavaScript SEO audit.
Start with one affected page. Find its LCP element, identify the part of loading that needs work, and keep the evidence that lets you verify the fix.
Common questions
What is Largest Contentful Paint in simple terms?
Largest Contentful Paint measures when the largest eligible visible content element renders during a page load. It often involves a large image or text block. It does not measure when every resource on the page has finished loading.
What is a good LCP result?
A good field LCP is 2.5 seconds or less at the 75th percentile. Review mobile and desktop separately, and check whether the reported field data describes the exact page or the whole origin.
Should I lazy-load the LCP image?
Avoid lazy loading an image you have identified as the LCP element in the initial viewport. Make its source discoverable early. Keep lazy loading for appropriate images farther down the page, and verify the browser's actual requests.
Why is LCP slower on mobile than desktop?
The viewport, selected content, device capability, and network conditions can differ. The LCP element itself may change. Inspect a mobile result under consistent conditions before assuming that a desktop fix addresses the same delay.
Why does Search Console still show an LCP issue after a fix?
Field reports reflect collected visitor experiences rather than a single new lab run. A rolling reporting window can include visits from before the deployment. Check the report's dates, device, URL grouping, and data scope, then monitor the changed page over time.
Does fetchpriority high fix LCP by itself?
No. It is a resource priority hint. It cannot resolve a slow HTML response, an image source that becomes available late, or rendering work that keeps content hidden. Use it when the evidence supports a priority problem, then retest.
Keep the diagnosis moving
Run your own public presence audit
See how your website, search footprint, AI visibility, social proof, and conversion trust look from the outside.