Is your website slow? What Core Web Vitals are and how they cost you customers

When someone opens your site on their phone and stares at a blank screen for a few seconds, they most likely hit "back" and go to a competitor. You'll never see that customer in your analytics. That's why speed isn't a technical nicety; it's revenue.

Google measures on-page experience with three indicators called Core Web Vitals. You can check yours for free with our scanner, but first, here's what they mean.

The three Core Web Vitals

Metric	What it measures	Good	Poor
LCP (Largest Contentful Paint)	how long until the main element (hero image or headline) appears	under 2.5 s	over 4 s
INP (Interaction to Next Paint)	how quickly the page reacts when you tap a button	under 200 ms	over 500 ms
CLS (Cumulative Layout Shift)	how much content jumps around while loading	under 0.1	over 0.25

Google looks at your real visitors' data at the 75th percentile: at least three out of four visits need to be "good" for the page to pass.

LCP: the first impression

LCP is the most visible one. If the hero image weighs 3 MB, a phone on a typical mobile connection takes a long time to download it. Usual causes:

• unoptimized images (huge JPEGs or PNGs instead of WebP or AVIF at the right size);
• hero sliders that load five images to show one;
• a slow server that takes ages to respond before loading even starts;
• fonts and CSS files that block rendering.

INP: the "it feels sluggish" metric

INP replaced the older FID metric in 2024. It measures how long a visitor waits after a click, tap or key press. When a page loads lots of JavaScript (chat widgets, sliders, page builders, dozens of tracking scripts), the phone is busy and responds late.

CLS: the button that runs away

Ever tried to tap a link only for the page to jump because a banner loaded? That's CLS. It happens when images have no declared dimensions, when ads or cookie banners push content down, or when fonts swap after loading.

Why so many sites are slow

Most business websites are built on "all-in-one" themes with visual page builders. They're convenient, but they load code for every possible feature on every page, used or not. Add a slider, a form plugin, a cookie plugin, a chat widget and a few analytics scripts, and you easily reach hundreds of kilobytes of JavaScript the phone has to process.

When we audited our own old site, built on such a theme, its mobile Lighthouse score was 59 with a 5.5-second LCP. That's one of the reasons we rebuilt it from scratch.

What to fix, in order of impact

1. Images. Convert them to WebP or AVIF, resize them to their displayed size and lazy-load everything below the first screen. That alone can halve page weight.
2. Hero sliders and animations. Replace them with one well-chosen static image and a clear message. It usually converts better anyway.
3. Unused plugins and scripts. Every plugin adds code. Keep only what you actually use.
4. Caching and a CDN. Pages should be served pre-built from a server close to the visitor.
5. Hosting. If the server takes more than 600 ms to respond, no front-end optimization fully makes up for it.
6. Image dimensions and reserved space for banners, to eliminate layout shifts.

When a rebuild makes sense

If your mobile score stays below 50 after optimizing, the problem is usually architecture: the theme, the page builder or the pile of plugins. A modern statically generated site (like the ones we build with Next.js) starts above 90 without special effort, because the page arrives in the browser already built, with very little JavaScript.

Want to know where you stand? Scan your website for free: in 30 seconds you get your mobile Lighthouse score, Core Web Vitals and a concrete list of issues.