Skip to content
Website Performance 2 min read Sajid Aslam

How to Improve Largest Contentful Paint (LCP)

Identify the element being measured first. Almost everything else is guesswork until you have.

Steps to reduce Largest Contentful Paint on a web page

Short answer

Find which element is the LCP element using PageSpeed Insights or Chrome DevTools, then fix that specific element: size and format the image properly, do not lazy-load it, preload it, and remove anything render-blocking ahead of it.

LCP work goes wrong when people optimise the page in general instead of the element being measured.

Step 1: find the LCP element

PageSpeed Insights names it under the LCP diagnostic. Chrome DevTools shows it in the Performance panel.

It is usually one of: a hero image, a background image on a hero section, a large heading, or a video poster frame.

Until you know which, you are guessing.

Step 2: fix that element

If it is an image

  • Do not lazy-load it. This is the most common single cause of a bad LCP, and it is usually applied automatically by a plugin or by loading="lazy" set globally. The largest visible element is exactly the thing you want loaded eagerly.
  • Size it correctly. A 3000px image rendering at 800px is 14 times more data than needed.
  • Modern format. AVIF or WebP with a fallback.
  • Preload it, so the browser starts fetching before it has finished parsing CSS.
  • Set width and height so no layout shift occurs when it arrives.

If it is text

Text renders fast; the delay is whatever is blocking it.

  • Font loading. A web font that blocks render delays the text. Use font-display: swap, preload the critical font, and cut the number of families and weights.
  • Render-blocking CSS. Large stylesheets parsed before anything paints.

Step 3: reduce what happens before it

The browser cannot paint until it has the CSS. So:

  • Inline critical CSS for above-the-fold content, defer the rest
  • Defer JavaScript that is not needed for first render
  • Remove render-blocking third-party scripts from the head — chat widgets and analytics do not need to block your hero

Step 4: server response

If Time to First Byte is already high, everything downstream inherits the delay. Above roughly 600ms, fix the server before optimising the front end:

  • Page caching, so a pre-built file is served instead of running PHP
  • A CDN for static assets
  • Hosting appropriate to the site's size

What not to bother with

  • Minifying CSS and JavaScript for LCP specifically. Small gains, and aggressive minification breaks things regularly.
  • Removing jQuery. Rarely the bottleneck and rarely possible without breaking something.
  • Chasing the last few points of a lab score. Field data is what counts.

Verify

Re-measure in the same conditions, then check Search Console field data after four weeks. That is a 28-day rolling window, so it will not move immediately no matter how good the fix was.

Core Web Vitals explained covers why that distinction matters, and the speed optimisation checklist is the condensed working version.

Worked examples

Related services

Related reading