Largest Contentful Paint, or LCP, measures how long the largest visible element on a page takes to finish rendering, counted from the moment navigation starts. A good LCP is 2.5 seconds or less. Google made LCP one of its three Core Web Vitals because it is the closest a machine gets to the question every visitor silently asks, which is when can I see the thing I came for. This post covers what counts as the LCP element, the four phases hiding inside every LCP time, where the thresholds come from, how to find your element in under a minute, the causes ranked by how often we correct them in audits, and the fixes with code.
The short version
- Good is 2.5 seconds or less, poor is above 4.0, measured at the 75th percentile of real Chrome visits.
- The LCP element is whatever renders largest in the viewport, most often the hero image.
- Every LCP splits into four phases; diagnose which phase is slow before touching anything.
- The two biggest levers are a right-sized, preloaded hero and a faster first byte.
- Never lazy load the LCP element; that one attribute adds seconds on its own.
Why Google invented LCP
For years the industry timed pages with onload and DOMContentLoaded, and both lie. A page can fire onload long after its content was visible, or long before, depending on how it loads scripts and images. First Contentful Paint got closer but fires when anything renders, including a spinner or a bare background. LCP exists because Google needed a milestone that tracks perceived loading, the moment the main content is actually on screen. It arrived with the Core Web Vitals announcement in May 2020 and has counted toward the page experience signals since the rollout that began in June 2021. Of the three metrics it is the one visitors feel first, because it is literally the wait before the page looks loaded.
What counts as the LCP element
The browser watches the viewport during load and keeps a running record of the largest rendered element. Candidates are img elements, image elements inside SVG, video elements with a poster frame or a painted first frame, elements with a CSS background image loaded through url(), and block-level elements containing text. Size means rendered area inside the viewport, not file size, and only the visible portion counts, so an image that overflows the screen is scored on what shows.
Chrome also filters out candidates that are unlikely to be real content. Elements with zero opacity do not qualify, full-viewport backgrounds are treated as wallpaper rather than content, and since Chrome 112 images with very little image data per rendered pixel, like a stretched gradient placeholder, are excluded too. The record can change mid-load: a headline often holds it until the hero image arrives and takes over. That is why the final LCP element on most marketing pages is the hero image, and why so much LCP work turns out to be image work.
The four phases inside every LCP time
Chrome's diagnostic model splits any LCP time into four phases that add up to the total. Putting numbers on each phase, which the DevTools Performance panel and PageSpeed Insights both do, tells you where to work before you change a line of code. A slow download needs compression; a slow start needs a preload; neither fix helps the other problem.
| Phase | The clock runs while | What moves it |
|---|---|---|
| Time to first byte | The server prepares and starts sending the HTML | Better hosting, server caching, a CDN |
| Resource load delay | The browser has the HTML but has not started fetching the LCP file | Preload, fetchpriority high, no lazy loading |
| Resource load duration | The LCP file downloads | Modern formats, compression, right-sized images |
| Element render delay | The file is here but pixels have not painted | Cut render-blocking CSS and JavaScript |
A text-only LCP skips the two resource phases entirely, which is why pages with a headline as the LCP element usually pass unless a web font or blocking script holds up the paint. The phase people miss most is resource load delay: the image downloads fast once it starts, but it starts late because the browser had to run a script or parse a stylesheet before it ever discovered the file.
Where the thresholds come from
Good is 2.5 seconds or less, poor is above 4.0, and the range between needs improvement. The score that counts comes from the Chrome UX Report, known as CrUX, which collects real page loads from opted-in Chrome users. Google assesses the 75th percentile over a rolling 28-day window, with mobile and desktop scored as separate assessments. Passing means three out of four real visits beat 2.5 seconds, including the visitor on a mid-range phone riding a weak cell signal. A lab run on office fiber is not that number. PageSpeed Insights shows both, field data on top and the Lighthouse lab run below, and the working rule is simple: lab data is for debugging, field data is the scoreboard.
How to find your LCP element
Three ways, fastest first. PageSpeed Insights names the element in its diagnostics for both mobile and desktop. Chrome DevTools shows it live: record a reload in the Performance panel and click the LCP marker in the timings row to highlight the element and read the phase breakdown. And for the page you are on right now, paste this into the console:
new PerformanceObserver((list) => {
const entry = list.getEntries().at(-1);
console.log(entry.element, Math.round(entry.startTime) + 'ms');
}).observe({ type: 'largest-contentful-paint', buffered: true });Check your top templates, not just the homepage, and check them at a mobile viewport. The LCP element often differs by screen size, because the element that renders largest on a phone is not the one that renders largest on a desktop monitor.
The causes, ranked by how often we correct them
- Oversized hero images. A hero shipped at full camera resolution, displayed at a fraction of that, is the most common cause of a failing score by a wide margin.
- Lazy loading the hero. A loading attribute of lazy on the LCP image tells the browser to deprioritize the one file it needed first. This single attribute is the cheapest seconds-scale fix that exists.
- Slow server response. If the HTML takes two seconds to arrive, no fix downstream can produce a fast LCP. Aim for a first byte under 800 milliseconds.
- Render-blocking CSS and JavaScript. The browser cannot paint until blocking resources in the head are downloaded and parsed, so they stretch render delay for every element.
- Late discovery. Heroes set as CSS background images or inserted by JavaScript are invisible to the browser's preload scanner, so the fetch starts after the stylesheet or script runs.
- Client-side rendering. Frameworks that build the page in the browser delay every paint until their JavaScript downloads, parses, and runs. Server rendering or static output removes the wait.
- Slow web fonts. When the LCP element is text, a font that arrives late can hold the render or restyle it mid-paint.
Our audit shorthand: two fixes rescue most failing pages before anything clever happens. Serve the hero at the size the layout displays, in AVIF or WebP, and preload it with high priority. Do those two, remeasure, and only then decide whether the remaining gap justifies server work or a render-blocking cleanup.
How to fix a slow LCP
-
Compress the hero and use modern formats
Serve AVIF or WebP at the dimensions the layout actually displays, with srcset variants for smaller screens. This alone moves many pages from poor to good.
-
Preload the LCP image with high priority
A preload link in the head with fetchpriority high starts the fetch immediately instead of after the parser stumbles onto it. This kills resource load delay.
-
Never lazy load above the fold
Lazy loading belongs on images below the viewport. On the LCP element it is pure delay with zero benefit.
-
Cut render-blocking resources
Inline the critical CSS, defer the rest, and add defer or async to every script. The browser paints as soon as nothing stands in its way.
-
Speed up the first byte
Server caching, leaner database queries, and better hosting shrink time to first byte, and every later phase inherits the head start.
-
Serve assets from a CDN with long cache lifetimes
Files delivered from a server near the visitor arrive sooner, and cached repeat visits count in your field data too.
-
Preload fonts when text is the LCP
Preload the main text font and use font-display swap so readable text paints without waiting on the file.
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>Notes for specific platforms
On WordPress, core lazy-loads images by default and recent versions skip the first image, but themes that paint the hero as a CSS background hide it from the preload scanner, so add an explicit preload for it. Page builders tend to ship render-blocking CSS bundles far larger than any single page needs. On Next.js, the image component with the priority prop handles the preload and fetch priority for the hero in one line. Static builders like Astro, which this site runs on, write dimensions and modern formats at build time and keep the first byte fast because there is no server work per request. On Shopify, injected app scripts are the usual render-blocking culprits, and removing unused apps is often worth more than any image tweak.
What does not move LCP
- Chasing a 100 Lighthouse score. The performance score is a lab composite. Google ranks on field data, and a 95 with passing field metrics beats a lab-perfect page that fails in CrUX.
- Minifying HTML. Kilobytes off the document rarely convert to visible milliseconds. Spend the effort on the image weight instead.
- Preloading everything. Preload is a priority budget. Spend it on the LCP resource and the critical font; ten preloads compete with each other and the win disappears.
- fetchpriority high on every image. If everything is high priority, nothing is. Mark the hero, leave the rest.
- Switching hosts on a hunch. If your first byte is already under 800 milliseconds, a faster server fixes a phase that was never the problem. Read the phase breakdown first.
What LCP means for rankings
Core Web Vitals are a real ranking signal, and an honest one to describe: Google treats page experience as a tiebreaker-weight factor, not a heavyweight. A fast LCP will not carry thin content past a strong competitor, but where pages are otherwise close it can decide the order, and slow pages bleed visitors before rankings ever enter it. LCP also travels with its two siblings. The image sizing that speeds up your paint also stabilizes Cumulative Layout Shift, and the script diet that unblocks rendering also improves Interaction to Next Paint, which replaced First Input Delay in March 2024. Fixing one usually pays into all three.
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, reading the phase breakdown, 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 over a rolling 28-day window, so three out of four visits need to land at 2.5 seconds or under to pass.
What causes a high LCP?
The usual suspects are oversized hero images, a hero that was accidentally lazy loaded, slow server response, and render-blocking CSS and JavaScript. Images are the most common cause by far; a hero shipped at full camera resolution can push LCP past 4 seconds on its own.
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 on the page.
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 separately?
Yes. Google evaluates mobile and desktop field data as separate assessments, 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.
