The three metrics in plain English

Core Web Vitals and their “good” thresholds
MetricWhat it measuresIn plain EnglishGood score
LCP — Largest Contentful PaintLoadingHow long until the main content (hero image or headline) appears2.5 seconds or less
INP — Interaction to Next PaintResponsivenessHow quickly the page reacts when someone taps, clicks or types200 milliseconds or less
CLS — Cumulative Layout ShiftVisual stabilityHow much content jumps around while the page loads0.1 or less

Google assesses these at the 75th percentile of real-user visits, separately for mobile and desktop.

Why they matter beyond rankings

Google confirms that Core Web Vitals contribute to its page-experience signals, but that great content can still rank with imperfect scores. The commercial argument is stronger: slow, jumpy pages lose visitors before they read a word, and faster pages tend to convert better. Treat vitals as a quality standard for the visitor, with SEO as a bonus.

How to measure your site (free)

ProcessA simple measurement routine
  1. 1

    PageSpeed Insights

    Enter a URL to see real-user data (if available) and a lab test with suggestions.

  2. 2

    Search Console report

    The Core Web Vitals report groups your URLs into good, needs improvement and poor.

  3. 3

    Test key pages

    Home, top landing pages and your main conversion path — on mobile first.

  4. 4

    Fix, then re-test

    Change one thing at a time; real-user data takes weeks to update.

Understand the difference between lab data (a simulated test, instant, good for debugging) and field data (real visitors over the previous 28 days, what Google uses). A page can look fine in the lab and still struggle in the field on slow phones.

Fixing LCP: make the main content appear sooner

  • Optimise the hero image: correct dimensions, modern formats (WebP/AVIF) and compression; never ship a 4 MB photo to a phone.
  • Do not lazy-load the main image: load it eagerly and consider preloading it.
  • Speed up the server: caching and a CDN reduce time to first byte.
  • Remove render-blocking resources: inline critical CSS, defer non-essential scripts.
  • Avoid heavy fonts and sliders above the fold: they delay the largest element.

Fixing INP: make interactions feel instant

  • Ship less JavaScript: every kilobyte must be downloaded, parsed and run.
  • Break up long tasks: heavy scripts that block the main thread make taps feel laggy.
  • Be selective with third-party scripts: chat widgets, tag managers and trackers all compete for the same thread.
  • Keep event handlers light: do the minimum work in response to a click and defer the rest.

A frequent culprit: too many tools

Sites accumulate analytics tags, heatmaps, chat widgets and A/B testing scripts over the years. Audit them: remove what nobody uses, load the rest after the page is interactive, and test the result.

Fixing CLS: stop the page jumping

ChecklistLayout-shift fixes that usually work
  • Give every image and video explicit width and height (or an aspect ratio)
  • Reserve space for ads, banners and embeds before they load
  • Avoid inserting content above existing content after load
  • Use font-display and similar techniques so text swaps do not shift layout
  • Animate with transforms rather than properties that move surrounding content
  • Test cookie banners and pop-ups, which commonly cause shifts

Build speed in, rather than bolting it on

It is far cheaper to build a fast site than to rescue a slow one. Choices made at the start — a lightweight front end, optimised assets, sensible third-party use, good hosting — decide most of your scores. That is one reason a custom build can outperform a heavily plugin-driven template, as we discuss when comparing custom and off-the-shelf approaches and in our website cost guide.