Frontend Performance/Core Web Vitals
Lesson 4 of 20 · Episode 4

Largest Contentful Paint (LCP)

Measuring perceived load: when the biggest thing on screen finishes painting, and how to make it happen sooner.

LCPLoadingCritical CSSPreload
Watch on YouTube ↗

Largest Contentful Paint answers the question users care about most on arrival: when does the main thing show up? It's the time until the biggest element in the viewport has painted. Good is ≤ 2.5 s — and getting there means understanding the four separate stages hiding inside that one number.

Definition

What counts as the LCP element

LCP only considers a specific set of element types — the things big enough to be “the main content.” If one of these sits above the fold (in the initial viewport), optimizing it is your job. Inline SVG drawings, gradients, and form controls don't count:

InteractiveDoes this element qualify as LCP?
<img>The classic — hero images, banners.
<image> in SVGAn <image> element inside an SVG.
<video> posterThe poster image (or first frame).
background-imageA block with a CSS url() background.
Text blockA big heading or paragraph of text.
<svg> shapesInline SVG vector drawings don't qualify.
GradientsCSS gradients aren't 'content'.
<input> / formForm controls aren't counted.
Google considers images, SVG <image>, video posters, background images, and text blocks — nothing else.
A moving target

LCP changes during the load

LCP isn't measured once. As the page renders, the browser keeps re-checking which visible element is largest. Early on, a heading might be the LCP; a moment later a hero image finishes loading, becomes the biggest thing, and it becomes the LCP. The final value is whichever element was largest when loading settled.

Note
This is why the LCP is so often a hero image or a big background image — once it paints, it's usually the largest thing on screen, so it sets your score.
The anatomy

The four stages of LCP

There's no single “make LCP fast” switch, because LCP is a sum of four stages. Each has its own cause and its own fix. Toggle the optimizations below and watch the bars collapse toward the 2.5 s line:

InteractiveLCP optimization simulator
TTFB
620ms
Resource load delay
700ms
Resource load time
920ms
Element render delay
520ms
▲ 2.5s
LCP =2.76sNeeds workGood ≤ 2.5s
LCP is the sum of four stages. There's no single fix — flip the optimizations and watch the bars collapse left under the 2.5s line.
TTFB → resource load delay → resource load time → element render delay. Each fix targets exactly one stage.

The four stages, in order:

  1. TTFB — time to the first byte of HTML. Poisons everything after it.
  2. Resource load delay — the gap between HTML arriving and the LCP resource even being requested.
  3. Resource load time — how long the image itself takes to download.
  4. Element render delay — resource is here, but it hasn't painted yet.
What to actually do

The fixes, stage by stage

Stage 2 — cut the resource load delay

The most common LCP win. The browser often discovers the hero image late (because it's referenced from JS or CSS) or gives it a low priority. Put it in the initial HTML and tell the browser it's important:

make the LCP image discoverable + high-priority
<!-- In the initial HTML, not injected by JS -->
<img src="/hero.webp" fetchpriority="high" width="1200" height="630" />

<!-- Or preload it so the scanner finds it immediately -->
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high" />

Stage 3 — cut the resource load time

Most LCP elements are images, so shrink the bytes: serve a right-sized image (not a 1800px file shown at 400px), use a modern format like WebP/AVIF, compress it, and serve it from a CDN close to the user.

Stages 1 & 4 — TTFB and render delay

Keep TTFB low with a CDN, less server work, and no needless redirects. Kill render delay by removing render-blocking CSS/JS and avoiding long tasks (and don't gate the LCP behind a client-side A/B-test script that decides which image to show).

Same origin matters
Hosting the LCP image on a different domain forces a fresh DNS + TCP + TLS handshake before it can even download. Keep critical images on your own origin, or preconnect to the other one early (lesson 13).
Q1Sort each scenario
Match each fix to the LCP stage it speeds up.
Add <link rel=preload> for the hero image
Convert the hero to WebP and compress it
Serve HTML from a CDN near the user
Add fetchpriority="high" to the image
Q2Multiple choice
Which is NOT eligible to be the LCP element?
Q3Multiple choice
Why is there no single “quick fix” for a poor LCP?
Q4Multiple choice
The hero image is requested 700 ms after the HTML arrives. Which stage is the problem?
Key takeaways
  • LCP = time until the largest visible element paints. Good ≤ 2.5 s.
  • Only certain elements qualify: images, SVG <image>, video posters, background images, text.
  • It's re-evaluated during load — the final largest element wins.
  • LCP is a sum of four stages: TTFB, load delay, load time, render delay.
  • Biggest levers: preload + fetchpriority, right-sized modern images, CDN, no render-blocking.
← Previous
3. Introduction to Web Vitals
Next →
5. Cumulative Layout Shift (CLS)