Google collects LCP data from real Chrome users via the Chrome User Experience Report (CrUX). If 75% of your real-world visitors experience LCP above 2.5 seconds, your page fails the Core Web Vital threshold and receives a "needs improvement" or "poor" label in Search Console. This CrUX data feeds directly into the page experience signal that influences search rankings.
The threshold ladder:
- Good: LCP ≤ 2.5 seconds
- Needs improvement: 2.5–4.0 seconds
- Poor: > 4.0 seconds
The benchmark is measured at the 75th percentile of page loads — meaning 75% of your visitors must be at or below 2.5 seconds for the page to be considered good.
Key Takeaways
- LCP is a Core Web Vital — poor LCP directly affects page experience rankings in Google Search
- The LCP element is usually a hero image, background image, or the H1 text block — identifying it is the first diagnostic step
- The four root causes of slow LCP: slow server response (TTFB), render-blocking resources, slow resource load time (large/unoptimised LCP image), slow element render time (CSS delays)
- Preloading the LCP image with
<link rel="preload" fetchpriority="high">is typically the single biggest LCP improvement for image-based LCP - Text-based LCP (H1 rendered as LCP) is usually caused by render-blocking CSS or web fonts; fix by inlining critical CSS and adding font-display: swap
What Becomes the LCP Element
The LCP element is whatever the browser considers the largest content element visible in the initial viewport when the page loads. It's not necessarily the element the designer considers most important. In practice:
| Common LCP element | When it appears |
|---|---|
Hero image (<img> tag) |
Any page with a large above-the-fold product or feature image |
| CSS background image | Pages where the hero is applied via background-image: in CSS |
| H1 text block | Text-heavy pages (blog articles, landing pages) without a large hero image |
| Video poster image | Pages with autoplay hero videos |
To confirm the LCP element on any page: open Chrome DevTools → Performance tab → record a page load → look for the "LCP" marker → click it to highlight the element in the DOM. Or check PageSpeed Insights — it shows a screenshot with the LCP element annotated.
The Four Root Causes of Slow LCP
1. Slow Server Response (TTFB)
LCP cannot happen until the HTML that references the LCP element has arrived. If TTFB is 3 seconds, LCP cannot be below 3 seconds — regardless of any other optimisation. Fix TTFB first.
Diagnose: measure TTFB with PageSpeed Insights or the ByteWaveNetwork Page Speed Inspector (which breaks TTFB into DNS + TCP + TLS + server processing time). If server processing time is dominant, look at caching, database query optimisation, or CDN deployment. If DNS or TCP time is dominant, a CDN solves it by serving from edge nodes close to users.
2. Render-Blocking Resources
Scripts and stylesheets without async/defer in the <head> block HTML parsing, which delays DOM construction, which delays LCP. This is the most common cause of LCP between 2.5 and 5 seconds on otherwise well-built sites.
Common offenders:
- Google Tag Manager synchronous script tag in
<head> - Third-party chat widgets loaded synchronously
- Monolithic CSS bundles with no critical-CSS extraction
- Framework scripts loaded before the hero component renders
Fix: add defer to non-critical scripts. Inline critical CSS (the styles needed to render above-the-fold content), and load the full CSS asynchronously using the media="print" onload="this.media='all'" pattern.
3. Slow Resource Load Time (LCP Image)
When the LCP element is an image, the image's own download time directly becomes LCP time. Common problems:
Image size too large. A 3MB hero image served as the LCP candidate, even with lazy loading disabled, takes several seconds to download on mobile. Convert hero images to WebP or AVIF (typically 40–80% smaller than JPEG at equivalent quality). Set explicit dimensions and serve appropriately sized variants with srcset.
LCP image is discovered late. The browser discovers images referenced in <img src="..."> tags during HTML parsing. But images referenced only in CSS (background-image) or injected by JavaScript aren't discovered until CSS/JS parse time — which may be hundreds of milliseconds later. The fix: use <img> for LCP images, not CSS backgrounds. If you can't, use a resource hint:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">This tells the browser to start loading the image immediately, even before it encounters the CSS rule that references it.
LCP image is lazy-loaded. A common mistake: applying loading="lazy" to the hero image because "all images should be lazy." Above-the-fold images — especially the LCP candidate — should never be lazy-loaded. Remove loading="lazy" from the LCP image and add fetchpriority="high" to signal its importance to the browser's preload scanner.
4. Slow Element Render Time
Even after an image downloads, the browser may not paint it immediately. CSS animation, JavaScript that blocks the main thread, or excessive DOM nesting can delay the actual paint event. Diagnose by comparing the image resource load time (visible in the network waterfall) against the LCP timestamp — if there's a gap, the element is loaded but not painted. The fix is usually eliminating main-thread JavaScript work that runs between resource load completion and LCP paint.
Preloading the LCP Image — the Single Biggest Win
For image-based LCP, a preload hint is consistently the highest-value optimisation:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">This tag in <head> instructs the browser's preload scanner — which runs concurrently with HTML parsing, before any CSS or JavaScript executes — to begin fetching the LCP image immediately. Without it, the image isn't discovered until the browser reaches the <img> tag in the HTML parse tree, by which point several hundred milliseconds may have passed.
If the LCP image uses srcset, preload the correct size variant with imagesrcset and imagesizes:
<link rel="preload" as="image"
href="/hero-800.webp"
imagesrcset="/hero-400.webp 400w, /hero-800.webp 800w, /hero-1600.webp 1600w"
imagesizes="(max-width: 768px) 100vw, 50vw"
fetchpriority="high">Diagnosing LCP with the Page Speed Inspector
The ByteWaveNetwork Page Speed Inspector reports TTFB (broken into DNS/TCP/TLS/server), compression, render-blocking resources, images missing dimensions, and images without lazy loading — all the signals that feed into LCP. Running it on a URL gives you a ranked list of which issues to fix first, specific filenames for render-blocking scripts, and the compression status of the main document.
For a fuller LCP-specific diagnosis, PageSpeed Insights (lab) shows the LCP element, the LCP breakdown (TTFB + resource load delay + resource load time + element render delay), and annotated screenshots. CrUX field data in PSI shows real-user LCP across your actual visitor base, which matters because lab simulations don't reflect CDN cache status, geographic distribution, or real network conditions.
Measure TTFB, Render-Blocking Resources, and Image Issues
Free, no signup. The Page Speed Inspector surfaces the specific causes of slow LCP: TTFB breakdown, render-blocking scripts and stylesheets, uncompressed responses, and images missing dimensions or lazy-load attributes.
Try the Page Speed Inspector Free →Affiliate disclosure: Some links on this page may be affiliate links. We only mention tools we've personally used and have an honest opinion about. Affiliate revenue helps keep ByteWaveNetwork's tools free and maintained. We are not paid by any of the tools compared in this article for favorable coverage.