SSL Checker DMARC Meta Tags Site Speed Broken Links AI Chat Bookings Try ModusOp
Home/Blog/LCP Explained

Largest Contentful Paint (LCP)

The Core Web Vital that measures when your page actually looks loaded to a real user. Get LCP under 2.5 seconds and you're past the most important performance threshold Google measures.

Published 27 April 2026

Largest Contentful Paint (LCP) is the time from when a page starts loading to when its largest visible element finishes rendering. Google uses LCP as one of three Core Web Vitals (alongside CLS and INP) — it's a ranking factor, and pages with poor LCP underperform competitors with the same content but better speed. The "good" threshold is 2.5 seconds or less at the 75th percentile of real visitors.

This guide covers what LCP measures specifically, the four root causes of a slow LCP, and the practical fixes that reliably move it under 2.5 seconds. Most LCP problems come from a small set of recurring patterns that this guide walks through.

What LCP Actually Measures

The browser tracks every "contentful" element rendered to the viewport during page load — text blocks, images, video posters, background images on block-level elements. As each renders, the browser asks: "is this the largest contentful element so far?" Whichever element is largest at the moment user input occurs (or the page completes loading) is the LCP element, and the time of its render is the LCP value.

Practically:

Run any URL through Site Speed Check and the report shows the LCP element, the LCP time, and a score against Google's thresholds.

The Four Causes of Slow LCP

Google's documentation breaks LCP delays into four phases:

  1. Time to First Byte (TTFB) — server takes too long to respond.
  2. Resource load delay — the LCP resource (image, font, etc.) is discovered late by the browser.
  3. Resource load duration — the LCP resource takes a long time to download once it's been discovered.
  4. Element render delay — the browser has the resource but takes time to actually display it (typically due to render-blocking JS or CSS).

Identifying which of the four is your bottleneck is the first step. The fixes for each are different.

Fix 1: Slow Server (TTFB)

If TTFB exceeds 600ms, no amount of front-end optimisation will get LCP under 2.5s. Common causes and fixes:

Fix 2: Late Discovery of LCP Resource

If the LCP element is an image inserted by JavaScript, the browser doesn't know about it until the JS runs — by which time precious milliseconds have passed. The fix is to make the LCP resource discoverable as early as possible:

Fix 3: Resource Takes Too Long to Download

The browser found the LCP resource quickly, but it's just a heavy file. Reduce the size:

Fix 4: Render Delay

The image is downloaded but the browser is busy with other work — typically blocked on JavaScript or CSS — and can't actually paint the LCP element. Fixes:

Common LCP Anti-Patterns

Hero image lazy-loaded

loading="lazy" on the above-the-fold hero. The browser explicitly defers loading. LCP suffers proportionally.

Massive hero images at desktop dimensions, served to mobile

3000-pixel-wide hero serving to a 400-pixel-wide phone. Most of the bytes are wasted on pixels the user can't see.

Web fonts blocking text render

Custom font on the LCP heading. Without font-display: swap, the heading is invisible until the font loads — pushing LCP into the seconds. 

@font-face {
    font-family: 'Custom';
    src: url('custom.woff2') format('woff2');
    font-display: swap; /* show fallback text immediately */
}

Background-image hero hidden behind CSS

Hero is a CSS background-image on a <div>. Browsers don't preload background images during HTML parsing — only after CSS has loaded and computed. Major LCP delay. Switch to a regular <img> element.

SPA with empty initial HTML

The initial HTML is just a <div id="root"></div>. Everything renders client-side. LCP is gated on JavaScript downloading, parsing, executing, and finally painting. Always 2-5 seconds. Use SSR for content pages.

Render-blocking analytics, A/B testing, or chat scripts

A 200KB analytics SDK loaded synchronously in the head blocks parser and rendering. Every script in the head should be deferred or async unless absolutely required for first paint.

The Diagnostic Workflow

  1. Run Site Speed Check on the URL — instant LCP measurement and identification of the LCP element.
  2. Open Chrome DevTools Performance panel, reload the page, and look at the LCP marker. The waterfall shows exactly which resource is the LCP element and what was happening at each phase.
  3. Run Lighthouse for actionable suggestions ranked by potential LCP improvement.
  4. Use PageSpeed Insights to see field data (real users) alongside lab data — field data is what actually counts for Google rankings.
  5. Apply fixes from this guide based on which phase is the bottleneck.
  6. Re-test. Lab data updates immediately; field data takes 28 days to fully update in Google's reports.

The 80/20

For most sites, three changes account for the bulk of LCP improvement:

  1. Add a CDN with full-page caching → fixes TTFB.
  2. Use modern image formats with proper sizing → fixes resource load duration.
  3. Defer non-critical JS → fixes render delay.

Apply those three and most LCP problems resolve. The advanced techniques (preload, fetchpriority, picture elements, font-display) are for the next 5-10% of improvement once the basics are in place.

Site Speed Check measures LCP and the other Core Web Vitals on any URL. Apply fixes, re-test, watch the number drop. The threshold to aim for is 2.5 seconds — once you're under, Google rewards you with the "good" classification, and the rankings follow.

Measure your LCP now

Site Speed Check reports LCP, CLS, INP, and the rest — instant diagnostics on what to fix first.

Run a Speed Test →