How to Improve Largest Contentful Paint (LCP) on Any Website

Short answer: To improve Largest Contentful Paint, first identify the LCP element (usually a hero image or a large heading), then find which part of its loading is slow: server response, resource discovery, download or rendering. The most common fixes are faster server response with caching, a compressed WebP or AVIF hero image that is not lazy-loaded and has high fetch priority, and less render-blocking CSS and JavaScript.

Largest Contentful Paint is the Core Web Vital that most often fails on small-business websites, and it is also the one that visitors notice most. When LCP is slow, people stare at an empty or half-built page. The good news is that LCP has a small number of well-understood causes, and you can work through them methodically instead of trying random optimisation plugins.

What LCP measures and what “good” means

LCP is the time from when the user starts loading the page until the largest image or text block visible in the viewport has been rendered. Google considers LCP good when it is 2.5 seconds or less for at least 75% of page visits, measured separately for mobile and desktop. Between 2.5 and 4 seconds needs improvement, and more than 4 seconds is poor.

The LCP element can be:

• an <img> element, including the first frame of an animated image;
• an image inside an SVG, or a video poster image;
• an element with a background image loaded through CSS;
• a block of text, such as a large heading or a paragraph.

On phones, the LCP element is often different from desktop, because the layout changes. A hero image that dominates the desktop view may be pushed down on mobile, and a heading becomes the LCP element instead.

Step 1: Find your LCP element

You cannot fix LCP until you know what the browser considers the largest element. There are three easy ways to find it:

1. PageSpeed Insights. In the diagnostics, the “Largest Contentful Paint element” audit names the element and shows a snippet of its HTML.
2. Chrome DevTools. Open the Performance panel, record a page load, and look for the LCP marker. Hovering over it highlights the element on the page.
3. Test on mobile and desktop separately. Note both elements, because the fix may be different for each.

Step 2: Break LCP into its four parts

An LCP time on its own does not tell you what to fix. Google’s guidance splits it into four sub-parts, and the slowest one is where you should start:

If the LCP element is text, there is no resource to download, so you only deal with server response and render delay. PageSpeed Insights shows this breakdown in the LCP diagnostic, which saves you from guessing.

Step 3: Speed up server response

Nothing can appear until the HTML arrives. If Time to First Byte takes a large share of your LCP, work on the server first:

• Enable full-page caching so the HTML is served ready-made instead of being built by PHP and the database for each visit.
• Remove redirect chains. Every redirect, for example from http to https to www, costs a round trip before the page even starts loading.
• Use a CDN or a server close to your audience if your visitors are far away from the hosting location.
• Upgrade PHP and fix slow database queries if uncached pages, such as a shop cart, are slow.

Step 4: Make the LCP image discoverable early

A surprisingly common problem is that the image itself is fast, but the browser finds out about it late. The browser’s preload scanner only sees images that are in the initial HTML. Anything added by JavaScript or hidden in a CSS file has to wait.

• Use a normal <img> tag for the hero, not a CSS background image, where possible.
• Never lazy-load the LCP image. Remove loading="lazy" from it. Many themes and plugins lazy-load every image by default, including the first one.
• Add fetchpriority="high" to the LCP image so the browser downloads it before less important resources.
• Preload it if it must stay in CSS. A <link rel="preload" as="image"> in the head tells the browser about it right away.
• Avoid sliders for the hero. Carousels often wait for JavaScript to decide which slide to show, which delays LCP considerably.

Step 5: Make the LCP resource smaller

Once the browser starts downloading the image, the size of the file decides how long it takes, especially on mobile networks.

• Resize to the displayed size. A phone does not need a 4,000-pixel-wide photo. Use srcset and sizes so each device gets an appropriate version.
• Use WebP or AVIF. Both are supported by all current major browsers and are typically much smaller than JPEG or PNG at similar visual quality.
• Tune compression. A quality setting in the range of 70 to 85 is usually indistinguishable from the original for photographs.
• Serve from a nearby location. A CDN reduces the distance the bytes have to travel.
• Reconsider video heroes. A background video is heavy; if you keep it, make sure the poster image is optimised, because it is often the LCP element.

Step 6: Reduce render delay

Sometimes the image arrives in time, but the browser still cannot paint it because it is waiting for stylesheets or scripts. This is render delay.

• Defer non-critical JavaScript with defer or load it after the page has rendered.
• Trim CSS. Large theme and page-builder stylesheets block rendering. Removing unused CSS or inlining the small amount needed for the top of the page helps.
• Check for client-side rendering. If the page is built by JavaScript in the browser, the content cannot appear until that script runs. Server-side rendering or pre-rendering fixes this.
• Watch for A/B testing and personalisation scripts that hide the page until they finish. They can add a lot of render delay.
• Use font-display for text LCP. If a heading is the LCP element, a web font that blocks text rendering delays it. font-display: swap or optional lets text appear right away.

Common LCP mistakes to avoid

• Lazy-loading every image, including the one at the top.
• Optimising images below the fold while the hero stays at several megabytes.
• Judging LCP only on a fast office connection and desktop computer.
• Adding a preload for the wrong image, which competes with the real LCP resource.
• Stacking several optimisation plugins that each rewrite image tags in different ways.

How to confirm that your fix worked

After each change, run the same test again under the same conditions: the same page, mobile mode, and ideally several runs so you can compare a typical result rather than one lucky number. Check that the LCP element is still the one you expect, because a change in layout can make a different element the largest one. Look at the breakdown again to see whether the sub-part you worked on actually shrank. Finally, remember that real-user data in PageSpeed Insights and Search Console covers the last 28 days, so it will improve gradually. If the lab result is better but the field data does not move after a month, look for pages or templates you have not fixed yet, or for visitors on much slower devices than your test assumes.

How Site AI Audit helps

Site AI Audit runs Google PageSpeed for mobile during every check and reports LCP together with server response time, compression and page weight. When LCP is slow, the finding explains why it matters and what to change first, for example compressing the hero image or loading it earlier, alongside the rest of your SEO, security and e-mail findings. You can start with a free check of your website.

Related reading

• Core Web Vitals Explained for Small Business Websites
• How to Fix a Slow WordPress Site: A Step-by-Step Guide

The bottom line

Improving LCP is a process, not a trick. Find the LCP element, see which of the four sub-parts takes the most time, and fix that part: server response, early discovery, file size or render delay. On most small-business sites, the biggest wins are page caching and a properly compressed, eagerly loaded hero image.

FAQ

What is a good LCP score?

Google considers LCP good at 2.5 seconds or less, measured at the 75th percentile of real visits. Between 2.5 and 4 seconds needs improvement, and above 4 seconds is poor. Check mobile and desktop separately, because they are assessed separately.

Why is my LCP slow when my images are optimised?

The delay may be somewhere else: slow server response, a late-discovered image, or render-blocking CSS and scripts. Look at the LCP breakdown in PageSpeed Insights to see which sub-part is largest. Also check that the hero image is not lazy-loaded.

Should I preload my hero image?

Preloading helps when the browser cannot see the image in the initial HTML, for example when it is a CSS background. If the image is already a normal img tag near the top of the HTML, adding fetchpriority=”high” is usually enough. Preloading the wrong file can slow down the real LCP resource.

Can text be the LCP element?

Yes. On many mobile pages and text-heavy pages, a large heading or paragraph is the LCP element. In that case server response time, render-blocking resources and web font loading are the main things to optimise.

Does lazy loading improve LCP?

Lazy loading helps images further down the page, but it hurts LCP if applied to the main image. The browser waits until layout is known before loading lazy images. Make sure the first large image loads eagerly.