Launch in Days, Not Weeks
Professional one-page website. Only a few slots left this month
Search Console keeps flagging your site as needing improvement, and nobody on your team can translate “INP 312ms” into a fix. Core Web Vitals are a ranking signal, but most explanations are written for engineers. This is the version for the person whose job depends on the numbers going green.
What Core Web Vitals Actually Measure in 2026
Google currently tracks three signals under Core Web Vitals. All three measure a different aspect of how real users experience your page.
LCP (Largest Contentful Paint) measures how long it takes for the biggest visible element on screen to load. Usually a hero image or large headline. This is the “does the page feel fast?” signal.
INP (Interaction to Next Paint) replaced FID in March 2024. It measures how quickly your page responds when a user clicks, taps, or types. If your navigation is slow to react, or a dropdown takes half a second to open, that’s an INP problem.
CLS (Cumulative Layout Shift) measures how much the page jumps around as it loads. That moment when you’re about to click a button and the layout shifts, sending your click somewhere else: that’s CLS.
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP | under 2.5s | 2.5s to 4.0s | over 4.0s |
| INP | under 200ms | 200ms to 500ms | over 500ms |
| CLS | under 0.1 | 0.1 to 0.25 | over 0.25 |
How Google Uses Core Web Vitals for Rankings
Core Web Vitals are a tiebreaker, not a primary signal. Relevance, authority, and content quality decide the shortlist. Page experience decides the order within it.
There’s an important distinction between the two data sources Google uses. PageSpeed Insights runs a lab test on your page right now, under controlled conditions. Search Console shows CrUX data: real measurements from real Chrome users over the past 28 days. A page can score 90 on PageSpeed Insights and still fail Core Web Vitals in Search Console, because real users are on slower devices and slower connections.
For UK B2B sites, where mobile traffic is lower than consumer averages (typically 40 to 50 percent rather than 60 to 70), desktop scores carry more weight in CrUX. That said, Google’s mobile-first indexing means mobile performance still determines your core index position.
The Five Fixes That Move LCP the Most
LCP failures are almost always caused by a small set of problems. Fix these in priority order.
1. Hero image format and size. A 1.4MB JPEG hero image is the single most common LCP killer on UK B2B sites. Serving it in AVIF or WebP at the right dimensions typically cuts load time by 60 to 70 percent. One client site dropped LCP from 4.2 seconds to 1.8 seconds through format change alone.
2. Server response time (TTFB). If your server takes more than 600ms to respond, everything else is delayed. Static sites deployed to a global CDN like Cloudflare Pages solve this structurally. Server-rendered sites need caching or infrastructure upgrades.
3. Render-blocking resources. Stylesheets and scripts that block the browser from painting anything. Defer non-critical JavaScript. Load fonts with font-display: swap.
4. Preload hints for the LCP element. Adding <link rel="preload"> for your hero image tells the browser to fetch it immediately rather than waiting to discover it while parsing HTML.
5. Font display swap. Web fonts that block rendering hold back LCP. Setting font-display: swap lets text render in a fallback font while the custom font loads.
Fixing INP on Interaction-Heavy B2B Sites
INP failures are harder to diagnose than LCP because they depend on what users actually do on your page.
The most common causes on B2B marketing sites are third-party scripts (live chat, analytics, heat mapping tools) that run JavaScript on the main thread. When a user clicks a navigation item while those scripts are running, the response is delayed.
React-heavy pages have a specific problem: hydration. When a server-rendered React page loads, the browser has to re-run the entire JavaScript bundle to attach event listeners. Until hydration completes, interactions are slow or unresponsive. This is one reason Astro sites score better on INP: Astro ships no JavaScript unless you explicitly add it, so there’s no hydration cost.
Practical fixes: audit your third-party scripts and remove anything you don’t actively use. Break up long tasks (anything over 50ms) into smaller chunks using scheduler.yield(). Debounce event handlers on scroll and resize events.
CLS Culprits on Marketing Sites
Layout shift is almost always preventable. The common causes on B2B sites:
Images without dimensions. If your HTML doesn’t declare width and height attributes on images, the browser doesn’t know how much space to reserve. When the image loads, content shifts. Fix: always include dimensions, even on responsive images.
Web fonts. Late-loading custom fonts cause text to reflow when they arrive. Use font-display: swap and preload your primary font files.
Cookie consent banners. Banners that inject above the fold after page load push all content down. Implement them with reserved space, or load them outside the document flow.
Embedded videos and iframes. Third-party embeds that load late with unknown dimensions. Use aspect-ratio containers to reserve the space before the embed loads.
Ads and dynamic content. Any content that loads after initial render without reserved space. Always specify minimum heights for ad slots.
A Weekly Monitoring Routine
You don’t need a full analytics stack. You need three checks.
Search Console (monthly): Check the Core Web Vitals report under Experience. Look for URLs moving from green to amber, and identify which URLs have the most poor visits (volume matters, not just percentage).
PageSpeed Insights (weekly for key pages): Test your homepage, top landing pages, and any page you’re running paid traffic to. Look for regressions after deploys.
CrUX Dashboard (quarterly): The CrUX dashboard in Looker Studio shows 28-day rolling field data for your origin. Use this to track whether your improvements are showing up in real-world data.
When to escalate: if your LCP degrades by more than 500ms on a key page after a deploy, that’s a priority fix. If INP creeps above 300ms, audit for new third-party scripts. If CLS spikes above 0.1, look for recent content or layout changes above the fold.
Getting Core Web Vitals right is mostly a build discipline rather than an ongoing task. Sites built on static architectures with minimal JavaScript start with a structural advantage. If your site is built on a platform where you can’t control TTFB, script loading, or image formats, you’re optimising around a ceiling rather than through it.
Every site we build at Fernside Studio is optimised for Core Web Vitals from the foundation up: Astro for near-zero JavaScript, Cloudflare Pages for sub-50ms TTFB from UK edges, and automated image conversion to AVIF and WebP.
If your Search Console is showing red, or you want to understand what’s holding your scores back before paying for a rebuild, book a 30 minute audit call. We’ll look at your actual CrUX data and give you a prioritised fix list, not a generic report.