CORE WEB VITALS IN 2026

Performance work in 2026 falls into two camps. The reactive camp tunes individual pages once they fall below a threshold. The structural camp builds performance into the framework choice, the design system, the deployment pipeline, and the content discipline so that performance is the default outcome of the work, not an optimisation pass that happens later. Every site I have seen succeed long-term is in the structural camp.

This guide is the structural view. Concrete numbers from sites I have shipped, the actual checks I run, the costliest mistakes I have made, and the parts of the conventional advice that turned out to be wrong in practice. Field data from CrUX always wins over lab data from PageSpeed Insights, so most numbers below come from real users at the 75th percentile.

LCP (Largest Contentful Paint)

The time until the largest above-the-fold element renders. Target: under 2.5 seconds at the 75th percentile. The single most-cited Core Web Vital, often the easiest to fix once you identify the LCP element correctly. Most sites have an image or a hero text block as the LCP element; the fix is almost always preloading the image, sizing it correctly, and ensuring no JavaScript blocks the render.

CLS (Cumulative Layout Shift)

How much the page content shifts unexpectedly during load. Target: under 0.1. The metric most often broken by lazy-loaded images without explicit width and height, by ads injected after first render, or by web fonts swapping with different metrics than the fallback. Solvable in most cases by being disciplined about explicit dimensions on every visual element above the fold.

INP (Interaction to Next Paint)

The slowest interaction time experienced during the page lifetime. Target: under 200ms. Replaced FID in March 2024. The hardest CWV metric to game, because it surfaces real user friction with JavaScript on long-running tasks. Sites with heavy client JavaScript almost always struggle here. The fix is shipping less JavaScript, breaking long tasks into smaller chunks, and using requestIdleCallback for non-urgent work.

TTFB (Time to First Byte)

Server response time before any rendering can start. Target: under 600ms. Not officially a Core Web Vital but it caps every other metric. Static-rendered sites on a CDN hit 50 to 150ms typically. WordPress on shared hosting hits 800ms to 2.5s on cold cache. The hosting decision is the largest TTFB lever.

Lab data tells you what one machine in one location measured at one moment under controlled conditions. Field data tells you what real users experienced at scale. The two diverge significantly on most sites, and field data is what Google uses for ranking signals. Optimise for field data first, lab data second.

Where to read field data

Search Console > Core Web Vitals report. CrUX dataset on BigQuery if you want raw event-level data. PageSpeed Insights > Field Data section (when sufficient real user data exists for the URL). Calibre, SpeedCurve, and Treo provide enriched dashboards on top of CrUX for paid users. RUM tooling (real user monitoring) like Vercel Analytics or Cloudflare Web Analytics adds further granularity.

Where to read lab data

PageSpeed Insights > Lab Data section. Lighthouse in Chrome DevTools. WebPageTest for granular waterfall analysis. Useful for diagnosing the why behind a field metric regression, not for measuring it.

The diagnostic flow I run

Field metric regression in Search Console. Identify the affected URL pattern. Run lab tests via WebPageTest in three locations to reproduce. Inspect the waterfall to find the offending request. Patch. Wait 28 days for CrUX field data to update. Confirm fix.

Real LCP numbers I have seen at the 75th percentile of field data on the platforms I ship most:

Static-rendered Astro on Netlify or Cloudflare Pages

LCP 0.6 to 1.0 seconds typical. Lighthouse 100 across all four metrics is the default outcome. Initial JavaScript under 30KB. Hardest tier to beat for content sites.

Static-rendered Next.js (App Router with RSC, SSG mode)

LCP 1.0 to 1.5 seconds. Initial JavaScript 80 to 150KB depending on how many client components ship. Lighthouse 90+ achievable but takes deliberate optimisation.

ISR or SSR Next.js

LCP 1.5 to 2.5 seconds depending on cache hit rate and origin response time. Cold cache misses are 3 to 5 seconds. Excellent technology with a real cost curve and a real performance variance.

WordPress on Kinsta or WP Engine plus Cloudflare

LCP 1.8 to 2.8 seconds typical. Achievable to clear CWV thresholds with discipline. Sites I run on this stack pass CWV at 75th percentile consistently after the optimisation pass.

WordPress on shared hosting

LCP 3.5 seconds or worse. Avoid for any site where performance is part of the brief.

Images are the LCP element on roughly 70% of marketing pages. Image discipline is the single highest-leverage performance lever I know.

Format and compression

WebP at quality 82 hits the sweet spot for visual quality versus file size. AVIF is smaller but encoding is slower and browser support has subtle gaps. Skip JPEG and PNG for any image that is not source-of-truth originals. WebP at q=82 typically produces files 70 to 90% smaller than the source PNG with no perceptual loss.

Resize to actual rendered dimensions

A 4K JPEG rendered at 1200 pixels wide is a 90% bandwidth waste. Always resize to the largest dimension at which the image will render, plus a 2x or 3x version for high-density displays. Sharp does this in roughly five lines of code in any Node.js build pipeline.

FAL hero pipeline

We generate hero images via FAL flux-pro/v1.1-ultra and Imagen 4 directly from the auto-blog pipeline. The generated images are 600KB to 1.5MB JPEGs at 1200x675. Uploading raw to Supabase Storage means every page ships ~1MB of hero alone. We pipe through sharp(buf).resize({width:1600, fit:"inside"}).webp({quality:82}).toBuffer() before storage upload. Cuts file size 90% with no perceptual loss. We saw a 50MB site-wide saving across 53 hero images on a single Seahawk site after applying this pipeline. Use cacheControl: 31536000 on the storage upload too.

Explicit width and height on every img

