Next.js vs WordPress in 2026: what real-user data says, and which to choose

"Should we build this on WordPress, or on something more modern?" The question usually comes with a belief attached: that Next.js is fast by nature and WordPress slow by nature. The field data does not say that. This comparison puts the two side by side on what can be measured, real-user speed, lab scores, page weight, market share, and on what cannot be measured but still decides projects: who edits the content, who maintains the stack, and what it costs over three years.

Every figure below has its source next to it. The speed figures come from the HTTP Archive Core Web Vitals Technology Report, which combines Chrome UX Report data from real Chrome users with the technologies HTTP Archive detects on each site. We read the 1 September 2026 crawl on 17 October 2026.

WordPress in 2026: four in ten websites

WordPress is used by 39.7% of all websites, and by 58.4% of the websites whose content management system is known, according to W3Techs (figures of 16 October 2026). It was first released in 2003 and it is still, by a wide margin, the most used CMS in the world.

The ecosystem. The official WordPress.org directory lists 71,871 plugins (query of its public API on 17 October 2026), before counting commercial ones. A contact form, a booking module, a store with WooCommerce, a multilingual layer: almost every common feature already exists, which saves time and budget on standard projects.

Content autonomy. The WordPress admin is familiar to a very large number of editors. A team can change copy, publish posts and manage products without a developer, and the block editor has made page building far less dependent on the theme.

The entry cost. A theme, a handful of plugins and shared hosting are enough to launch. For a small organisation with a tight budget and standard needs, that remains a strong argument.

The limits. Each plugin adds its own scripts, styles and database queries, and they are written by different authors with different standards. The attack surface is mostly there: plugins and themes have to be updated continuously, and an abandoned one is a liability. Technical debt builds up as plugins pile on, and every later change costs a little more.

Next.js in 2026: a framework, not a CMS

Next.js is a React framework maintained by Vercel. It renders pages ahead of time or on the server and sends the browser ready HTML, then React takes over in the browser. Its current major version, Next.js 16, was released on 21 October 2025: it made Turbopack the default bundler and introduced Cache Components, which is where partial prerendering now lives. This site runs on Next.js.

Control. You decide exactly what HTML, which scripts and which data each page sends. Metadata, structured data, sitemaps and redirects are code, reviewed like the rest of the code.

Rendering options. A page can be fully static, regenerated on a schedule, or rendered on each request. Static pages served from a cache are hard to beat on time to first byte.

Security. A Next.js site has no public admin panel by default and no third-party plugins running on the server. The dependencies still need updating, and a framework vulnerability concerns every site at once, but the surface is smaller and you choose what goes into it.

The limits. It needs React developers, so the initial build costs more. Editors need a headless CMS (Sanity, Strapi, Contentful, or WordPress itself used headless), which is one more piece to set up and learn. There is no plugin to install: every feature is either a library or code.

What real-user data says about speed

This is where the usual article prints "95-100 on PageSpeed for Next.js, 70-85 for WordPress" without a source. Here are the measured numbers instead. Core Web Vitals are Google's three field metrics: LCP (loading, good under 2.5 seconds), INP (responsiveness, good under 200 milliseconds) and CLS (visual stability, good under 0.1). INP replaced FID as a Core Web Vital on 12 March 2024. A site passes when at least 75% of its real visits are good on each of the three.

• WordPress, 2,658,175 sites
• Next.js, 395,345 sites

All three metrics good

WordPress48.3%

Next.js35.7%

LCP good (loading)

WordPress55.4%

Next.js53.5%

INP good (responsiveness)

WordPress90.3%

Next.js59.7%

CLS good (visual stability)

WordPress87.3%

Next.js73.5%

Source: HTTP Archive, Core Web Vitals Technology Report (Chrome UX Report field data), crawl of 1 September 2026, mobile, all countries, all ranks. Share of sites (origins) whose 75th percentile is good. Read on 17 October 2026.

September 2026, HTTP Archive	WordPress	Next.js
Sites measured on mobile	2,658,175	395,345
Good Core Web Vitals, mobile	48.3%	35.7%
Good Core Web Vitals, desktop	53.7%	56.9%
Good Core Web Vitals, mobile, September 2025	45.0%	28.1%
Median Lighthouse performance score, mobile (lab)	43	53
Median JavaScript per page, mobile	677 KB	822 KB
Median page weight, mobile	2.72 MB	2.17 MB

