TTFB, CLS, INP: The Metrics That Decide Your Ranking

Google keeps a stopwatch on your website. It’s not a secret, and it’s not a rumour — it’s the Core Web Vitals, a set of three measurements that Google uses as ranking signals, alongside the classic speed metrics. If you’ve been hearing about them and nodding along without really understanding them, this is the plain-language version.

The three measurements

There are three Core Web Vitals, each answering a different question about how your site feels:

LCP — Largest Contentful Paint. How long until the main content of the page appears. The hero image, the big heading, the first thing the visitor actually reads. Goal: under 2.5 seconds.
CLS — Cumulative Layout Shift. How much the page jumps while it loads. You know this one — you’re about to click a button and the layout shifts, and you click the wrong thing. Goal: under 0.1.
INP — Interaction to Next Paint. How quickly the page responds when the visitor clicks, taps, or types. This is the newest one, and it matters more than people realize.

Why INP matters now

INP replaced the old FID (First Input Delay) in 2024. The difference is subtle but important: FID only measured the first interaction; INP measures every interaction across the visit and reports the worst one. A site that feels snappy at first but janks on the fifth click will fail INP.

Why does that matter for a business owner? Because a slow, janky site isn’t just a minor annoyance. It’s the difference between a visitor completing a contact form and giving up. Interactions are where your visitors become customers — and INP measures exactly that moment.

The ones that aren’t “official” but still matter

Alongside the three Core Web Vitals, two older metrics still shape how fast a site feels and ranks:

TTFB — Time To First Byte. How long the server takes to start responding. If your TTFB is slow, everything after it is slow too, because the browser can’t even begin rendering until the first bytes arrive.
FCP — First Contentful Paint. When the first bit of content — a heading, an image, a paragraph — actually appears on screen.

What actually makes these numbers good

Here’s the part I tell every client, because it’s the part that saves them the most money: the fastest way to improve all of these is to send less and do less.

Less JavaScript. The single biggest lever. Every script the browser has to download, parse, and execute delays LCP and INP. This is why I build with a “zero-JS by default” philosophy — the browser rests, and the metrics improve.
Less render-blocking CSS. Split and load only what each page needs.
Faster servers and edge delivery. Serving static files from a content delivery network brings TTFB down dramatically.
Fixed-size media. An image without declared dimensions is a CLS time bomb — the layout shifts when it loads. Declaring sizes (or using modern formats like AVIF/WebP with intrinsic dimensions) stops the jumping.

The honest take

These metrics are not a game you can win by tweaking one slider. They’re the outcome of architectural decisions made early — what framework you choose, whether you ship JavaScript you don’t need, whether your hosting is fast. That’s why I treat performance as a design constraint from the first sketch, not a last-minute polish.

A 100/100 Lighthouse score isn’t a trophy I chase after the build is done. It’s the result of building the site correctly in the first place. And when the metrics are good, the ranking, the conversions, and the user experience all follow.