Browsers reserve space before the image loads only if width and height are present in the HTML. Without them, layout shifts as images load and CLS rises. Astro and Next.js Image components handle this automatically; raw img tags need it manually.

LCP image preload

The above-the-fold hero image should be preloaded with link rel="preload" as="image" in the head. Saves 100 to 400ms typically. The single highest-impact one-line change available on most marketing sites.

JavaScript is the largest performance liability on most modern sites. The budget I work to in 2026:

Initial JavaScript under 100KB on content sites

Below 100KB the framework, the site, and any analytics or marketing pixels combined still parse and execute fast enough on a mid-tier mobile device. Above 100KB the cost shows up in INP and TTI, often invisibly to the desktop developer testing on a fast laptop.

Defer everything that is not above-the-fold

Analytics, social pixels, chat widgets, A/B testing scripts. None of these need to block first paint. Use defer attribute or load on user interaction. The CWV improvement is often dramatic, the engagement loss is usually zero.

Avoid heavy client components above the fold

A hero carousel that requires React + framer-motion + 30KB of supporting code to render the first frame is a performance liability. Render the first slide as static HTML and hydrate the carousel only when the user is about to interact.

Audit third-party scripts quarterly

Marketing scripts compound silently. A site with one analytics tag in 2020 has eight scripts in 2026 if nobody audits. Run a quarterly check via Lighthouse or webpagetest, identify what is still earning its place, and remove anything that is not.

Critical CSS inlined, rest deferred

The CSS needed to render above-the-fold should be inlined in the head. The rest can load asynchronously. Astro and Next.js handle this automatically with their CSS scoping; manual sites need a critical-css extraction step in the build pipeline.

Self-host fonts and use font-display: swap

Web fonts loaded from Google Fonts add 100 to 300ms typically. Self-hosting from the same origin as the site eliminates the DNS lookup. font-display: swap renders fallback text immediately while the web font loads, eliminating FOIT (flash of invisible text). Variable fonts where supported deliver multiple weights from a single file.

Subset fonts to the languages you actually serve

A Latin font subset is 30 to 60KB. The full multi-language file is often 250KB+. Subsetting is a one-line change in most build pipelines and saves significant bandwidth on every page load.

The hosting and edge layer matters more than most teams give it credit for. The non-obvious advice:

Cloudflare in front of the origin always

Whether your origin is Vercel, Netlify, AWS, or a managed WordPress host, putting Cloudflare in front improves global latency, absorbs bot traffic, and adds caching that the origin would otherwise serve. Free tier is sufficient for most sites; paid tiers add observability and security features.

Static rendering is the largest performance lever

Pre-rendered HTML served from CDN edge nodes hits sub-100ms TTFB globally. No origin hop, no database query, no template render. If your content does not strictly need to be dynamic, render it statically.

Edge functions for the dynamic surface

When you do need dynamic behaviour (auth, personalisation, A/B), edge functions on Cloudflare Workers or Vercel Edge Functions execute closer to the user than origin servers. Latency drops dramatically without the operational burden of running infrastructure.

Watch ISR billing on Vercel at scale

Incremental Static Regeneration is excellent technology with a real cost curve. We hit a multi-million-event ISR billing month on Deluxe Astrology in March 2026. The fix was an explicit "two production merges per week" rule, since each merge fires roughly six million ISR write events at 91,000-page scale. Plan for this if you are running ISR on a large site.

Before declaring any new site or template launch-ready, I run this checklist. It is short on purpose. Long checklists never get used.

1. Hero image is preloaded with link rel preload as image. 2. Above-the-fold images have explicit width and height. 3. WebP format, quality 82, resized to render dimensions. 4. Critical CSS inlined, rest deferred. 5. Web fonts self-hosted with font-display: swap. 6. Initial JavaScript under 100KB. 7. Analytics and marketing scripts deferred. 8. CSS Grid columns use minmax(0, 1fr) not 1fr to prevent overflow on long content. 9. Static rendering wherever the content allows. 10. Cloudflare in front of origin. 11. Field data measured weekly via Search Console. 12. Build-time SEO linter fails the build on regressions.

Sites that ship with all twelve in place rarely have CWV issues. Sites that skip three or four of them eventually fail at the 75th percentile and the team scrambles to fix it after Google has already noticed.

Not every site needs to hit Lighthouse 100. The honest framing for the question "how much performance work is enough":

Sites under 10,000 monthly visitors with no commercial dependence on search rankings: hit the CWV thresholds at 75th percentile and stop. Further optimisation produces diminishing returns. Spend the time on content or product instead.

Sites with paid traffic where conversion rate matters: every 100ms of LCP costs roughly 1 to 4% of conversions on average benchmarks. Optimisation past CWV thresholds typically pays back at scale. Run the math, prioritise accordingly.

Sites where Lighthouse score is part of the brand brief: hit Lighthouse 100 and treat any regression as a bug. The optimisation work compounds because the team will not let regressions ship.

Sites with editorial teams who will not maintain optimisation discipline: pick the framework that delivers performance by default (Astro, statically-rendered Next.js, headless WordPress with managed hosting) and accept the constraint. Manual performance tuning that the team cannot maintain is worth less than a slightly less optimal default that survives.

Performance in 2026 is a structural posture: framework choice, hosting choice, image pipeline discipline, JavaScript budget, CSS and font discipline, edge caching, and the CWV checklist applied at every launch. Sites that build these in early get a performance floor that compounds. Sites that bolt them on later spend more for less.

You do not need every line of this guide on day one. You do need to know which lever you have not pulled yet, and to pull the next one before the field data tells you it was already too late.

If you want a Core Web Vitals audit on your specific site, we run them at Seahawk Media starting from 2,500 USD. The audit produces field-data analysis, prioritised remediation, and a target metric profile you can track over time.