How to Improve Largest Contentful Paint (LCP)
Identify the element being measured first. Almost everything else is guesswork until you have.

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
Website Performance
Core Web Vitals Explained for Business Website Owners
Three metrics, in plain English — what each one measures, what breaks it, and which number Google actually uses.
Website Performance
How Images Affect Website Speed and SEO
Usually the largest thing on the page and the last thing anyone checks. Sizing, formats, and the lazy-loading trap.
Website Performance
Website Speed Optimisation Checklist
Ordered by impact rather than alphabetically, so you fix the thing that matters before the thing that does not.
Website Performance
How to Reduce Server Response Time (TTFB)
Everything else on the page waits for the first byte. How to find out why yours is slow, and what actually brings it down.
