How to Fix Largest Contentful Paint (LCP) on Your Website

When someone opens your website, the moment that matters most is when the main content appears. Google measures that moment as Largest Contentful Paint (LCP). This guide is for small business owners and the person who looks after their site. You will learn how to find your LCP number, work out what is slowing it down, and fix the most common causes in a sensible order.

In short: LCP is the time until the largest content item in the visible part of a page has appeared. Google rates 2.5 seconds or less as good. Measure first, find which of four phases is slowest, then fix that one. Compressing every image on the site without measuring is often wasted effort.

What LCP measures

LCP is the time from the start of a page visit until the largest item in the visible area has rendered. According to Google's guidance, the candidates are images (including SVG images), video elements, elements with a CSS background image, and blocks of text. The browser picks the element automatically, and it may not be the one you consider most important.

Google's LCP ratings: 2.5 seconds or less is Good, over 2.5 up to 4.0 seconds Needs improvement, over 4.0 seconds Poor. Judged at the 75th percentile of real visits.

Google's published thresholds:

LCP time	Rating
2.5 seconds or less	Good
Over 2.5 up to 4.0 seconds	Needs improvement
Over 4.0 seconds	Poor

These are judged at the 75th percentile of real visits, separately for mobile and desktop. In plain terms, three in four real visitors on each device type should see the main content within 2.5 seconds.

LCP is one of the three Core Web Vitals, alongside Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). Google's LCP explainer covers the definition in more depth.

Step 1: find your real LCP number

Paste a page address into PageSpeed Insights. The report has two kinds of data:

Field data comes from real Chrome users. This is what Google assesses. If a page has too little traffic, the report may show data for your whole site instead.
Lab data is a one-off simulated test. It is useful for before-and-after comparisons, but it is not what your visitors experienced.

Chrome DevTools can also show you the LCP element, for example in the Performance panel or a Lighthouse report. Test your main service, product and landing pages, not just the homepage, on both mobile and desktop. The LCP element can differ between them.

Tip: Write down the LCP element for each key page before changing anything. If it is a block of text, compressing images will do nothing.

Step 2: find the slow phase

Every LCP time is made of four parts, described in Google's LCP optimisation guide:

Every LCP time has four parts: Time to First Byte, resource load delay, resource load duration and element render delay. Find the biggest phase and start there.

Time to First Byte (TTFB): how long the server takes to start sending the page.
Resource load delay: how long before the browser starts fetching the LCP image or font.
Resource load duration: how long the download itself takes.
Element render delay: the gap between the file arriving and it appearing on screen.

A slow first byte leaves very little time for the other phases, so compression alone rarely gets you under 2.5 seconds. Find the biggest phase and start there.

Symptom	Likely cause	Go to
Slow first byte	Hosting, no caching, redirects	Server
Long delay before image starts	Lazy loading, late discovery	Lazy loading, preload
Long download	Oversized image file	Right-size
Long render delay	Blocking CSS/JS, fonts, sliders	Blocking files, fonts

A hypothetical example. Imagine a report where the first byte and the download are short, but the delay before the image starts loading is the largest part. Shrinking the file would barely help. The better fix is to check whether the image is lazy-loaded or only discovered late, as described below. If instead the download were the largest part, right-sizing the image would be the first job.

Watch out: Take a backup before any change, and use a staging copy if your host offers one. Change one thing at a time, retest, and check that forms, checkout, cookie consent and analytics still work.

Fix: right-size the LCP image

Open the LCP image in DevTools and compare its file dimensions with the size it is shown at. A typical problem is a 3000-pixel photo displayed at 800 pixels, or a PNG used for a photograph.

Export at roughly the displayed size, allowing about twice the width for sharp 2x screens.
Save photographs as JPEG, WebP or AVIF where your tools support them, and compress them.
Use srcset and sizes so phones download smaller versions. Many CMS platforms generate these, so inspect the <img> tag before adding anything by hand.
Add width and height attributes so the browser reserves space, which also helps CLS.

There is no universal target file size. Test on a throttled mobile connection and keep trimming until download time stops being the biggest phase. Our image optimisation guide goes deeper on formats and tools.

Fix: stop lazy-loading the LCP image

Lazy loading suits images further down the page. For the main image at the top, it tells the browser to wait, which adds delay.

