Your Site Loads in 4.2 Seconds. Google Stopped Caring at 2.5.

Why Core Web Vitals Matter in 2026

Google's Core Web Vitals have been confirmed ranking signals since 2021, but their weight has only increased. In March 2024, Google replaced First Input Delay (FID) with Interaction to Next Paint (INP) -- a stricter, more comprehensive interactivity metric that many sites are failing without realising it.

The impact extends beyond traditional search. AI Overviews and LLM-powered search engines preferentially cite fast-loading pages. When Perplexity or ChatGPT pulls information from the web, pages that load quickly and render cleanly get indexed more reliably. Slow sites get skipped entirely or cited with lower confidence.

We've seen this firsthand: our clients with Lighthouse scores above 90 see measurably better crawl efficiency in Google Search Console and faster inclusion in AI-generated citations. Poor Core Web Vitals don't just hurt rankings -- they reduce your visibility across the entire emerging search landscape.

The Three Core Web Vitals Explained

LCP (Largest Contentful Paint)

Target: Under 2.5 seconds

LCP measures when the largest visible content element finishes rendering -- typically your hero image, headline, or featured video thumbnail. It's what users perceive as "the page loaded."

Main culprits: Unoptimised hero images (serving 2MB PNGs instead of responsive WebP), slow server response time (TTFB above 800ms), render-blocking CSS and fonts, lazy-loaded above-fold images (a counterintuitive mistake).

On SleepDr.com, we reduced LCP from 6.8 seconds to 1.8 seconds primarily by eliminating a render-blocking chain: the WordPress theme loaded a 1.2MB uncompressed hero image after waiting for three blocking CSS files and two Google Fonts requests.

CLS (Cumulative Layout Shift)

Target: Under 0.1

CLS measures visual stability -- how much the page layout shifts unexpectedly while loading. A score of 0 means nothing moves; a score above 0.25 means elements are jumping around significantly.

Main culprits: Images and iframes without explicit dimensions, late-loading web fonts that cause text reflow, dynamically injected content (ads, cookie banners, newsletter popups), CSS that loads after HTML content.

The fix is usually straightforward: always specify width and height attributes on images, use font-display: swap with proper font fallbacks, reserve space for dynamic content with CSS aspect-ratio boxes.

INP (Interaction to Next Paint)

Target: Under 200 milliseconds

INP is the newest Core Web Vital and the hardest to optimise. It measures the latency between a user interaction (click, tap, keypress) and the next visual update. Unlike FID, which only measured input delay, INP tracks the entire interaction lifecycle including processing time and presentation delay.

Main culprits: Heavy JavaScript bundles executing on the main thread, long tasks blocking the event loop, third-party scripts (analytics, chat widgets, ad networks), complex React re-renders from user interactions.

Most WordPress sites fail INP due to jQuery plugins and poorly-optimised theme JavaScript. Even well-built React sites can fail if they're not using server components strategically to reduce client-side hydration.

Our Optimisation Process

1. Audit

We don't rely on a single data source. Lighthouse provides lab data under controlled conditions. PageSpeed Insights adds real-user Chrome User Experience Report (CrUX) data. WebPageTest gives us detailed waterfall analysis showing exactly where time is spent.

The goal isn't a generic list of recommendations -- it's identifying your specific bottlenecks. A site might score 45 on Lighthouse for completely different reasons than another site scoring 45. We pinpoint whether you're blocked by images, fonts, JavaScript, server response, or (usually) a combination.

2. Prioritise

Not all fixes deliver equal impact. A hero image causing a 3-second LCP delay is worth fixing before a 0.01 CLS improvement. We rank optimisations by impact versus effort, giving you a clear roadmap.

Sometimes the honest answer is that your current platform has a performance ceiling. WordPress with WP Rocket, Cloudflare, and optimised images might get you to 70 on mobile -- but the PHP execution model and plugin architecture create inherent limitations. When a client needs 90+, we're upfront about whether optimisation or migration is the faster path.

3. Implement

Our standard toolkit for Next.js projects:

• next/image: Automatic WebP/AVIF conversion, responsive srcsets, lazy loading for below-fold images, priority loading for LCP images
• next/font: Local font hosting with automatic subsetting, proper font-display: swap, eliminating Google Fonts network requests
• Server Components: Above-fold content renders on the server with zero JavaScript hydration, dramatically reducing INP
• Dynamic imports: Code-splitting for non-critical JavaScript (analytics, chat widgets, interactive components below the fold)
• Edge caching via Vercel: Response times under 100ms globally with proper ISR configuration
• Third-party script management: Defer non-essential scripts, use next/script with afterInteractive or lazyOnload strategies

4. Verify

We re-run all audits post-implementation and compare lab data (Lighthouse) with field data (CrUX). Since CrUX updates on a 28-day rolling basis, we monitor Google Search Console's Core Web Vitals report for a full cycle to confirm improvements are reflected in real-user data.

Lab scores improving while field scores stay flat indicates a testing environment issue -- usually third-party scripts that don't load in Lighthouse but do load for real users.

SleepDr Case Study: Lighthouse 35 → 94

