What Is a Good LCP Score? (And How to Check Yours in PageSpeed Insights)
Under 2.5 seconds. Here's exactly how Google measures LCP, what counts as the LCP element, and how to fix yours.
Largest Contentful Paint measures how long it takes for the largest visible element above the fold to render in the browser. Google's scoring thresholds:
| Score | LCP Value |
|---|---|
| Good | Under 2.5 seconds |
| Needs Improvement | 2.5 to 4.0 seconds |
| Poor | Over 4.0 seconds |
These thresholds apply to the 75th percentile of page loads for real users. That means Google looks at all the LCP measurements collected from Chrome users loading your page and takes the value at the 75th percentile — a score that 75% of your users experience or better. A single fast load from a high-speed connection doesn't move the needle much; slow loads on mobile connections or older devices pull the 75th percentile up significantly.
What Counts as the LCP Element
LCP is not always a hero image. Google defines LCP as the largest element by visible area that's above the viewport when the page starts loading. The candidate elements are:
<img>tags (including<image>inside SVG)<video>poster images- Elements with a CSS
background-image(though these are less favorable — see below) - Block-level text elements (
<p>,<h1>,<h2>,<li>, etc.) that contain text
The LCP element is determined dynamically as the page renders — it can change as larger elements paint. Google uses the last reported candidate as the final LCP element.
Common LCP elements by site type:
- Blog homepage: the
<img>in the featured post card or the above-fold hero banner - Product page: the primary product image
- Landing page: the hero background image or H1 headline
- News article: the featured article image or the first image in the article
For text-heavy pages with no images above the fold, LCP is often the H1 heading. In this case, font loading time becomes the relevant variable.
How to Find Your LCP Element in PageSpeed Insights
Run your URL at PageSpeed Insights. In the Lab Data section, you'll see the LCP score with a timestamp. Scroll to Diagnostics > Largest Contentful Paint element — PSI shows the exact element, including its CSS selector path.
Example output from PSI:
Largest Contentful Paint element
1 element found
img.hero-image
Click "Expand view" to see the full selector. This tells you exactly which element to target.
Lab data vs. Field data:
PSI shows both. Lab data (the Lighthouse run) simulates a page load from a controlled environment on a throttled mobile connection. Field data comes from the Chrome User Experience Report (CrUX), which collects real measurements from Chrome users on your site.
Lab data is your diagnostic tool — use it to identify the LCP element and test fixes. Field data is the ranking signal — it's the number that actually affects your position in search results. Field data requires 28 days to cycle, so changes you make today won't appear in your CrUX field data for a month.
The 4 Most Common LCP Regressions
1. Lazy-Loaded Hero Image
This is the single most common LCP failure, particularly on WordPress. Adding loading="lazy" to an above-the-fold hero image tells the browser to defer the download — directly increasing LCP.
The fix:
<img
src="hero.jpg"
alt="Hero"
loading="eager"
fetchpriority="high"
width="1200"
height="630"
/>
fetchpriority="high" tells the browser to prioritize this download above other same-type resources. loading="eager" ensures the browser doesn't defer it. Both attributes together have the best LCP impact.
For WordPress specifically, the lazy-load attribute is added automatically by WordPress Core for most images. See WordPress Lazy Loading LCP Fix for the filter-based fix.
2. Render-Blocking CSS
If your LCP element is above the fold but the browser isn't showing it, the delay is often caused by render-blocking stylesheets. The browser doesn't render anything until all blocking CSS in <head> is downloaded and parsed.
<!-- This blocks rendering until the CSS downloads -->
<link rel="stylesheet" href="/styles/main.css">
<!-- Better: preload critical CSS, load rest async -->
<link rel="preload" href="/styles/critical.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<link rel="stylesheet" href="/styles/non-critical.css" media="print" onload="this.media='all'">
The practical approach: use a performance plugin (WP Rocket, Perfmatters for WordPress; Speed Booster for other CMS platforms) that automatically identifies and inlines critical CSS. Manually optimizing this is time-consuming and brittle.
3. Slow Server TTFB
Time to First Byte (TTFB) is the time between the browser sending a request and receiving the first byte of the response. If TTFB is 1,200ms, your LCP can't be under 2.5 seconds even with a perfectly optimized image — the math doesn't work.
Google's threshold for good TTFB is under 800ms.
TTFB causes:
- Unoptimized server or hosting plan — shared hosting on oversold servers, database queries without caching, no object caching (Redis, Memcached)
- No CDN — origin server responding from a geographic location far from the user
- Slow database queries — especially on dynamic pages that run multiple DB queries per load (WordPress on cheap hosting is the canonical example)
The fix hierarchy: enable full-page caching first (this is the highest-impact TTFB fix for WordPress sites), then add a CDN, then optimize database queries.
4. Render-Blocking JavaScript
JavaScript files in <head> without async or defer attributes pause HTML parsing until the script downloads and executes. If your LCP image is in the HTML below a blocking script, the browser won't start downloading the image until the script finishes.
<!-- Blocking — delays everything after it -->
<script src="/vendor/heavy-library.js"></script>
<!-- Non-blocking — parses after HTML, executes in order -->
<script src="/vendor/heavy-library.js" defer></script>
<!-- Non-blocking — executes immediately when downloaded, may be out of order -->
<script src="/analytics.js" async></script>
For LCP specifically: use defer for scripts that need to run after DOM parsing, async for scripts that don't depend on DOM order (analytics, ad scripts). Neither attribute delays HTML parsing or image downloading.
Priority Fix Order
If PSI shows a Poor LCP score (over 4s), work through the regression list in this order:
- Check for lazy-loaded hero image first — this is the most common cause and the fastest fix
- Check TTFB — if PSI shows TTFB over 800ms in the Diagnostics section, fix hosting/caching before anything else. Image optimization doesn't help much if the page itself takes 2 seconds to respond.
- Check for render-blocking CSS — PSI flags this under "Eliminate render-blocking resources"
- Check for render-blocking JS — also flagged under "Eliminate render-blocking resources"
For a Needs Improvement score (2.5–4s), the fixes above still apply but the impact of each fix is smaller. In this range, the most common remaining cause is a combination of slow image delivery (no CDN, wrong image format, oversized images) and TTFB slightly above the threshold.
For platform-specific guidance, see WordPress Lazy Loading LCP Fix for WordPress, Elementor LCP Fix for Elementor specifically, and the Core Web Vitals guide for the full context on how LCP fits alongside INP and CLS in Google's page experience evaluation.
RankCrab's on-page audit runs PageSpeed Insights against your URLs and surfaces LCP, INP, and CLS scores in one place — so you can see which pages are in Good, Needs Improvement, or Poor range without running PSI manually on every URL. Track scores over time as you apply fixes to confirm what's actually moving the needle.