Blog

Core Web Vitals, explained without the jargon

What Google's Core Web Vitals actually measure, why your site feels slow, and the fixes that move them, in plain English.

Last updated: 13 October 2026

Google grades every page on “page experience,” and at the centre of that are three numbers called Core Web Vitals. They sound technical, but each one maps to something a real visitor feels. Here is what they mean, and what actually moves them.

LCP: how long until the page shows up

Largest Contentful Paint measures how long it takes for the biggest thing on screen, usually your hero image or headline, to appear. It is the closest number to “when did the page load?” as a person would judge it. Google considers 2.5 seconds or less good.

LCP suffers when the server is slow to respond, when CSS and JavaScript block the first paint, when the hero image is large and uncompressed, or when nothing is cached close to the visitor.

INP: how quickly the page responds

Interaction to Next Paint measures the delay between a tap or click and the page visibly reacting. It replaced the older First Input Delay metric in 2024 and is a better proxy for “does this page feel sluggish when I use it?” Under 200 milliseconds is good.

INP is almost always a JavaScript problem: too much script running on the main thread, so the browser is busy when the visitor tries to interact.

CLS: how much the page jumps around

Cumulative Layout Shift measures how much content moves while the page loads, the annoying jump that makes you tap the wrong button. A score of 0.1 or less is good. The usual culprits are images and ads without set dimensions, and fonts that load late and reflow the text.

Why sites feel slow

Most slow sites share the same roots: too much JavaScript, pages rendered fresh on every request instead of served as ready-made HTML, and assets delivered from one origin far from the visitor. Platforms and plugins make this easy to accumulate without noticing.

What actually helps

  • Pre-render pages to static HTML so the browser receives finished markup instead of building it on the fly. This helps LCP directly.
  • Serve from the edge, a global network that keeps a copy close to every visitor, so the first byte arrives quickly wherever they are.
  • Defer non-critical scripts until after the page is interactive, which is the single biggest lever on INP.
  • Set dimensions on images and reserve space for anything that loads late, which keeps CLS near zero.

Where Mirra fits

This is the approach Mirra takes for you. It captures your existing site, on almost any platform, and serves a pre-rendered, edge-cached copy on your own domain, with scripts deferred through simple speed presets. That is why it tends to move LCP and CLS without a rebuild or migration. If you are on a specific platform, see how it works for Shopify, Webflow, or WordPress.

Every site is different, so the honest answer is to measure your own. You can run a free single-page speed test and compare the numbers side by side before changing anything.