Web Performance Benchmarks 2026: Core Web Vitals & Page Speed Trends

Performance targets mean nothing without context. Knowing that your LCP is 2.3 seconds does not tell you whether that is competitive until you know what other sites in your category achieve. This guide provides the 2026 benchmarks — where the web stands on Core Web Vitals, how different platforms and CMS choices affect baseline performance, and what realistic targets look like for different site types.

This is for developers and site owners who need data-grounded performance targets, not aspirational goals from conference talks. The numbers come from the Chrome User Experience Report (CrUX), HTTP Archive, and field data from production sites we have worked on.

Industry-Wide Performance in 2026

LCP (Largest Contentful Paint)

Median across all origins: 2.8 seconds (mobile), 1.6 seconds (desktop)

The mobile-desktop gap has narrowed slightly since 2024, but remains significant. The primary driver is not network speed — 4G/5G is fast enough. It is device processing power. Mid-range phones need more time to parse JavaScript, decode images, and complete layout.

By CMS:

• Static site generators (Gatsby, Hugo, Astro): median 1.8s mobile
• WordPress (optimised, good hosting): median 2.6s mobile
• WordPress (average): median 3.4s mobile
• Shopify: median 2.9s mobile
• Squarespace: median 3.1s mobile
• Custom React SPAs: median 3.2s mobile

Static site generators consistently outperform server-rendered platforms because the output is pre-built HTML. There is no server processing at request time. The Core Web Vitals guide covers the specific techniques for hitting sub-2.5s LCP.

INP (Interaction to Next Paint)

Median across all origins: 230ms (mobile), 80ms (desktop)

This is the metric where most sites are failing in 2026. The 200ms threshold is exceeded by over 60% of mobile origins. The desktop numbers look healthy because desktop hardware masks JavaScript bloat.

Common INP failure patterns:

• Single-page applications with heavy client-side rendering
• Sites with 3+ third-party scripts running simultaneously
• JavaScript-heavy interactive widgets (carousels, complex forms, live search)

CLS (Cumulative Layout Shift)

Median across all origins: 0.08 (mobile), 0.05 (desktop)

CLS is the only metric where the majority of sites pass the threshold (0.1). The improvements have been driven by better awareness of layout shift causes and framework-level mitigations (image dimension attributes, font loading strategies).

Category-Specific Benchmarks

Content / Editorial Sites

Target: LCP < 2.0s, INP < 150ms, CLS < 0.05

Content sites should be the fastest category. The pages are predominantly text and images with minimal interactivity. If your content site fails Core Web Vitals, the cause is almost always third-party scripts, unoptimised images, or excessive JavaScript for features that could be CSS.

E-Commerce

Target: LCP < 2.5s, INP < 200ms, CLS < 0.1

E-commerce sites have more interactive elements (product filters, cart updates, variant selectors) that make INP harder. The CLS target is at the threshold because product listings with dynamically loaded images and prices are prone to shift.

SaaS / Web Applications

Target: LCP < 3.0s, INP < 200ms, CLS < 0.1

Application-style sites inherently have more JavaScript and interactivity. The LCP target is more lenient because the "largest contentful paint" is often a UI shell, not content. INP is the critical metric — application responsiveness directly affects user productivity and retention.

Portfolio / Agency Sites

Target: LCP < 2.0s, INP < 100ms, CLS < 0.05

Portfolio sites should be fast. They are typically static, image-focused, and have minimal interactivity. Failing performance on a portfolio site is particularly damaging if you are demonstrating design or development skill.

The JavaScript Weight Problem

The single largest performance predictor for a website in 2026 is JavaScript payload size. HTTP Archive data shows:

• Median JavaScript per page: 520KB (compressed), 1.8MB (uncompressed) on mobile
• 90th percentile: 1.2MB (compressed), 4.5MB (uncompressed)

Each KB of JavaScript costs more than each KB of images because JavaScript must be downloaded, parsed, compiled, and executed — all on the main thread. The CSS innovations guide covers the CSS features that can replace JavaScript for UI interactions, directly reducing this payload.

Framework Overhead