Three things stand out.

• On phones, real visitors get a good experience on more WordPress sites than Next.js sites: 48.3% against 35.7%. On desktop the order flips, 56.9% for Next.js against 53.7%.
• The gap is responsiveness. Loading is almost level (LCP good on 55.4% and 53.5% of sites). INP is good on 90.3% of WordPress sites and only 59.7% of Next.js sites. Next.js pages ship more JavaScript (822 KB median on mobile against 677 KB), and hydrating it keeps the main thread busy right when the visitor taps.
• The lab score says the opposite. The median Lighthouse performance score on mobile is 53 for Next.js and 43 for WordPress. A lab test loads one page once, on a simulated phone; field data is months of real visits, with real interactions. When the two disagree, the field data is what Google uses.

These are averages over everything detected as WordPress or Next.js, and the two populations are not the same: many Next.js sites are heavy web applications, many WordPress sites are brochure sites. The data does not prove that WordPress is faster. It proves something more useful: the framework does not make a site fast, the build does. A Next.js site that ships little JavaScript and renders statically will pass; one that hydrates a large client bundle on every page will not. The trend is moving, too: Next.js went from 28.1% to 35.7% of sites passing on mobile in a year, WordPress from 45.0% to 48.3%.

The head-to-head comparison

Criterion	WordPress	Next.js	Advantage
Real-user speed (field)	48.3% of sites pass Core Web Vitals on mobile	35.7% on mobile, 56.9% on desktop	Depends on the build; on average WordPress on mobile
Ceiling	Limited by the theme and the plugins you keep	No ceiling: you control every script that ships	Next.js
SEO control	Good with Yoast or Rank Math, within what the theme outputs	Full control of the HTML, metadata, structured data and redirects	Next.js
Initial cost	Low: theme, plugins, fast setup	Higher: custom development and a headless CMS	WordPress
Maintenance	Core, theme and plugin updates, all the time	Dependency updates, fewer moving parts on the server	Next.js, if a developer owns it
Content autonomy	Familiar admin, no developer needed	Headless CMS with a learning curve	WordPress
Security	Plugins and themes are the main attack surface	No public admin, smaller server surface	Next.js

On total cost of ownership. WordPress is cheaper to launch. Its recurring costs are the ones nobody puts in the first quote: premium plugin licences, updates, the fix when an update breaks something, hosting sized to absorb the plugins. A Next.js site concentrates the spending at the start and needs less after, provided someone who can read the code stays responsible for it. Without that person, the comparison turns in favour of WordPress, whose ecosystem of maintainers is enormous.

Which one for your project?

Choose WordPress if

• The budget is tight and the launch date close.
• The site is mostly a blog or a brochure site, with standard features.
• Non-technical people must edit everything themselves from day one.
• Nobody on your side, or around you, will own a codebase.

Choose Next.js if

• The site is a product, with logic, accounts or integrations a plugin will not cover.
• Search visibility and speed are worth engineering time, and someone will measure them in the field, not only in Lighthouse.
• You want to control exactly what ships to the browser.
• A developer will own the code after launch.

For a store, the patterns that decide speed and reliability (static product pages, the cart, the checkout) are in our guide to the App Router for e-commerce.

The hybrid approach

WordPress can stay the editing tool while Next.js renders the public site: editors keep the admin they know, visitors get pages built by the framework. The price is two systems to maintain instead of one. It pays off when the editorial volume is real, rarely for a five-page site updated twice a year.

Our view

We build our own products, and they run on Next.js, like this site. That is a choice of control, not a promise of speed: the numbers above are a reminder that a Next.js site has to earn its Core Web Vitals, mostly by sending less JavaScript. If the project is a brochure site that a team will edit alone, WordPress remains the rational answer. If the project is a product, the framework that lets you control everything is worth its cost, as long as someone measures what real visitors experience.

If you are moving an existing WordPress site, plan the redirects before anything else: every old URL needs a permanent redirect to its closest equivalent, or the search traffic built over the years goes with it.