Improving LCP: making the main content appear faster

A failing Largest Contentful Paint score rarely has a mysterious cause. On most business websites, one element decides it: a big banner photo, a product image or a heading block at the top of the page. If you want to improve LCP, the job is to find that element, understand exactly what holds it back, and remove those delays one by one. This guide covers that process without drifting into general speed advice.

Google’s "good" threshold for LCP is 2.5 seconds or less, measured at the 75th percentile of real page loads. Anything above 4 seconds is rated poor.

Step one: identify the LCP element on each template

You cannot fix what you have not identified, and the LCP element is not always what people assume. On mobile it may be a paragraph of text rather than the image, because the image is cropped smaller.

• PageSpeed Insights: in the lab section, open the "Largest Contentful Paint element" diagnostic. It names the element and shows a snippet of its HTML.
• Chrome DevTools Performance panel: record a page load and look for the LCP marker in the timings track; clicking it highlights the element.
• Per template, not per page: check the home page, a service or category page, a product page and a blog post. Pages built on the same template usually share the same LCP element.

Write down the element for each template. Your fixes will be applied at template level.

The four parts of LCP time

Google’s web.dev guidance breaks LCP into four sub-parts. Thinking in these terms stops you guessing.

1. Time to First Byte: waiting for the server to start sending HTML.
2. Resource load delay: the gap between TTFB and the moment the browser starts downloading the LCP image.
3. Resource load duration: how long the image itself takes to download.
4. Element render delay: time between the image finishing and it actually being painted on screen.

If the element is text, only the first and last parts apply. For images, a common pattern is a surprisingly large load delay, meaning the browser found the image late.

Cutting server response time

Every millisecond of TTFB is added directly to LCP. A page that takes 1.5 seconds before the first byte leaves only one second for everything else.

• Enable full-page caching for pages that are the same for every visitor, such as the home page and service pages.
• Check for slow database queries or plugins running on each request.
• Choose hosting with a data centre reasonably close to your audience; for Indian visitors, servers in India or nearby regions usually respond faster than distant ones.
• Consider a CDN that can serve cached HTML from an edge location.

Helping the browser discover the hero image early

Resource load delay is where many sites lose the most time. The browser can only fetch an image once it knows the image exists.

Put the image in the HTML

If the banner is a CSS background, the browser has to download and parse the stylesheet first. If a JavaScript slider inserts it, the script has to download and run first. A plain img element in the initial HTML is discovered immediately by the browser’s preload scanner.

Preload when the image cannot be in the HTML

When a background image is unavoidable, a link element with rel="preload" and as="image" in the document head tells the browser to fetch it straight away. Preload only the one LCP image; preloading many files competes for the same bandwidth. For responsive images, the preload can carry imagesrcset and imagesizes attributes to match the right size.

Raise its priority

Adding fetchpriority="high" to the hero image asks the browser to download it ahead of other images. Supporting browsers honour it; others simply ignore the attribute, so it is safe to add.

Never lazy-load the LCP image

Lazy loading is excellent for images further down the page, but applying it to the hero is one of the most common causes of poor LCP. With loading="lazy", the browser waits until it has worked out the layout and confirmed the image is in the viewport before starting the download.

Many themes and plugins lazy-load every image automatically. Check the HTML of your LCP element; if it has loading="lazy" or a data-src attribute swapped in by a script, exclude that image from lazy loading. Most WordPress optimisation plugins have a setting to skip the first one or two images.

Making the image itself smaller

Once the download starts on time, reduce how long it takes.

• Serve the image at the size it is displayed, using srcset so phones do not download a 2,400-pixel desktop banner.
• Use a modern format such as WebP or AVIF where supported.
• Compress at a sensible quality level; hero photos rarely need maximum quality.
• Host the image on your own domain or CDN, avoiding an extra connection to a third-party image host.

Removing render-blocking resources

Element render delay usually comes from CSS and JavaScript that must be processed before the browser paints. The image may be downloaded and still invisible.

• Stylesheets in the head block rendering until downloaded. Remove unused CSS files, and consider inlining the small amount of CSS needed for the top of the page.
• Synchronous scripts in the head pause parsing. Add defer to scripts that do not need to run before the page shows.
• Sliders and animation libraries sometimes hide the first slide until their script initialises. Show the first slide with plain HTML and CSS instead.
• Web fonts: if the LCP element is a heading, use font-display: swap so text appears in a fallback font rather than staying invisible.

A working order for fixing a slow LCP

Take one template at a time. Confirm the LCP element, check which of the four sub-parts is largest in the DevTools Performance panel, and fix that part first. Then re-test in the lab, deploy, and watch field data in Search Console over the following weeks.

Hero sections are often where design and speed collide, especially on campaign pages. If you are planning a new one, our landing page development work keeps the above-the-fold area light from the start.

Frequently asked questions

Is a hero slider bad for LCP?

Not necessarily, but many sliders delay the first slide until JavaScript runs and load every slide image upfront. If you keep a slider, render the first slide in plain HTML and lazy-load the rest.

Can text be the LCP element?

Yes. Headings or large paragraphs often are, especially on mobile. In that case, focus on server response time, render-blocking CSS and web font loading.

Does preloading every image make the page faster?

No. Preloading too many files makes them compete with each other and with critical CSS. Reserve preload for the single image that is the LCP element.

Why is my LCP good on desktop but poor on mobile?

Phones have slower processors and networks, and the LCP element may differ by screen size. Check the mobile LCP element separately and make sure mobile visitors receive an appropriately sized image.