How to Improve Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) is one of Google's Core Web Vitals, measuring how long the main content of a page takes to appear. A good LCP is under 2.5 seconds. Most sites that fail LCP do so because of one of four causes. Identify yours and the fix is usually straightforward.

What is LCP and why does it matter?

LCP records the render time of the largest element visible in the viewport — typically a hero image, a large heading or a video poster. It is the user's perception of speed: not "did the page load eventually?" but "did the page look ready?"

Google uses LCP as a ranking signal, but more importantly, users treat a slow LCP as a quality signal. Studies show roughly 47 percent of users expect a page to load in under two seconds, and slow pages lose visitors before they have seen anything. A slow LCP means higher bounce rates, fewer enquiries and poorer conversion rates. If you want to understand how LCP sits alongside the other vitals, read our Core Web Vitals explained guide.

Fix 1: Optimise images

Images are the most common LCP element and the most common cause of a poor score. The fix involves three steps.

Convert to modern formats. JPEG and PNG are bulkier than necessary. WebP typically reduces file size by 25 to 35 percent with no visible quality loss. AVIF goes further, though browser support is still growing. If your CMS supports automatic conversion, turn it on. If not, batch convert your images before uploading.

Serve the right size. A 2400-pixel-wide image displayed at 600 pixels wastes bandwidth. Use srcset to serve different image sizes at different viewport widths. The browser picks the appropriate size, and the page loads faster as a result.

Lazy-load below-the-fold images. Images that are not visible on initial page load do not need to load before LCP. Add loading="lazy" to every image that appears below the viewport. The LCP element itself must not be lazy-loaded — it should load with priority.

If you are on a shared hosting plan at BD 3.5 a month and your hero image is a multi-megabyte JPEG, upgrading image delivery will produce the biggest single improvement to your page speed.

Fix 2: Reduce server response time

Time to First Byte (TTFB) measures how long the browser waits before receiving the first byte of data from your server. If your server takes more than 800 milliseconds to respond, your LCP is already behind before a single byte of content arrives.

Check your TTFB. Use PageSpeed Insights or WebPageTest. If TTFB is high, the problem is either hosting, application code or a missing cache layer.

Upgrade hosting if needed. Shared hosting pools resources across accounts. A neighbour's traffic spike can slow your response time. Moving to private shared hosting at BD 8.5 a month guarantees dedicated CPU and RAM, which stabilises response times.

Implement caching. A caching plugin or CDN can serve cached pages in milliseconds rather than seconds. For WordPress, caching plugins like WP Rocket or W3 Total Cache make a significant difference.

For a broader look at what slows your entire site down, see our why is my website slow diagnostic guide.

Fix 3: Eliminate render-blocking resources

Render-blocking resources are CSS and JavaScript files that the browser must download and process before it can paint anything on the screen. Every render-blocking file adds to the time before LCP registers.

Identify blockers. PageSpeed Insights lists every render-blocking resource by URL and shows how much time it adds. Typically the worst offenders are large CSS files and JavaScript libraries loaded in the head.

Inline critical CSS. Extract the CSS needed for above-the-fold content and inline it in the page head. Defer the remaining CSS to load after the initial paint. This alone can cut LCP by several hundred milliseconds.

Defer non-critical JavaScript. Add the defer or async attribute to JavaScript files that are not needed for the initial render. Defer ensures the script loads after the HTML is parsed, so the page can paint without waiting for the script.

Fix 4: Optimise client-side rendering

If your site is built with a JavaScript framework like React, Vue or Angular, the browser has to download, parse and execute the JavaScript before it can render the page. This delays LCP because the largest element does not exist in the initial HTML.

Use server-side rendering (SSR) for the initial page load. SSR sends fully rendered HTML from the server, so the LCP element is immediately available. Next.js and Nuxt.js make this relatively straightforward.

Move critical content to static HTML. If you cannot implement SSR, structure your page so the hero section is static HTML that does not depend on JavaScript. The JavaScript-driven content can hydrate after the initial paint.

These fixes require development work, but the improvement to LCP is often dramatic — from failing to passing on a single deployment. Our website speed optimisation service covers all four causes in a structured audit.

Measuring and monitoring LCP over time

Fixing LCP is not a one-time task. Sites change: new images are added, plugins are updated, third-party scripts are introduced and content is expanded. Each change can affect LCP, and without monitoring, a regression can go unnoticed for weeks.

Set up Real User Monitoring (RUM). PageSpeed Insights and Search Console provide field data based on real user visits. Check the Core Web Vitals report in Search Console monthly to see whether your LCP scores are stable, improving or declining. The report segments by URL, so you can identify which pages need attention.

Use lab testing for pre-deployment checks. Before publishing a new page or making significant changes, run the URL through PageSpeed Insights or Lighthouse. Lab data is not a perfect proxy for real user experience, but it catches regressions before they reach visitors. Make this a standard step in your publishing workflow.

Set a performance budget. A performance budget caps the maximum page weight, number of requests or LCP time you allow. If a change pushes the page over the budget, the change is either optimised or not deployed. Performance budgets are the most reliable way to prevent LCP from regressing over time. Our page weight budget tool helps you calculate your starting budget from your current metrics.

Common LCP mistakes and how to avoid them

Even with the best intentions, certain mistakes keep LCP scores high. Here are three of the most common.

Mistake one: lazy-loading the hero image. The LCP element must not have loading="lazy". Adding lazy loading to the largest above-the-fold image tells the browser to deprioritise it, which directly delays LCP. Only images below the viewport should be lazy-loaded.

Mistake two: using a carousel or slider as the hero. A carousel loads multiple images, and the browser must determine which is the largest. This delays LCP because the render is blocked until the carousel script executes. A single, static hero image loads faster and scores better.

Mistake three: ignoring mobile LCP. The LCP element on mobile is often different from desktop — a heading or a text block instead of an image. Optimising only the desktop experience misses the mobile issue entirely. Always test on both viewport sizes.

Understanding how LCP interacts with the other Core Web Vitals — particularly CLS, which measures layout stability — gives you a complete picture of your page performance. Our Core Web Vitals guide connects all three metrics so you can prioritise the fixes that make the biggest difference to your users. For server-level improvements that affect every page, consider our speed optimisation service.

LCP improvement is one of the highest-ROI technical investments a business website can make. A one-second improvement in load time can increase conversion rates by up to 20 percent for some industries, and unlike most marketing investments, the benefit persists as long as the site remains optimised. Start with your most visited pages, measure before and after, and expand the fixes across your entire site from there.