Largest Contentful Paint, or LCP, measures how long it takes for the largest visible element on a page, usually a hero image or a big block of text, to finish rendering. A good LCP is 2.5 seconds or less. LCP is one of Google's three Core Web Vitals, alongside Cumulative Layout Shift and Interaction to Next Paint, so it feeds into rankings. It also decides first impressions: a page that shows its main content in one second feels instant, and one that takes five feels broken. This post covers what LCP measures, what slows it down, and exactly how to fix it.
The short version
- Good is 2.5 seconds or less, poor is above 4.0, measured at the 75th percentile of real visits.
- The LCP element is whatever renders largest in the viewport, most often the hero image.
- The two biggest levers are a lighter, preloaded hero image and a faster server response.
- Never lazy load the LCP element; that one mistake adds seconds on its own.
What counts as the LCP element
The browser watches the viewport as the page loads and keeps track of the largest thing rendered so far. Candidates are images, video poster frames, elements with CSS background images, and block-level text. Size means rendered size on screen, not file size, and the winner can change mid-load: a headline might hold the title until the hero image arrives and takes over. On most marketing pages the LCP element is the hero image, which is why so much LCP work is image work.
What slows LCP down
- Heavy images. An uncompressed hero shipped at full camera resolution is the single most common cause of a failing score.
- Slow server response. If the HTML takes two seconds to arrive, nothing can render before then. Aim for a time to first byte under 800 milliseconds.
- Render-blocking CSS and JavaScript. The browser cannot paint until blocking resources in the head are downloaded and parsed.
- Lazy loading the hero. A loading attribute of lazy on the LCP image tells the browser to wait on the one file it needed first.
- Client-side rendering. Frameworks that build the page in the browser delay every paint until the JavaScript runs. Server rendering or static output avoids the wait.
- Slow web fonts. When the LCP element is text, a font that arrives late can hold up the render.
How to improve your LCP score
-
Compress the hero and use modern formats
Serve AVIF or WebP at the size the layout actually displays, with srcset for smaller screens. This alone rescues many failing pages.
-
Preload the LCP image
A preload link in the head with fetchpriority high tells the browser to fetch the hero immediately instead of discovering it late in parsing.
-
Never lazy load above the fold
Lazy loading belongs on images below the viewport. On the LCP element it is pure delay.
-
Cut render-blocking resources
Inline the critical CSS, defer the rest, and add defer or async to scripts. The browser paints as soon as nothing stands in its way.
-
Speed up the server
Better hosting, server-side caching, and leaner database queries all shrink time to first byte, which every later milestone inherits.
-
Serve assets from a CDN
Files delivered from a server near the visitor arrive faster. For a national or global audience a CDN routinely takes a second or more off LCP.
-
Preload fonts when text is the LCP
Preload the main text font and use font-display swap so readable text renders without waiting on the file.
-
Cache static assets
Long cache lifetimes make repeat visits nearly instant, and repeat visits count in your field data too.
The fixes in code
<!-- Preload the hero so the browser fetches it first -->
<link rel="preload" as="image" href="/images/hero.avif" fetchpriority="high">
<!-- Responsive hero: right format, right size, never lazy -->
<img src="/images/hero-800.avif"
srcset="/images/hero-400.avif 400w,
/images/hero-800.avif 800w,
/images/hero-1200.avif 1200w"
sizes="(max-width: 600px) 400px, (max-width: 1000px) 800px, 1200px"
width="1200" height="600" alt="Product hero" fetchpriority="high">
<!-- Scripts wait their turn instead of blocking the paint -->
<script src="/js/analytics.js" defer></script>Measuring LCP
PageSpeed Insights shows lab and field LCP for any URL and names the LCP element in its diagnostics. Search Console reports Core Web Vitals site-wide, and the Chrome DevTools Performance panel marks the LCP moment on a timeline you can click into. Field data from real Chrome users is what Google ranks on, so treat lab runs as debugging and field data as the scoreboard. We keep a fuller tool rundown in our post on technical SEO tools.
LCP next to the other Core Web Vitals
| Metric | Measures | Good threshold | Primary fix |
|---|---|---|---|
| LCP | Loading speed | 2.5 seconds | Lighter, preloaded hero and faster server |
| INP | Responsiveness | 200 milliseconds | Stop blocking the main thread |
| CLS | Visual stability | 0.1 | Reserve space for everything |
The three are siblings and the fixes overlap: sized, compressed images help LCP and Cumulative Layout Shift at the same time, and the script diet that speeds up rendering also improves Interaction to Next Paint. Note that INP replaced First Input Delay as the responsiveness metric in March 2024, so anything you read about FID is out of date.
Where Egochi fits
Egochi audits and fixes Core Web Vitals as part of our technical SEO services: identifying the LCP element on your key templates, fixing the image and server issues behind slow scores, and watching field data so regressions get caught before they cost rankings. This site is built to the same standard, which you can check in ten seconds with PageSpeed Insights.
Questions people ask about LCP
What is a good LCP score?
A good LCP score is 2.5 seconds or less. Between 2.5 and 4.0 seconds needs improvement, and above 4.0 seconds is poor. Google measures the 75th percentile of real page loads, so 75% of visits need to land at 2.5 seconds or under to pass.
What causes a high LCP?
The usual suspects are large uncompressed images, slow server response, render-blocking CSS and JavaScript, and hero images that were accidentally lazy loaded. Images are the most common cause by far; a heavy hero image alone can push LCP past 4 seconds.
How do I find my LCP element?
Run the page through PageSpeed Insights and check the diagnostics, which name the LCP element directly. In Chrome DevTools, record a page load in the Performance panel and click the LCP marker in the timings row to highlight the exact element.
What is the difference between LCP and FCP?
First Contentful Paint fires when anything renders, even a spinner or a nav bar. Largest Contentful Paint waits for the biggest visible element, which is usually the content people came for. LCP is one of the Core Web Vitals; FCP is not.
Can text be the LCP element?
Yes. If no larger image sits in the viewport, a big headline or opening paragraph block can be the LCP element. Slow web font loading then delays it, which is why font preloading shows up in LCP work as often as image compression does.
Does LCP affect mobile and desktop rankings separately?
Yes. Google evaluates mobile and desktop field data separately, and mobile is almost always the slower of the two because of weaker hardware and slower connections. Fix mobile first; most of your visitors are there anyway.