Before: loading="lazy" on the hero image slows LCP. Better: remove it and add fetchpriority="high" with width and height so the browser treats it as a priority.

<!-- Slows your LCP image -->
<img src="/hero.jpg" loading="lazy" alt="Our workshop">

<!-- Better -->
<img src="/hero.jpg" fetchpriority="high" width="1200" height="600" alt="Our workshop">

Remove loading="lazy" from the LCP image and add fetchpriority="high" to ask the browser to treat it as a priority. Many themes and image plugins lazy-load everything by default, so look in their settings for an option to skip the first or featured image.

Fix: preload only when the image is found late

If the LCP image is a CSS background, or is added by a script, the browser discovers it late. A preload hint in the page <head> lets it start sooner:

<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">

Preload only the one image that is truly the LCP. With responsive images, make sure the preloaded file is the one the browser would pick anyway, or it may download twice. Often the simpler fix is to put the image in a normal <img> tag so the browser finds it in the HTML without help.

Fix: trim render-blocking files

Stylesheets in the page head block rendering until they load, and classic scripts without async or defer stop the browser reading the rest of the page. Both can push LCP later.

Remove plugins and widgets you no longer use. Many add their own CSS and JavaScript to every page.
Add defer to non-essential scripts, testing for order problems. Take care not to break consent banners or analytics.
Question third-party embeds such as chat widgets, social feeds and extra marketing tags.

PageSpeed Insights lists render-blocking resources as diagnostics. Treat them as leads to investigate, not proof.

Fix: speed up the server response

A slow first byte uses up your LCP time before anything can be drawn. Check:

Checklist for a slow first byte: caching, heavy back-end work, redirect chains and distance (a CDN can help). Never cache accounts, baskets or checkout as public content.

Caching: is full-page caching on, and are anonymous visitors actually served cached pages?
Heavy back-end work: slow database queries, bloated plugins or external calls on every page load.
Redirect chains: each extra hop adds delay, for example http to https to www to a final address.
Distance: a server far from your customers adds travel time. A content delivery network (CDN) can reduce this for images and files.

Watch out: Never cache personalised pages such as accounts, baskets or checkout as public content. Follow your platform's documented exclusions.

On a hosted website builder, ask the provider's support what caching is already included before adding anything of your own.

Fix: web fonts and sliders

Fonts. If the LCP element is text, the browser may hold it back until a custom font arrives. Add font-display: swap so a fallback font shows immediately:

@font-face {
  font-family: "YourFont";
  src: url("/fonts/yourfont.woff2") format("woff2");
  font-display: swap;
}

If you load fonts from a provider, check its settings for a font-display option. The trade-off is that text can shift slightly when the real font loads, so check CLS afterwards.

Sliders. A rotating hero slider often hides the LCP image behind JavaScript, so nothing is drawn until the script has loaded. A single static hero image can be faster. If you keep a slider, make sure the first slide's image is in the plain HTML and visible without JavaScript.

Re-measure properly

After each change, rerun the lab test on the same page under the same conditions, a few times, because single results vary. Field data is reported over a rolling 28-day period, so improvements appear gradually as older visits drop out.

To see how a page looks from an SEO angle alongside speed, the free single-page scan at seo.lordevo.com is one option. To make sense of any report, see how to read an SEO audit.

Key takeaways

Measure with PageSpeed Insights first and note the LCP element on each important page.
Fix the slowest of the four phases, not the easiest one.
Right-size and compress the LCP image, and never lazy-load it.
Check caching and redirects before blaming the image.
Change one thing at a time and retest.

FAQ

Is 2.5 seconds the target for every page?

It is Google's "good" threshold, assessed at the 75th percentile of real visits. Aim for it on your important pages, on mobile and desktop.

Why does my score differ between tests?

Lab tests vary with server load, network and device, while field data reflects real visitors over time. Compare like with like and run several tests.

Will fixing LCP improve my rankings?

Google says good Core Web Vitals align with what its ranking systems seek to reward, but they are one factor among many and no outcome is certain. See Google's Core Web Vitals documentation. A faster page is still better for visitors.

Do I need a developer?

Not always. Image sizing, lazy-loading settings, plugin clean-up and caching can often be done through your CMS or host. Script, CSS and server changes usually benefit from someone experienced.