| Framework | Typical JS bundle (gzip) | Note | |---|---|---| | Vanilla HTML/CSS | 0KB | No framework overhead | | Gatsby (static) | 70–90KB | React runtime + router | | Astro | 0–20KB | Ships zero JS by default | | Next.js (SSG) | 80–100KB | React runtime + router + hydration | | Next.js (SSR) | 80–100KB | Same, but server-rendered | | Create React App | 120–200KB | Full client-side rendering | | Vue/Nuxt | 60–80KB | Smaller runtime than React |

The Gatsby site you are reading has a baseline JavaScript cost of roughly 80KB. Every additional JavaScript feature (search, analytics, interactive widgets) adds to that baseline. Performance discipline means evaluating whether each addition is worth its cost in milliseconds.

Mobile vs Desktop: The Hidden Gap

Developers test on desktop machines and deploy to mobile users. The performance gap is not just about network speed:

• CPU processing: A 2024 MacBook Pro executes JavaScript 8–12x faster than a mid-range Android phone
• Memory: Desktop browsers have 4–8GB available. Mobile browsers are throttled to 1–2GB
• Thermal throttling: Phones reduce CPU speed when they get warm. Sustained JavaScript execution on mobile gets slower over time within a single page visit

This means a page that runs smoothly on your development machine can be visibly sluggish on the devices your visitors actually use. The Core Web Vitals guide recommends testing on actual mid-range phones — the data here explains why that recommendation is critical.

Image Performance in 2026

Images remain the largest payload category:

• Median image weight per page: 1.1MB (mobile), 1.6MB (desktop)
• Average number of image requests: 24 per page

Format Adoption

| Format | Support | Savings vs JPEG | |---|---|---| | WebP | 97% of users | 25–35% smaller | | AVIF | 88% of users | 40–50% smaller | | JPEG XL | ~20% of users | 35–45% smaller |

AVIF should be your primary format with JPEG fallback. The cache and performance guide covers image optimisation strategy. The benchmarks show that sites using AVIF with <picture> element fallbacks have measurably better LCP than sites serving JPEG only.

Setting Your Performance Budget

A performance budget defines the maximum acceptable resource weight for each category:

| Resource | Budget (mobile) | |---|---| | HTML | < 50KB | | CSS | < 60KB | | JavaScript | < 150KB (gzip) | | Images (above fold) | < 200KB | | Fonts | < 80KB | | Total initial load | < 540KB |

These budgets, combined with CDN delivery (TTFB < 200ms), produce pages that consistently pass all three Core Web Vitals thresholds on mobile.

Checklist

• [ ] Current Core Web Vitals measured in CrUX field data (not just Lighthouse)
• [ ] Performance budgets defined for JS, CSS, images, and fonts
• [ ] JavaScript payload tracked per-page, not just per-build
• [ ] Mobile testing done on actual mid-range devices, not just DevTools throttling
• [ ] Third-party script impact measured separately from first-party code
• [ ] Image format strategy defined (AVIF primary, JPEG fallback)
• [ ] Framework JS overhead accounted for in performance budget
• [ ] Performance regression alerts configured in CI/CD pipeline
• [ ] Competitor performance benchmarked for context
• [ ] Performance metrics included in project requirements, not just post-launch audits

FAQ

How do I access CrUX data for my site? Use PageSpeed Insights, the CrUX Dashboard on BigQuery, or the CrUX API. You need sufficient traffic volume for CrUX to report data — roughly 1,000+ monthly visits from Chrome users.

Can a WordPress site really match static site generator performance? With excellent hosting, aggressive caching, minimal plugins, and a block theme, yes. But the default WordPress setup is significantly slower than the default Gatsby or Hugo setup.

Is the 200ms INP target achievable for complex web apps? It is challenging but achievable with careful JavaScript architecture: breaking long tasks, using Web Workers for computation, and moving UI interactions to CSS where possible.

Next Steps

• Review the Core Web Vitals guide for specific optimisation techniques
• Check the CSS innovations guide for reducing JavaScript payload
• Read the advanced typography guide for font loading performance
• Browse all guides for more implementation patterns