SleepDr.com came to us with a WordPress site scoring 35 on Lighthouse mobile. The site was functional but slow -- pages took 6+ seconds to become interactive, and users were bouncing before content loaded.

We migrated to Next.js 15 with Payload CMS 3, Supabase for data, and Vercel for hosting. Here's the exact before and after:

Metric	Before (WordPress)	After (Next.js 15)	Improvement
Lighthouse Score	35	94	+169%
First Contentful Paint	4.2s	1.1s	-74%
Largest Contentful Paint	6.8s	1.8s	-74%
Cumulative Layout Shift	0.28	0.01	-96%
Total Blocking Time	1,200ms	50ms	-96%
Time to First Byte	2.1s	0.3s	-86%

The TTFB improvement (2.1s → 0.3s) came from eliminating PHP execution entirely. WordPress generates pages dynamically on every request unless heavily cached. Next.js with ISR serves pre-rendered HTML from the edge.

The TBT improvement (1,200ms → 50ms) came from removing the WordPress theme's JavaScript bundle, jQuery, and plugin scripts -- replacing them with React Server Components that ship zero JavaScript for above-fold content.

Read the full technical breakdown: SleepDr WordPress to Next.js Migration

What Causes Poor Core Web Vitals (And How We Fix Each)

Unoptimised Images

Problem: Images are often the largest resource on a page. Serving a 2MB PNG when a 150KB WebP would suffice destroys LCP.

Fix: Automatic format conversion (WebP/AVIF), responsive srcsets so mobile devices don't download desktop-sized images, proper priority hints for above-fold images, lazy loading for everything else.

Render-Blocking Fonts

Problem: Google Fonts requests add 200-500ms of blocking time. Custom fonts without fallbacks cause invisible text (FOIT) or layout shift when they load (FOUT).

Fix: Self-hosted fonts with next/font, automatic subsetting to reduce file size, font-display: swap with appropriate fallback stacks.

JavaScript Bloat

Problem: Every third-party script -- analytics, chat widgets, A/B testing, ad networks -- adds to Total Blocking Time and INP. WordPress sites often load 500KB+ of JavaScript before the page is interactive.

Fix: Code-splitting and dynamic imports, server components for non-interactive content, aggressive deferral of non-essential scripts, eliminating unused JavaScript entirely.

Poor Server Response

Problem: TTFB above 600ms makes achieving good LCP nearly impossible. PHP-based CMSs executing on every request, unoptimised database queries, and distant hosting all contribute.

Fix: Edge caching, static generation where possible, ISR for dynamic content. On HostList (25,000 company profiles), changing from force-dynamic to revalidate: 3600 dropped TTFB dramatically by serving cached responses from the edge instead of hitting the database on every request.

Layout Shift from Dynamic Content

Problem: Cookie consent banners, newsletter popups, late-loading ads, and images without dimensions all cause CLS spikes.

Fix: Reserved space with aspect-ratio CSS, proper image dimensions, strategic placement of dynamic elements outside the viewport, banner animations that don't shift content.

Technology We Use

Framework: Next.js App Router with React Server Components for minimal client-side JavaScript

Image Optimisation: next/image with automatic WebP/AVIF, Cloudinary for advanced transformations when needed

Font Optimisation: next/font with automatic subsetting and self-hosting

Hosting: Vercel Edge for sub-100ms TTFB globally, with ISR for dynamic content

Database: Supabase with proper indexing and connection pooling

Analysis: Chrome DevTools Performance panel, Lighthouse, PageSpeed Insights, CrUX dashboard, WebPageTest for waterfall analysis, Google Search Console Core Web Vitals report

For Deluxe Astrology (91,000 programmatic pages), we maintain Lighthouse scores above 90 site-wide using ISR with selective revalidation. Pages regenerate on a schedule without requiring full rebuilds, and edge caching ensures consistent TTFB regardless of traffic spikes.

Pricing

Audit Only: $1,500–$3,000

Comprehensive analysis using Lighthouse, CrUX, PageSpeed Insights, and WebPageTest. Deliverable includes specific bottlenecks identified, prioritised fix list with estimated impact, and recommendations on whether optimisation or migration is the better path.

Audit + Fixes: $3,000–$8,000

Full audit plus implementation of fixes within your existing platform. Realistic for sites that can reach 80+ with optimisation alone. Includes 28-day monitoring to verify CrUX improvements.

Full Migration: $8,000–$25,000

When your platform has a performance ceiling that optimisation can't break through, migration to Next.js is often the only path to 90+. CWV optimisation is built into our Next.js development process -- we don't build slow sites and then optimise them.

Some WordPress sites can reach 75-80 with aggressive caching, image optimisation, and plugin cleanup. But if you need 90+ consistently, the PHP execution model and plugin architecture create limitations that no amount of WP Rocket configuration can overcome. We'll tell you honestly which situation you're in.

For a complete technical SEO picture beyond Core Web Vitals, see our Technical SEO Services.

---

Most agencies can improve your Lighthouse score by 10-20 points with standard optimisations. We've taken sites from 35 to 94, and we maintain 91,000 programmatic pages above 90 on Lighthouse. When Google's Core Web Vitals report becomes a competitive advantage instead of a problem to fix, you'll understand why performance engineering matters more than performance plugins.