How to fix a slow LCP score: a step-by-step guide for business websites

You open Search Console and see it: LCP issue: longer than 2.5 s (mobile). The site looks fine on your office Wi-Fi. So what’s slow?

LCP, Largest Contentful Paint, measures when the biggest thing in the first screen finishes showing. That is usually the hero image, a large banner, or the main headline. Visitors judge a page by when that appears, which is why it’s one of the three Core Web Vitals.

The good news: LCP problems are usually easier to find than INP problems, because a normal Lighthouse or PageSpeed Insights test can measure LCP. This guide walks through finding the cause and fixing it, and says which fixes need a developer.

The thresholds

LCP at the 75th percentile	Rating
2.5 s or less	Good
2.5–4 s	Needs improvement
Over 4 s	Poor

The “75th percentile” means three out of four real visits must be at or under the number. Your own fast laptop doesn’t count; your visitors’ phones do. We set a stricter 2-second budget on our own builds, so there’s room for a slow network day.

The four parts of LCP

Every LCP time is the sum of four parts. The fix depends entirely on which part is long:

1. Server response (TTFB). How long the server takes to send the first byte of HTML. Slow hosting, no caching or a heavy CMS make this long.
2. Load delay. The gap between the HTML arriving and the browser starting to download the hero image. This is long when the browser can’t see the image early: it’s lazy-loaded, set as a CSS background, or added later by JavaScript.
3. Download time. How long the image itself takes to download. A 2 MB JPEG straight from the camera makes this long.
4. Render delay. The gap between the image finishing and it actually appearing on screen. Render-blocking CSS and scripts, web fonts, or an animation that keeps the hero invisible at first make this long.

In a healthy page, almost all of the time goes on server response and download, and the two delays are close to zero. On most slow business sites we look at, load delay is the biggest part. The browser simply finds out about the hero image too late.

Step 1: find the pages that fail

Open Google Search Console → Core Web Vitals → Mobile and click the LCP issue. Google groups similar URLs, for example all service pages or all blog posts, and shows LCP for each group. It’s usually one template that fails, not the whole site: the homepage with a slider, or every page with a full-width banner.

No Search Console data yet? Test the URL in PageSpeed Insights. The top section shows real-user data when Google has enough of it; the lower section is a lab test you can use straight away.

Step 2: find the LCP element and the slow part

In PageSpeed Insights, scroll to the diagnostics and look for the LCP element. It names the exact image or text block, and it splits the time into the four parts above.

For more detail, open the page in Chrome:

1. Open DevTools → Performance.
2. Set network throttling to a mobile speed and CPU throttling to 4× slowdown.
3. Click Record and reload.
4. Find the LCP marker. The Insights sidebar shows the LCP element and the breakdown by phase.

Write down two things: what the LCP element is, and which part is longest. Then go to the matching fix below.

Step 3: fix the slow part

If load delay is long: let the browser find the image early

This is the most common problem, and the fixes are cheap:

• Never lazy-load the LCP image. Many themes and plugins add loading="lazy" to every image, including the hero. Lazy loading tells the browser to wait, which is the opposite of what you want for the first screen. Lazy-load images further down, never the hero.
• Use a real img in the HTML, not a CSS background. The browser only finds a CSS background image after it has downloaded and read the stylesheet. A normal <img> tag in the HTML is found almost immediately.
• Add fetchpriority="high" to the hero image. It tells the browser this image matters more than the others.
• If the image must come from CSS or a script, add a <link rel="preload" as="image"> for it in the page head so the browser starts the download early.
• Drop the slider. Sliders usually build the hero with JavaScript after the page loads, so the browser can’t see the first image until the script runs. One strong static hero image loads faster.

If download time is long: make the image smaller

• Serve the right size. A phone doesn’t need a 2,400-pixel-wide image. Use srcset and sizes so each device downloads a version that fits its screen.
• Use a modern format. WebP and AVIF are usually much smaller than JPEG or PNG at the same visual quality.
• Compress properly. Export at a sensible quality, not maximum.
• Serve images from a CDN close to your visitors, so the file travels a shorter distance.

Most of this needs no developer on WordPress or Webflow: Webflow converts images to WebP for you, and WordPress has well-known image plugins. On a custom build, an image pipeline such as Astro’s built-in image component does all of it at build time.

If render delay is long: stop hiding the hero

• Check for animations on the hero. A fade-in that starts the headline or image at zero opacity delays LCP until the animation runs. Show the hero immediately; animate things further down.
• Cut render-blocking CSS and JavaScript. Large stylesheets and scripts in the page head stop the browser painting anything until they’ve loaded. Inline the small amount of CSS the first screen needs, and defer scripts that aren’t needed straight away.
• Handle web fonts. If the LCP element is a headline, the browser may wait for its font. Use font-display: swap or optional, preload the one font file the headline uses, and serve fonts from your own domain.
• Watch the cookie banner. A large banner or pop-up can itself become the LCP element, and if it’s injected late, it makes LCP late.

If server response is long: speed up the HTML

• Turn on page caching so the server sends a ready-made page instead of building it for every visitor.
• Use a CDN that caches the HTML near your visitors, not just images.
• Look at the hosting plan. Cheap shared hosting is often the bottleneck. Moving a small business site to better hosting is one of the few fixes that helps every page at once.
• Check redirects. A chain like http → https → www → /home/ adds a round trip for each step before anything loads.

On sites we build, pages are static HTML served from a global edge network, so server response is rarely the long part. If you’re comparing platforms, we wrote about this in Astro vs Webflow vs WordPress.

Platform notes

WordPress. Check whether your theme or an optimisation plugin lazy-loads the first image, and turn that off for the hero. Replace slider plugins with a static hero. Then look at hosting and page caching.

Webflow. Webflow’s hosting and CDN are fast, so the usual problems are a hero set as a background image, heavy Interactions that fade the hero in on page load, and large videos in the first screen. Swap the background for an image element and remove the load animation on the hero.

Shopify and other hosted platforms. Theme sections often lazy-load everything. Check the hero section’s settings, and remove apps that inject banners or pop-ups above the fold.

Custom builds. Render the hero on the server, not in client-side JavaScript. A page that ships an empty <div> and builds the hero after a framework bundle loads will always have a long load delay.

Step 4: confirm the fix

1. Re-run PageSpeed Insights and the DevTools recording. Check that the LCP element is the one you expect and that the long part has shrunk.
2. In Search Console, open the LCP issue and click Validate fix. Google monitors the affected pages for 28 days.
3. Watch the Core Web Vitals report. Field data is a 28-day rolling window, so improvements show up gradually.

If you’re working through all three vitals, our Core Web Vitals checklist is the full list we run before every launch.

When to get help

If the hero is a plain image, it isn’t lazy-loaded, it’s sized and compressed, and LCP is still slow, the problem is usually in the theme, the hosting or how the page is built. That’s developer work.

Our Core Web Vitals audit starts at ₹15,000. It measures your real-user data, finds the LCP element and the slow part on each template, and gives you a prioritised fix list your own developer can follow, or we can make the fixes. If the site needs rebuilding anyway, see our website redesign service. You can see sites we’ve built on our work page, and if you’d like us to look at yours, send us the URL.