Speed matters: TTFB, FCP, LCP and what they actually mean for your site

Google uses a set of performance metrics to measure how fast a page feels to real users. They show up in Search Console, Lighthouse, and PageSpeed Insights - and they have a direct relationship with both rankings and conversion rates. Here’s what each one measures and what actually matters.

The three Core Web Vitals

Google’s Core Web Vitals are three metrics that measure loading, interactivity, and visual stability. Of the three, loading is the one most sites struggle with.

Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible element on the page to render - usually a hero image, a large heading, or a video poster. It’s the metric that best correlates with how fast a page feels to a user, because it captures when the main content appears.

Good: under 2.5 seconds
Needs improvement: 2.5 – 4 seconds
Poor: above 4 seconds

The most common LCP culprits are unoptimised hero images (large file size, no loading="eager" + fetchpriority="high"), render-blocking CSS and JavaScript, and slow server response times.

Cumulative Layout Shift (CLS)

CLS measures visual stability - whether elements jump around as the page loads. A high CLS score means buttons move before you click them, text shifts under your cursor, or images pop in and push content down. It’s irritating and it drives people away.

Good: under 0.1
Needs improvement: 0.1 – 0.25
Poor: above 0.25

The most common cause is images and embeds without declared dimensions - the browser doesn’t reserve space for them until they load.

Interaction to Next Paint (INP)

INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. Where FID measured only the delay on the first interaction, INP measures the latency of all interactions across the page lifetime. Slow JavaScript is almost always the cause of a poor INP score.

Good: under 200ms
Needs improvement: 200 – 500ms
Poor: above 500ms

The supporting metrics

Time to First Byte (TTFB)

TTFB measures how long it takes for the browser to receive the first byte of the server’s response. It is not a Core Web Vital but it directly affects all the metrics that are.

A slow TTFB (above 800ms) usually points to: slow hosting or an overloaded shared server, no server-side caching, a slow database query on page load, or a distant server with no CDN.

A fast TTFB (under 200ms) almost always requires either a caching layer, a CDN, or both.

Good: under 800ms
Needs improvement: 800ms – 1800ms
Poor: above 1800ms

First Contentful Paint (FCP)

FCP measures when the browser renders the first piece of visible content - any text, image, or canvas element. It is a user perception metric: it tells you when someone first sees something on the screen, rather than a white page.

Good: under 1.8 seconds
Needs improvement: 1.8 – 3 seconds
Poor: above 3 seconds

FCP is heavily influenced by render-blocking resources - CSS and JavaScript files that pause rendering while they load.

How Google measures these in practice

Google’s CrUX (Chrome User Experience Report) collects real-world performance data from Chrome users who have opted in to sharing it. A URL needs to pass at the 75th percentile - meaning 75% of real visits to that URL must meet the “Good” threshold. One fast visit in ten does not count.

This is why lab tools like Lighthouse can show green scores while your Search Console still flags Core Web Vitals failures. Lab tests run once, in ideal conditions. CrUX captures the full range of devices, connections, and locations.

What actually moves these numbers

In rough priority order:

1. Server response time (TTFB) - Fix this first. Switch to proper managed hosting, add a full-page caching layer (Redis, server-level caching, or a CDN like Cloudflare), and move to a PHP version no older than two versions behind current.
2. Image optimisation - Convert to WebP or AVIF, size images for the slot they fill (not full-resolution), and set loading="lazy" on everything below the fold. Set fetchpriority="high" on the LCP image.
3. Eliminate render-blocking resources - Defer non-critical JavaScript with defer or async. Inline critical CSS and load the rest asynchronously.
4. Remove bloated plugins - Every plugin that adds a CSS file and a JavaScript file to every page load costs you something. Audit them.
5. Use a CDN - A CDN serves static assets (images, CSS, JS) from edge locations close to the visitor. Cloudflare’s free tier is often enough to make a measurable difference.

Scores not moving despite the usual tweaks? WordPress speed optimisation is one of the things we do most often - we audit first, then fix what’s actually holding your site back.