Next.js Core Web Vitals Case Study: Oxbridge Passed Mobile + Desktop

Short answer: Core Web Vitals are not a WordPress curse or a Next.js guarantee — they are a build outcome. On Oxbridge Summer Courses (headless WordPress + Next.js), we passed mobile and desktop Core Web Vitals with published PageSpeed numbers you can re-run. This case study walks through the scores, what actually moved LCP / INP / CLS, and when you should fix WordPress first instead of rebuilding.

Still failing on WordPress? Start with how to fix Core Web Vitals in WordPress. Deciding on architecture? See headless WordPress with Next.js and migration cost.

Why this case study exists

Agencies love saying "we care about performance." Buyers need proof: live URLs, field-passing Core Web Vitals, and lab scores you can verify on PageSpeed Insights. Oxbridge is that proof for a content-heavy directory built on headless WordPress + Next.js — not a marketing brochure with three pages.

If you're comparing agencies for a WordPress to Next.js migration, ask for the same format: date, device, LCP, INP, CLS, and a URL you can test yourself. Screenshots alone are not enough.

The project in one paragraph

Oxbridge Summer Courses is a course directory: lots of listing and detail pages, editorial content from WordPress, public site on Next.js. Editors keep wp-admin. Visitors get pre-rendered HTML from the edge. The goal was not a vanity Lighthouse 100 — it was pass Core Web Vitals on mobile and desktop for real users, with SEO still intact after cutover.

A second directory build — Best Summer Courses Guide — passed desktop Core Web Vitals with 98 Performance / 100 SEO in lab (Jul 22, 2026). Same performance discipline, slightly different stack (Next.js + PostgreSQL + WordPress API for the blog).

Published Core Web Vitals results (Oxbridge)

Metrics verified with Google PageSpeed Insights (Lighthouse + CrUX where available). Full screenshots live on services → performance proof.

Mobile — passed (Apr 30, 2026)

LCP: 1.8s (good ≤ 2.5s)
INP: 139ms (good ≤ 200ms)
CLS: 0.01 (good ≤ 0.1)

Desktop — passed (Jul 20, 2026)

LCP: 1.5s
INP: 69ms
CLS: 0.06
Lab: Performance 90 · SEO 100

Studio baseline for comparison: devcritters.com desktop May 18, 2026 — Performance 99, SEO 100, LCP 0.9s, CLS 0.

What was failing before (typical pattern)

We see the same pattern on WordPress marketing and directory sites that later move to Next.js:

LCP red — oversized hero or card images, slow TTFB without cache, LCP image lazy-loaded by accident
INP red — page builder + plugins shipping JS on every template, chat and analytics blocking the main thread
CLS red — images without dimensions, late-loading fonts, ads or banners injected above content

Many of those fix on WordPress without a rebuild — see our WordPress CWV fix guide and why WordPress is slow. Oxbridge went headless because the product needed Next.js routing, component reuse, and a performance ceiling WordPress themes could not hold as the directory grew.

What we did on Next.js to pass Core Web Vitals

1. Rendering strategy for LCP

Listing and detail pages use static generation or ISR so the first HTML already contains the main content. Crawlers and visitors are not waiting on a client-only shell. Marketing routes stay static; only truly dynamic paths use SSR.

2. Images as the LCP budget

next/image with correct sizes, modern formats, and explicit dimensions. The LCP image is never lazy-loaded; it gets priority. Card grids on directory pages are where CLS and LCP both die if you skip dimensions.

3. JavaScript budget for INP

Ship less client JS. Defer non-critical widgets. Avoid loading admin-style or builder assets on the public site (common when teams keep WordPress theme leftovers). Filters and interactive bits stay scoped to the components that need them.

4. Fonts and layout for CLS

next/font (or equivalent) so text does not reflow after paint. Reserve space for media and UI chrome. No surprise banners above the fold after hydration.

5. WordPress as CMS only

Content and SEO fields come from the WordPress API; the public HTML — including metadata — is owned by Next.js. That split is also how we protect SEO on headless builds. Full playbook: headless WordPress SEO.

Lab vs field: what actually counts

PageSpeed lab scores help you debug. Search Console → Core Web Vitals (field / CrUX) is what Google uses for page experience when it has enough data. Oxbridge's win is the pass on mobile and desktop field thresholds — not a single Lighthouse screenshot.

If your lab looks fine and GSC still says "Failed," fix the URLs with real traffic first. If lab is red, fix that before you argue with field data.

When to fix WordPress vs rebuild on Next.js

Stay on WordPress and fix CWV when:

One metric is failing and the cause is obvious (hero image, no cache, one heavy plugin)
Mobile scores are in the 60–80s and improve after a proper audit
Budget does not support two systems (CMS + Next.js front end)

Move to headless WordPress + Next.js when:

Scores stay poor after caching, image, and plugin discipline
You need app-like directory, filters, or multi-market routing
Editors must keep WordPress, but the theme cannot hit CWV at scale

Migration is not free. Typical mid-market ranges sit in our cost guide ($10k–$50k / 6–16 weeks for many marketing sites). Use the SEO migration checklist so rankings do not take the hit while you chase LCP.

How to verify our numbers yourself

Open pagespeed.web.dev
Run the live Oxbridge URL from the case study (mobile + desktop)
Compare LCP / INP / CLS to the thresholds above
Cross-check screenshots on performance proof

Any agency pitching "we do Core Web Vitals" should give you the same homework.

FAQ: Next.js Core Web Vitals

Can Next.js pass Core Web Vitals?

Yes — Oxbridge passed mobile and desktop. Next.js makes it easier via static HTML, image optimisation, and controlled JS, but a bloated Next.js app can still fail. Implementation decides the outcome.

Is Next.js better than WordPress for Core Web Vitals?

Usually a higher ceiling and easier to sustain at scale. WordPress can pass with lean themes and caching. Choose rebuild when WordPress fixes stop moving the needle. See WordPress vs Next.js SEO.

How do I fix Core Web Vitals assessment failed?

Identify which metric fails in Search Console, fix that URL set first (images → cache → JS → CLS), re-test. On WordPress follow this guide. On Next.js: SSG/ISR for content pages, next/image, font strategy, JS budget.

Who can improve Core Web Vitals without a full site rebuild?

Often your current team or a performance-focused agency — if the issue is configuration. Rebuild when architecture blocks sustainable scores. We do both: WordPress CWV fixes and headless Next.js when needed.

Do Core Web Vitals affect SEO rankings?

They are part of page experience. Content and relevance still dominate, but failing CWV on money pages hurts mobile UX and can cost rankings/CTR against faster competitors.

What LCP, INP, and CLS targets should I use?

Good band: LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 at the 75th percentile of real users. Lab scores are diagnostic; field data in GSC is the SEO scoreboard.

How long does a Next.js performance rebuild take?

Depends on scope. A focused front-end rebuild for a marketing or directory site often lands in the same window as a headless migration — weeks, not a weekend. Cost and timeline: migration cost guide.

Related resources

Bottom line

Passing Core Web Vitals on Next.js is a deliberate engineering outcome — rendering, images, JS, fonts — not a framework checkbox. Oxbridge proves a headless WordPress + Next.js directory can pass mobile and desktop with numbers you can re-run. Fix WordPress first when the problem is configuration; rebuild when the theme and plugin stack cannot hold the line.

We publish performance proof and ship SEO-safe headless migrations for businesses worldwide. Migration service · Services · Performance proof · Book a consultation.