Services

Fix Next.js Core Web Vitals Regressions After Launch or Release

This is for sites that were performing acceptably, then got slower after a release, redesign, dependency change, or new thirdparty load.

Recover lost Core Web Vitals after a release before the site feels slower and key routes start hurting conversion, crawl efficiency, or release confidence.

Short Answer

A Core Web Vitals regression is easy to dismiss when the site still works, but real users feel the change on the routes that affect conversion, search quality, and release confidence. Start by finding which metric moved first, connect it to a real technical change, and fix the causes that field data will actually notice.

Typical Symptoms

  • Largest Contentful Paint, Interaction to Next Paint, or CLS worsened after a release.
  • The site still works functionally, but userperceived speed has clearly degraded.
  • The regression is being discussed in dashboards but the cause is still unclear.

Likely Causes

  • Rendering strategy, assets, or script changes increased work on critical routes.
  • Caching or datafetching behaviour changed in a way that slowed the page shell.
  • Thirdparty additions or component regressions are affecting live traffic.

What I Look at First

  • Identify which routes and which metric moved first in field data, not just in lab traces.
  • Recent rendering, asset, or dependency changes on critical page types.
  • Whether the regression is primarily network, render, or scripting driven.

How I Help Fix This

  • Isolate the regression to the smallest credible set of technical causes.
  • Put the highestmeasurement fixes ahead of speculative cleanup.
  • Remediate the issue and verify that the regression really moved back down.

When to Look at This

  • When the regression is visible in live traffic but the root cause is still unclear.
  • When dashboards show the problem and releases are still piling more change on top.

What Gets Resolved

  • Core Web Vitals regressions are traced to the route, template, asset, script, image, or rendering behaviour causing them.
  • The affected route, template, component, script, or cache path is identified.
  • Field and lab signals are separated from local reproduction noise.
  • Fixes are prioritised by user impact, commercial exposure, and complexity.
  • The team has a verification path before release.

How This Usually Works

  1. Technical Diagnostic

    A focused review of affected routes, templates, deployment behaviour, crawl signals, CMS behaviour, performance bottlenecks, or code paths, followed by a prioritised fix plan the team can take into delivery.

  2. Recovery Sprint

    A short, concentrated engagement for a defined technical SEO, performance, CMS, Vercel, migration, or production issue where the business needs the cause isolated and the first fixes moved quickly.

Talk to me about your performance problem

A short description of the affected route, metric, or recent release is enough. I'll read it and suggest the next step.

Related Case Studies and Project Work

  1. Screenshot of the Selfridges website; part of John Kavanagh's selected project work.

    A New User Experience and Features for Selfridges

    At Selfridges, ecommerce frontend work had to keep perceived speed, release quality, and commercial flows stable under pressure.

    View case study
  2. Screenshot of the John Lewis website; part of John Kavanagh's selected project work.

    The Optimisation and Rebrand of johnlewis.com

    On John Lewis, Core Web Vitals and frontend optimisation work on hightraffic retail pages left little room for regressions in speed, stability, or search visibility.

    View case study
  3. Screenshot of the Nando’s website; part of John Kavanagh's selected project work.

    A Complete Migration and Replatform for Nando’s

    On Nando’s restaurant pages, speed, structured data, and local discovery were handled as one customer path rather than separate scorechasing exercises.

    View case study