What makes a website fast: Core Web Vitals in 2026

A fast website isn't a vibe - Google measures it with three specific numbers (Core Web Vitals), and they're both a confirmed ranking factor and a direct lever on conversion. The good news: most slowness is architectural, so it's fixable by design rather than by endless tweaking. Here's what the three metrics mean, what actually slows sites down, and how to fix it - in plain English.

The three numbers Google measures

Google grades real-user experience on three metrics, each with a documented "good" threshold (web.dev):

• LCP (Largest Contentful Paint) - under 2.5s. How long until the biggest thing on screen (usually the hero image or headline) has loaded. This is your "does it feel fast" metric.
• INP (Interaction to Next Paint) - under 200ms. How quickly the page responds when someone taps or clicks. INP replaced FID as a Core Web Vital in March 2024, and it's stricter.
• CLS (Cumulative Layout Shift) - under 0.1. How much the page jumps around as it loads - the annoying moment a button moves just as you tap it.

Crucially, Google judges these at the 75th percentile of real visits: 75% of your actual users must get a good experience, not your fast laptop on office wifi. Lab scores are a guide; field data is the grade.

Why it matters beyond ranking

Core Web Vitals are a confirmed part of Google's page-experience ranking signals, so they affect where you appear. But the bigger story is conversion: slow pages lose people before they ever convert - each extra second of load time measurably raises bounce and drops conversions. Speed is a feature users feel, not a technical vanity metric.

What actually slows sites down

Most slowness traces to a few architectural causes, not mysterious gremlins:

• Unoptimised images - the number-one LCP killer. A 3MB hero image served at full size to a phone is the single most common cause of a slow site.
• Too much JavaScript - heavy frameworks and third-party scripts (chat widgets, analytics, ad tags) block the main thread and wreck INP.
• No reserved space for media - images and embeds that load without set dimensions shove content around, spiking CLS.
• Render-blocking resources - fonts and stylesheets that must download before anything paints, delaying LCP.
• A slow server with no caching - the page can't be fast if the first byte is slow.

How to fix it - by design, not by luck

The durable fixes are structural, not cosmetic:

1. Render static HTML wherever you can. A pre-rendered page is fast by default - no slow server round-trip on every visit.
2. Optimise and size every image - modern formats, responsive sizes, and lazy-loading below the fold. This alone fixes most LCP problems.
3. Reserve space for anything that loads (width and height on images, min-heights on embeds) to push CLS to near zero.
4. Budget your JavaScript - question every third-party script; each one is a tax on INP.
5. Cache aggressively at the edge so repeat and nearby visitors get near-instant responses.

You don't make a site fast by tweaking it at the end. You make it fast by building it so the slow things never happen - static rendering, optimised images, reserved space.

Our opinion

The two mistakes we see most: measuring the wrong thing, and fixing it too late. Teams celebrate a perfect lab score while real users on mid-range phones get a poor one - watch the field data (the 75th-percentile numbers Google actually uses). And performance retrofitted onto a heavy site is a slog, where built in from the first commit it's nearly free. A fast site and a well-structured, SEO-ready one are the same site: the architecture that makes Google rank you is the architecture that makes users stay.

How Ashvara helps

We build sites that pass Core Web Vitals by construction - static rendering, optimised media, and tight JavaScript - because that's cheaper and more durable than chasing scores later, and we measure on real-user data, not just lab runs. If your site is slow, or you want it built fast from the start, that's our web development practice. Tell us where you stand and we'll give you a straight read.

Thresholds per Core Web Vitals on web.dev (Google). Field (real-user) data at the 75th percentile determines pass or fail.