What is Largest Contentful Paint (LCP)?
It's the stopwatch on the moment your page looks loaded — how many seconds until the largest element (usually the hero image or headline) actually appears. It's one of Google's three Core Web Vitals, the target is 2.5 seconds, and our audit flagged LCP-delaying patterns — a hero image nobody preloaded, above-fold images set to lazy-load — on 20 of the 28 real sites in our corpus. The pain is universal: you've felt a bad LCP yourself, staring at a half-empty page wondering if the site works.
The audit checks this on every page it crawls — up to 25 pages — and names every offender in the report.
The definition, in plain English
What our engine actually checks
Core Web Vitals metric (LCP) · severity: warning · flagged on 20 of the 28 real audits behind our statistics page
An honest note first: LCP is a metric measured in a real browser as the page paints, and no static audit can time it from outside. What the audit checks instead is the HTML for the known LCP killers — the fix opportunities that move the number: a hero image with no rel=preload hint (the most common LCP pattern in the corpus), the same image fetched without fetchpriority="high", above-fold images marked loading="lazy" (a below-the-fold optimisation turned against the hero), render-blocking CSS and JavaScript in the <head>, and images shipped in heavy formats. Each finding names the element and the specific fix.
In the corpus: the preload hint was missing on 20 of 28 sites — the most common LCP pattern we flag — with the un-prioritised hero (16/28), render-blocking head resources (11/28) and lazy-loaded above-fold images (9/28) stacking on many of the same pages.
Why it matters, honestly sized
LCP is the Core Vital tied most directly to money. Every second of delay before the main content appears, a slice of mobile visitors gives up — bounce-rate studies consistently show the jump inside the 1–3s window, exactly the band most small-business sites sit in. And unlike most performance metrics, LCP is a confirmed Google ranking input via the page-experience signals: at competitive parity, the slower page loses.
The hidden cost is the self-inflicted kind our audit catches: plugins and themes that lazy-load everything "for speed" push the LCP element backwards, and render-blocking sliders and fonts hold the hero hostage. The fix is usually configuration, not redesign — but only if you know which element is the culprit.
The fix, step by step
- Identify your LCP element first — on most sites it's the hero image or the H1. Chrome DevTools → Performance panel records it explicitly, or PageSpeed Insights names it in the diagnostics.
- Preload the LCP image:
<link rel="preload" as="image" href='/hero.webp' fetchpriority="high">in the head tells the browser to start downloading it immediately instead of discovering it after the CSS. For CSS background heroes, preload the URL the stylesheet points at. - Never lazy-load above the fold. Search your templates for
loading="lazy"and remove it from the hero and everything visible without scrolling. Below the fold, keep it — it's the right tool in the right place. - Trim the render-blocking head: inline critical CSS where practical, defer non-essential JavaScript, and self-host fonts with
font-display: swapso text paints without waiting on a third party. - Ship the hero in a modern format — WebP or AVIF, properly sized to its rendered dimensions. A 4MB photograph resized to a 400KB WebP is the single biggest LCP win most sites have available.
What the £7.99 report checks — and what it can't
Everything here that can be checked from outside your site is mechanical, and mechanical is checkable. Full disclosure: some of it isn't, and we say which. The report is the full 21-category audit — what it costs and how it compares to doing it yourself are on their own pages.
The mechanical half
Checked across up to 25 pages per audit, with every offending page named and the exact fix spelled out.
- hero/above-fold images: preload hints and fetchpriority present — the most common LCP delay we flag
- lazy-loading applied above the fold
- render-blocking CSS and JavaScript in the head
- image format and sizing across audited pages
— Not ours to claim
What no report sold from outside your site can do:
- The audit finds the fix opportunities in your HTML — it can't time the metric itself, because real LCP depends on your visitor's device and network, measured as the page paints in a browser. The fix list names every delaying pattern and the exact change; a re-test in PageSpeed Insights confirms the seconds saved.
Fair questions, straight answers
What is a good LCP score?
Under Google's Core Web Vitals thresholds: 2.5 seconds or faster is good, 2.5–4.0 seconds needs improvement, and over 4.0 is poor. The thresholds are measured at the 75th percentile of your real visitors — your fastest quarter doesn't get you off the hook. Practically: aim your fixes at mobile connections, since that's where the slow measurements come from.
How is LCP different from page load time or First Contentful Paint?
First Contentful Paint is the first anything appearing — often just the background or a navigation bar. Full load is every resource fetched, long after the visitor has stopped caring. LCP sits in the middle and measures the thing visitors actually perceive: when the main content — the big image, the headline — is visible. That's why Google chose it as a Core Web Vital: it tracks perceived usefulness, not technical completion.
Can the LCP element be different on different pages?
Yes — it's per page, per viewport, and it can even change on one page as content loads. A blog post's LCP element is usually the featured image; a service page's might be the H1 text; a homepage slider's is whatever slide paints largest first. That's why the fix starts with identifying the element rather than applying one universal optimisation — and why the audit reports the patterns per page rather than site-wide.
Does lazy-loading images actually hurt my LCP?
Above the fold, almost always yes. We flag it on 9 of 28 corpus sites — typically a page-speed plugin that lazy-loaded everything, hero included — though the mistake we flag most often is the simpler one: a hero image nobody preloaded. loading="lazy" tells the browser to defer the download until the image is near the viewport, which is exactly wrong for the hero image the visitor is staring at: the browser deprioritises the one element your LCP depends on. Below the fold, lazy-loading is correct and helps. The fix is one attribute per tag, and it's why our audit checks every audited page for lazy-loaded heroes.
Find out what's holding your hero back.
Enter your URL and pay securely — your report PDF lands in your inbox in ~30 minutes,
with lazy-loaded heroes, missing preloads and render-blocking assets named page by page.