Real visitors wait too long for the main content to appear

MediumConfirmedperf.crux.lcp-poor

What this check looks for

For a quarter of real visits to ‹scope›, the largest thing on the screen — usually the hero image or the headline — took ‹value› to appear. Google's threshold for a good experience is 2.5 seconds.

Why it matters

This is the metric users describe as "the site is slow". It is a Core Web Vital, so it feeds Google's page experience signals, and it correlates directly with people leaving before the page finishes.

When the check passes, your report says: “Real visitors see the main content within Google's threshold”.

What it costs your score

When this check fails it removes 12 points from your Performance score, before the status, confidence and repeat multipliers are applied. Performance carries a weight of 8 in the overall score.

It shares the performance.field family ceiling of 35 points: however many findings that family produces, together they cannot remove more than that from Performance. One underlying problem showing up in several places is still one problem.

Severity: medium
Default confidence: confirmed
Status when triggered: fail
Deduction: 12 points
Family cap: performance.field · 35
Category: Performance
Module: Perf crux
Fix owned by: user
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Get the largest element on the page painted within 2.5 seconds for three visits in four.

A quarter of your real visitors currently wait ‹value› to see anything substantial, and a large share of them leave before it arrives.

Identify which element is the LCP element — it is almost always the hero image, a background image, or the first block of text. We do not report it: our lab audit measures render-blocking resources, image weight and server response time, not which element painted last. Chrome DevTools does, under Performance → the LCP marker, and so does PageSpeed Insights for the same URL.
If it is an image: serve it at the size it is displayed, in AVIF or WebP, and give it fetchpriority="high". Never lazy-load the LCP image — loading="lazy" on it is the single most common cause of a poor LCP.
Preload the LCP resource (<link rel="preload" as="image">) so it is not discovered late in the document.
Remove render-blocking CSS and synchronous JavaScript from the critical path; those delay the render, not just the download.
Check the server response time first if it is a large share of the total — no front-end change can recover time already spent waiting for the first byte. Google treats 800 ms as the good threshold for field TTFB; the lab number in this report is a single request from a data centre and is normally the optimistic end of what real visitors see.

How to confirm it worked

Re-run this scan after the change has been live for several weeks — field data uses a trailing 28-day window and will not move sooner.
In the meantime, confirm the change in the lab section of this report, and in Chrome DevTools under Performance → LCP.

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

Page HTML

<!-- The LCP image: sized, modern format, high priority, never lazy. -->
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">

<img src="/hero.avif" alt="" width="1200" height="600"
     fetchpriority="high" decoding="async">

<!-- Wrong, and very common: -->
<!-- <img src="/hero.jpg" loading="lazy"> -->

width and height are not optional here: without them the image contributes to layout shift as well, which is a second Core Web Vital failing for the same reason.

Technical detail

Largest Contentful Paint at the 75th percentile: **‹value›** (‹band›).

This is **field data**: the experience of real Chrome users who visited ‹scope› over the trailing 28-day collection window, not a measurement we took ourselves. The number quoted is the **75th percentile** — Google's own choice of statistic, meaning three visits in four were at least this good. A site with a fast median can still fail here, and that is the point: the quarter of visits that are worst are real people on real networks and devices.

Field data also lags. A fix you deployed yesterday will not move this number until it has been in front of users for most of the window, so use the lab measurements alongside it to confirm the change landed.

Google's published thresholds: **good at or below 2,500 ms**, needs improvement up to 4,000 ms, **poor above 4,000 ms**. We report a needs-improvement result as a warning and a poor result as a failure; the boundary is Google's, not ours.

LCP is a sum of four parts, and the fix depends entirely on which one dominates: time to first byte, resource load delay, resource load time, and element render delay. The lab audit in this report breaks the same page down by render-blocking resources, image weight and server response time, which is usually enough to tell which part is yours. ‹detail›