Core Web Vitals in 2026: What Google's INP Update Means for Your Website

Core Web Vitals are still Google's clearest signal for how a page actually feels to use, and in 2026 the metric that trips up the most UK business websites is INP (Interaction to Next Paint), not loading speed. A site can look fast on first load and still fail Core Web Vitals the moment a visitor clicks a menu, opens an accordion, or adds something to a basket and the page hesitates. Here is exactly what Google measures, why so many WordPress and page-builder sites fail it, and what actually fixes it.

The Three Metrics Google Measures in 2026

Every page gets scored on three thresholds, each split into Good, Needs Improvement, and Poor:

To "pass" Core Web Vitals for a URL, at least 75% of real visits need to fall in the Good band for all three metrics — a single Lighthouse test scoring green in a lab environment does not guarantee a pass in Google's real-world field data.

Why INP Replaced FID (And Why It's Harder to Pass)

Until 2024, Google used First Input Delay (FID), which only measured the delay before the very first interaction on a page. That made it easy to score well even if a site became sluggish after that first click — a common pattern on pages that load a wave of tracking scripts, chat widgets, and carousels shortly after the initial paint. INP measures every interaction throughout the visit and reports the worst representative one, so it catches the "feels fine at first, then grinds" experience that FID missed entirely.

Why WordPress, Wix and Page Builders Often Fail

The pattern shows up repeatedly across audits of plugin-heavy and drag-and-drop sites:

• Generic theme and page-builder JavaScript bundles load code for every possible feature, not just the ones a specific page uses
• Multiple third-party plugins each add their own separate script, and none of them are aware of each other's load order
• Image sliders, pop-ups, and chat widgets often run heavy JavaScript on page load rather than on demand
• Render-blocking CSS from bundled frameworks delays the browser's first paint and inflates LCP

None of this is a deliberate flaw in WordPress or Wix themselves — it is the cost of a platform designed to serve every possible use case with the same underlying code. A site built specifically for one business, with only the interactions that business actually needs, avoids the problem structurally rather than needing constant optimisation plugins to patch around it.

How to Test Your Own Site's Core Web Vitals

• Google Search Console → Core Web Vitals report: real visitor (field) data from the last 28 days, grouped by URL — this is what actually influences rankings
• PageSpeed Insights (pagespeed.web.dev): combines a live Lighthouse lab test with field data where available, and flags the specific elements causing poor LCP or layout shift
• Chrome DevTools → Lighthouse tab: useful for diagnosing exactly which script or image is responsible on a given page, but a single run is a lab simulation, not real-user data

Field data and lab data can disagree — a site can lab-test well on a fast office connection but fail in the field if most real visitors are on mobile data. Always trust the Search Console field report over a one-off Lighthouse score.

What Actually Fixes Core Web Vitals

In practice, the fixes that move the needle are unglamorous but effective: serve properly sized and lazy-loaded images, defer or remove third-party scripts that are not essential above the fold, reserve space for images and embeds so nothing jumps as the page loads, and compile only the CSS a page actually uses instead of loading an entire framework. This is exactly the approach behind every AskMind build — read more on why hand-coded, Tailwind-compiled sites load faster.

Quick FAQ