Need More Growth & Leads?
We are ready to work with your business and generate some real results…
Let's TalkJoin Our Community: Subscribe for Updates
Get notified of the best deals on our WordPress themes.
What is Largest Contentful Paint (LCP)?
Largest Contentful Paint (LCP) measures how long it takes for the largest visible element on a page (usually a hero image, a banner, or a big block of text) to load and appear. It’s one of Google’s three Core Web Vitals, and it answers the user’s first question about any page: “is this thing loading?” A good LCP is 2.5 seconds or less, measured at the 75th percentile of real visits (web.dev). Slow LCP is what makes a page feel sluggish before a visitor has seen anything useful.
Key Takeaways
- LCP measures when the largest visible element finishes loading; good is 2.5 seconds or less (web.dev).
- It’s measured on real users at the 75th percentile, so it must be fast for most visitors, not just on your fast connection.
- The usual culprits: heavy images, slow server response, and render-blocking CSS or JavaScript.
- Fixing LCP is mostly about optimising images, speeding up the server, and unblocking the render path.
LCP is the loading half of page experience, and it’s often the Core Web Vital businesses fail first, because images and slow servers are everywhere. The good news is that it’s also one of the most fixable, since the causes are well understood and the tools to diagnose it are free. This guide explains what LCP is, what drags it down, and the concrete steps to get it into the good range, as one of three metrics covered in our Core Web Vitals beginner’s guide.
The table below maps the common causes of poor LCP to their fixes.
| Cause of slow LCP | Fix |
|---|---|
| Large, unoptimised images | Compress, use modern formats, size correctly |
| Slow server response (TTFB) | Better hosting, caching, a CDN |
| Render-blocking CSS/JS | Minify, defer, inline critical CSS |
| Lazy-loading the LCP element | Don’t lazy-load above-the-fold content |
| Slow-loading web fonts | Preload fonts, use font-display |
Why does LCP matter?
LCP matters because it captures the moment a page becomes useful to a visitor, and slow loading drives people away before they engage. As the loading metric among Core Web Vitals, it directly reflects perceived speed, and perceived speed shapes whether someone stays. Google’s data shows the probability of a bounce rises 123% as mobile load time goes from 1 to 10 seconds (Think with Google, 2017), and LCP is the metric most tied to that experience.
It also matters for search. Core Web Vitals, including LCP, are part of Google’s page experience signals, which its core ranking systems are designed to reward (web.dev). A poor LCP can therefore work against you in two ways at once: it loses impatient visitors, and it weakens a page-experience signal that helps competitive pages rank.
The encouraging part is the payoff. Because LCP is usually dominated by one or two heavy elements (typically a large image or a slow server response), fixing it often produces a big, visible improvement from a focused effort. Of the three Core Web Vitals, LCP is frequently where the fastest, most noticeable gains live, which is why it’s a sensible place to start, and it overlaps directly with general website speed optimization.
How common is poor LCP?
Poor LCP is widespread, not a rare edge case. As of the 2025 HTTP Archive Web Almanac, only about 62% of mobile page loads achieve a “good” LCP, which means nearly four in ten (38%) still fail it (HTTP Archive). That makes LCP the Core Web Vital the most sites fail, ahead of both Cumulative Layout Shift and Interaction to Next Paint.
The reason it’s so commonly failed is that its causes are everywhere: large hero images, slow or uncached servers, and render-blocking resources are the default state of most sites rather than the exception. The flip side is opportunity. Because so many competing pages fail LCP, getting yours into the good range is a genuine differentiator, both for the visitors who stay and for the page-experience signal that helps you rank. Far from being a niche technical metric, LCP is the most failed and often the most rewarding Core Web Vital to fix.
What slows down LCP?
LCP is slowed by three main things: heavy images, slow server response, and resources that block the page from rendering. Diagnosing which one is your bottleneck is the first step, and free tools like PageSpeed Insights point you straight at it.
The most common cause is images. The largest element on most pages is an image, and if it’s a large, uncompressed file in an old format, it takes too long to download and paint. Serving oversized images (far bigger than they display) compounds the problem. The second cause is slow server response, measured as Time to First Byte: if your hosting is slow or the page isn’t cached, the browser waits before it can even start rendering, delaying everything including LCP.
The third cause is render-blocking resources. CSS and JavaScript that must load before the page can paint hold up the LCP element, and bloated or poorly ordered stylesheets and scripts are a frequent offender. A subtler mistake is lazy-loading the LCP element itself: lazy loading is good for offscreen images, but applying it to the main above-the-fold image delays the very thing LCP measures. Slow web fonts can also contribute when text is the largest element. Identifying which of these dominates your LCP tells you exactly where to focus.
How do you improve LCP?
You improve LCP by optimising the largest element and clearing the path to render it: lighter images, a faster server, and unblocked CSS and JavaScript. Work in order of impact, starting with whatever your diagnostics flag as the bottleneck, usually images.
- Optimise images. Compress them, serve modern formats like WebP or AVIF, and size them to their display dimensions rather than shipping huge files. For the LCP image specifically, consider preloading it so the browser fetches it early, and never lazy-load an above-the-fold image.
- Speed up the server. Improve Time to First Byte with quality hosting, server-side caching, and a content delivery network (CDN) to serve assets from closer to the user. A fast server benefits every metric, not just LCP.
- Unblock rendering. Minify CSS and JavaScript, defer non-critical scripts, and inline the critical CSS needed to render above-the-fold content, so the LCP element isn’t waiting behind resources it doesn’t need.
- Handle fonts. If text is your LCP element, preload key fonts and use a sensible font-display setting so text appears quickly rather than waiting on the font.
Measure after each change with PageSpeed Insights and confirm progress in Search Console’s field data, since that’s what Google assesses. Because LCP is usually dominated by one heavy element, fixing that single thing often moves the metric into the good range, the focused win that makes LCP a good first target, as our guide to improving Core Web Vitals lays out across all three metrics.
Frequently asked questions
A good LCP is 2.5 seconds or less, measured at the 75th percentile of your real visitors (web.dev). Between 2.5 and 4 seconds is “needs improvement,” and over 4 seconds is “poor.” The 75th-percentile detail matters: 75% of real page loads must hit 2.5 seconds or less, so a page can feel fast on your device yet still fail if many real users are on slower connections or devices. Aim for the experience most visitors actually get.
Final thoughts
Largest Contentful Paint is the Core Web Vital that captures perceived loading speed, the moment a page becomes useful, and it’s usually the first one to fail because heavy images and slow servers are so common. The 2.5-second target is achievable for most sites with focused work on the right bottleneck.
Start by diagnosing what dominates your LCP (usually images), then optimise that element, speed up the server, and clear render-blocking resources. Because LCP is typically driven by one or two heavy things, fixing them often produces a large, visible gain, which is why it’s a great first metric to tackle. For the responsiveness and stability metrics, see our guides to interaction responsiveness (INP) and Cumulative Layout Shift.