Table of Contents
- What Largest Contentful Paint Is
- LCP Thresholds and 2026 Core Web Vitals Targets
- What Usually Causes Slow LCP
- How to Diagnose LCP Problems
- Image Optimization: The Highest-Impact LCP Fix
- Server, Render, and CDN Fixes for LCP
- LCP Fixes by Platform: WordPress, Shopify, and Headless
- How LCP Fits With INP and CLS
- Frequently Asked Questions
What Largest Contentful Paint Is
LCP measures the render time of the largest image or text block visible in the initial viewport. On a blog post that is usually the featured image or the headline; on an ecommerce category page it is typically the first product image row; on a homepage it is the hero banner. The metric updates as the page loads, so the element Google records is the largest one at the moment of the final qualifying paint.
Two properties make LCP the anchor of Core Web Vitals. It correlates strongly with how fast a page feels, because humans judge speed by when the main thing appears, not by when background resources finish. And it is measurable both in the lab and in the field, so the number you optimize in development is the same metric real users report through the Chrome User Experience Report.
| Common LCP element | Typical page type | Usual bottleneck |
|---|---|---|
| Hero image | Homepages, landing pages | Uncompressed upload, no preload, lazy-loaded by mistake |
| Headline text block | Blog posts, guides | Render-blocking CSS and web fonts |
| First product image | Ecommerce category pages | Unoptimized grids, third-party scripts before paint |
| Video poster frame | Agencies, media brands | Heavy poster image, autoplay video handshake |
LCP Thresholds and 2026 Core Web Vitals Targets
Google’s thresholds have been stable for years, which makes them reliable targets. An LCP of 2.5 seconds or better on the 75th percentile of real user loads counts as good, 2.5 to 4.0 seconds needs improvement, and above 4.0 seconds is poor. The 75th percentile matters: your fastest visitors cannot offset your slowest, because the metric is judged where most of your users actually experience it.
Assessment is per URL group on mobile and desktop separately, using 28-day field data. New pages and low-traffic pages lack field data, which is where lab tools like Lighthouse and PageSpeed Insights help as proxies, but ranking evaluation and your own dashboards should key off the field data once it exists. Treat lab scores as a compass and field data as the map.
| Core Web Vital | Good | Needs improvement | Poor |
|---|---|---|---|
| LCP | 2.5 seconds or less | 2.5 to 4.0 seconds | Above 4.0 seconds |
| INP | 200 milliseconds or less | 200 to 500 milliseconds | Above 500 milliseconds |
| CLS | 0.1 or less | 0.1 to 0.25 | Above 0.25 |
What Usually Causes Slow LCP
Across hundreds of audits, slow LCP traces to the same short list. Oversized hero images dominate: a 3,000-pixel-wide photo served to a phone at 400 pixels is the single most common cause we see. Render-blocking CSS and JavaScript sit second, because the browser cannot paint the hero until stylesheets download and parse. Slow server response (TTFB) third, since nothing paints until the HTML arrives.
The remaining causes are subtler but frequent. Lazy-loading the LCP image, a well-meaning performance plugin default, delays the most important asset on the page. Client-side rendering on JavaScript frameworks delays paint until bundles hydrate. Waterfalls of third-party tags, chat widgets, and A/B tools compete for bandwidth in exactly the window the browser needs for the hero. And image CDNs or hosts without modern formats silently double transfer sizes for every visitor.
| Cause | Typical LCP impact | Fix priority |
|---|---|---|
| Oversized, unoptimized LCP image | 1 to 4 seconds | Highest |
| Render-blocking CSS and JS | 0.5 to 2 seconds | Highest |
| Slow TTFB | 0.3 to 2+ seconds | High |
| Lazy-loaded LCP element | 0.5 to 3 seconds | High, quick win |
| Web font blocking headline paint | 0.2 to 1 second | Medium |
| Third-party tag waterfalls | 0.3 to 1.5 seconds | Medium |
| Client-side rendering without SSR | 1 to 4 seconds | High for JS frameworks |
How to Diagnose LCP Problems
Start with field data, because it reflects real users. PageSpeed Insights and the Core Web Vitals report in Search Console show the 75th-percentile LCP per URL group and, critically, which phase is slow: TTFB, resource load delay, resource load duration, or element render delay. That phase breakdown is the diagnosis — it tells you whether to fix the server, the asset, or the render path before you touch anything.
Then reproduce in the lab with Lighthouse or WebPageTest using mobile throttling, find the exact LCP element, and read the waterfall. Look for three things in order: how late the LCP image request starts (load delay), how long it takes to download (load duration), and whether the element waits on scripts or fonts after download (render delay). Each phase maps to a different fix, and guessing instead of diagnosing is how teams spend a week caching a page whose real problem was a lazy-loaded hero.
| LCP sub-part | What it means | Primary fix |
|---|---|---|
| TTFB | Time to first byte of HTML | Caching, CDN, faster hosting, database tuning |
| Load delay | Request starts late | Preload image, remove lazy-load on hero, fix discovery |
| Load duration | Download is slow | Compress, resize, modern formats, CDN edge delivery |
| Render delay | Paint waits after download | Inline critical CSS, font-display, defer non-critical JS |
Image Optimization: The Highest-Impact LCP Fix
Because the LCP element is an image on most commercial pages, image work pays the biggest dividends. Serve the hero at the size it renders — a 1,200 to 1,600 pixel width covers most full-width mobile heroes — and export in WebP or AVIF, which cut file sizes by 30 to 70 percent versus JPEG at similar quality. Compress deliberately: quality settings around 75 to 80 are visually transparent for photographs at hero sizes.
Then wire the browser to treat the hero as a priority. Preload it with a link tag in the head, include fetchpriority=”high” on the img element, and exclude it from lazy loading entirely — loading=”lazy” on an LCP image is a self-inflicted wound. Set width and height attributes so the layout reserves space, which simultaneously protects CLS. Where the CMS supports it, responsive srcset sizes let each device download only what its screen needs.
| Technique | How | Expected gain |
|---|---|---|
| Resize to render width | Match image dimensions to layout, use srcset | Large, often the whole gap |
| Convert to WebP or AVIF | CDN transform or CMS option | 30 to 70 percent smaller files |
| Preload + fetchpriority | Link rel=preload, fetchpriority=high | Removes seconds of load delay |
| Never lazy-load the hero | Exclude LCP image from lazy loading | Immediate, zero cost |
| Set width and height | Attributes on the img tag | Protects CLS while optimizing LCP |
For the broader picture beyond the hero, our page speed guide covers image strategy across whole templates.
Server, Render, and CDN Fixes for LCP
If the slow phase is TTFB, the fixes live upstream of the browser. Full-page caching for anonymous visitors, a CDN that serves HTML from edge locations, adequate hosting for your traffic profile, and database query tuning are the levers, roughly in order of cost-effectiveness. A page that paints in 1.8 seconds on a good cache hit and 4.5 on a miss has a caching problem, not a page-weight problem, and no amount of image work will hide it.
If the slow phase is render delay, attack the critical path. Inline the CSS the hero needs and load the rest asynchronously, use font-display: swap with preloaded font files so headlines paint immediately, and move analytics, chat, and personalization scripts to defer or after-interaction loading. On JavaScript frameworks, server-side rendering or static generation restores an early paint that pure client-side rendering gives away, and streaming SSR narrows the gap further for data-heavy pages.
LCP Fixes by Platform: WordPress, Shopify, and Headless
On WordPress, most LCP damage comes from plugin stacks: lazy-load applied to heroes, bloated sliders, and multiple caching plugins fighting each other. Pick one performance plugin or a lean code approach, exclude the hero from lazy loading, enable WebP conversion, and put the site behind a CDN with HTML caching for anonymous traffic. Check theme quality too, because premium themes shipping six sliders are a chronic source of render-blocking weight.
On Shopify, the theme and app ecosystem decide the outcome. Remove apps that inject render-blocking scripts, use image_url and width parameters so product images transform at the CDN, preload the featured collection image on landing templates, and resist autoplay video heroes on mobile. On headless builds, budget server components first, keep client bundles lean, adopt ISR or static generation for commercial pages, and instrument real-user monitoring at launch so regressions surface in days rather than quarters. Our WordPress speed guide and Core Web Vitals guide go deeper on each stack.
How LCP Fits With INP and CLS
LCP is one of three Core Web Vitals, and they fail in different ways. LCP is about perceived load speed, INP about responsiveness to interactions, and CLS about visual stability during load. A page can ace LCP at 1.9 seconds and still frustrate users if the first tap does nothing for 600 milliseconds, so treat the trio as a set: paint fast, respond fast, stop jumping.
They also interact. Fixing CLS by reserving image space helps LCP stay stable across template updates. Fixing render-blocking JavaScript for LCP usually improves INP on the same page. And a hero image swap that forgets width and height fixes LCP while quietly wrecking CLS, which is why every performance change should be verified against all three metrics in field data, not just the one you were targeting. Our small-business speed guide sequences the whole program for lean teams, and when you want performance treated as a growth lever, Digimau builds Core Web Vitals work into every SEO engagement.
Frequently Asked Questions
These are the questions US business owners and developers ask most about LCP, answered plainly.
What is a good LCP score?
2.5 seconds or faster at the 75th percentile of real user loads is good. Between 2.5 and 4.0 seconds needs improvement, and above 4.0 seconds is poor by Google’s published thresholds.
How do I find my LCP element?
Run PageSpeed Insights or Lighthouse on the page and open the diagnostics: the LCP element is named directly. In field data, the web-vitals JavaScript library and CrUX-based tools report which element real users experienced.
Why is my LCP image slow even though it is compressed?
Compression fixes load duration, but the delay is often load delay or render delay: the image is lazy-loaded, discovered late, or waiting on CSS and fonts. Check the LCP phase breakdown before re-compressing.
Does lazy loading hurt LCP?
Yes, when applied to the LCP element. Lazy-load everything below the fold, but the hero image must load eagerly, preloaded, with fetchpriority set to high.
Is LCP a Google ranking factor?
Core Web Vitals are part of Google’s page experience signals, which act as a tiebreaker among comparable results rather than a primary ranking driver. Fix them for users first; the SEO benefit compounds with every other signal.
How is LCP different from FCP?
First Contentful Paint measures when anything first paints, often a header or spinner. LCP measures when the largest above-fold element paints, which matches what users perceive as loaded.
How long does it take to fix LCP?
Image and lazy-load fixes can show field-data movement within a few weeks of deployment, because CrUX rolls on a 28-day window. Server-level fixes take longer to validate but often deliver the biggest single gain.
What tools measure LCP?
PageSpeed Insights, Lighthouse, WebPageTest, Search Console’s Core Web Vitals report, and real-user monitoring libraries like web-vitals. Use lab tools to diagnose and field data to verify.
Does WebP improve LCP?
Usually yes, by shrinking the LCP image download. AVIF can shrink it further. Format change alone will not rescue a page with severe render-blocking or TTFB problems, so fix phases in order.
What is a good TTFB for LCP?
Aim for under 800 milliseconds at the 75th percentile, which is Google’s guidance for the TTFB vital. Faster is better: every millisecond of TTFB delays everything that follows, including the hero paint.
Related Articles
Keep reading with these guides:
