Neither WordPress nor Next.js has a speed. What has a speed is the rendering mode — whether the HTML already exists when the visitor asks for it, or gets built while they wait. Decide that and the framework question mostly answers itself.
The closest thing to evidence here compares architectures rather than logos, and the gap is smaller than the arguments suggest. In the 2024 Web Almanac, 41% of prerendered sites passed Core Web Vitals, against 33% of dynamic ones (verified August 2026). Prerendering wins by roughly eight points. It also leaves 59% of prerendered sites failing, which is the part nobody quotes.
Worth saying where we stand before the comparison: this blog is a Next.js static export, and most of our week goes into making WordPress sites faster. We sell both. That is exactly why we have no reason to tell you the tool matters more than it does.
Neither has a speed. The rendering mode does
A page is fast or slow depending on when its HTML gets built and who builds it. There are four answers to that, and both platforms can be configured into most of them. This is why the versus framing collapses on contact: you can build a slow Next.js site and a fast WordPress one without doing anything unusual in either.
| Rendering mode | When the HTML is built | What a crawler receives | On WordPress | On Next.js |
|---|---|---|---|---|
| Pre-rendered at build | Before anyone visits | The complete document, immediately | Static-export plugins, or an edge cache that behaves like one | output: ‘export’ — one HTML file per route, hostable on any web server |
| Server-rendered once, then cached | On the first request, reused until purged | The complete document | A page cache. The default good WordPress setup | Cached rendering or ISR — needs a server, so not in a static export |
| Server-rendered per request | While the visitor waits | The complete document, once the server has finished thinking | WordPress without a cache, and always cart, checkout and logged-in pages | Next.js on a Node or serverless host, rendering on demand |
| Assembled in the browser | After the JavaScript downloads and runs | A shell, with the content arriving later | Uncommon site-wide, normal for individual widgets and builder blocks | A build that ships content as client-side data instead of HTML |
HTTP Archive, whose data this argument usually gets fought with, says the quiet part itself. Its Jamstack chapter warns that “many Static Site Generators don’t leave a fingerprint by default, so the dataset skews toward frameworks like Next.js and Nuxt that do”, and then asks the question that ends the debate: these frameworks “are capable of both prerendering pages and dynamically rendering them, so which category do we put them in?” (verified August 2026). If the people who collect the numbers cannot classify a framework by its rendering, the framework name is not the variable.
For scale, the same body of work puts the whole web at 48% of mobile origins and 56% of desktop origins passing all three Core Web Vitals (2025 Web Almanac, July 2025 CrUX data, verified August 2026). Against that baseline, an eight-point architectural advantage is real and worth having. It is not the difference between a fast site and a slow one.
“Is Next.js good for SEO” is the wrong question too
Both are fine. Both can be broken. The only thing that matters technically is whether your HTML contains your content when the crawler reads it, and a static export guarantees that by construction: the build “generates an HTML file per route” and the result can be served by any web server (Next.js documentation, verified August 2026). From Googlebot’s side that is indistinguishable from a cached WordPress page.
The configuration that does cost you is the fourth row of the table. Google processes JavaScript in three phases — crawling, rendering, indexing — and rendering is not immediate: “Googlebot queues all pages with a 200 HTTP status code for rendering… The page may stay on this queue for a few seconds, but it can take longer than that” (Google Search Central, verified August 2026). Content that only exists after JavaScript runs is content waiting in a queue. Content in the HTML is not.
So the real SEO difference is not capability. It is who owns the technical SEO, and how each one decays.
WordPress rots. Its SEO lives in a plugin someone configured once, and the site gets heavier one small decision at a time. The pattern is familiar to anyone who audits these sites: a plugin added for a single feature, forgotten, loading its own CSS and JavaScript on every page for two years — and it turns out that deactivating it moves the numbers more than any optimisation plugin ever did. Nobody chose that. It accumulated.
Next.js forgets. The metadata, the sitemap and the structured data are code, written once and then correct forever, which is genuinely better right up until someone adds a new page type and nobody adds it to the sitemap route. Or the build starts failing and the site keeps serving last month’s HTML perfectly, so nobody notices. The failure is silent and it is always an omission.
The comparison that actually decides it
Same nine dimensions, both platforms, no diplomacy. The Next.js column assumes a static export, because that is the configuration worth comparing — a Next.js app rendering every request on a server is just WordPress with more expensive developers.
| What you are deciding | WordPress | Next.js (static export) |
|---|---|---|
| Speed ceiling | High. A cached page is a file, and a file is fast | High. There is no PHP in the request path to be slow |
| Speed floor | Low, and commonly reached: thirty plugins and no cache | Also low, if the build ships a heavy bundle or renders content in the browser |
| SEO capability | Everything you need, via a plugin somebody has to keep configured | Everything you need, written in code once — and nothing happens by itself |
| Who can publish | Anyone, from a browser, with no technical involvement | Anyone if you wire up a CMS; otherwise a developer and a pull request |
| What publishing feels like | Log in, edit, publish. It is live | Edit, build, deploy. A minute if the pipeline works, a morning if it does not |
| Cost shape | Cheap to start, permanent maintenance line | More to build, then almost nothing to host |
| Maintenance rhythm | Continuous and unavoidable: core, plugins, PHP, security | Rare but lumpy: dependency and framework upgrades arriving all at once |
| How it fails | By accumulation — weight, conflicts, an update that breaks a page | By omission — a page type with no metadata, a build that silently stopped |
| Best fit | Frequent publishing by non-technical people, shops, anything plugin-shaped | Content that changes rarely, where speed, control and hosting cost matter most |
Four questions that settle it
- Who edits the site, and how often? This decides it more often than everything else combined. Daily publishing by people who do not write code points at WordPress, and no amount of tooling makes a build step feel like a publish button.
- Does anything have to happen at request time? Carts, logins, personalised pages, server-side form handling. A static export cannot do those — the docs list cookies, Server Actions, request-reading route handlers and ISR among the unsupported features — so needing them means needing a server, which is a different project with a different budget.
- Do you depend on a plugin ecosystem? WooCommerce, memberships, bookings, a form builder your team knows. Rebuilding those is not a weekend, and “we will just use an API for it” is where most of the overrun comes from.
- Is the current site actually slow because it is WordPress? Measure before you answer. Most of the time the cause is server response time you can fix with a cache or an LCP image the browser finds out about too late, and both of those mistakes port cleanly into a new framework.
When Next.js is not worth it
Next.js is not automatically faster than WordPress, and a well-tuned WordPress beats a sloppy Next.js build. The speed comes from static pre-rendering and discipline, not from the logo. The 41% figure is the honest version of this: even in the category that wins, most sites still fail, because the category tells you when the HTML was built and nothing about whether someone shipped a 400KB JavaScript bundle and four web fonts alongside it. A framework can remove one class of problem. It cannot supply judgement.
And rebuilding to fix speed is the most expensive page cache on the market. If a site is slow, find out which part is slow first. Server response time is a cache and a decent host. A late hero image is an attribute. Layout that jumps under the reader is reserved space, and a JavaScript framework can make that one worse, not better. Rebuild for the architecture, the control and the hosting bill — good reasons, all of them — but not as a performance patch, because you will pay for a rebuild and inherit the same mistakes.
The reverse holds too, and we say it before starting: if you publish every day with non-technical authors, Next.js is usually the wrong tool, and a well-optimised WordPress serves that team better. Where the rebuild does earn its cost is a site whose content changes rarely, where the hosting is a monthly annoyance and the speed is worth engineering for — that is what our Next.js builds are for. If the site you have is the right tool and just slow, the cheaper answer is making it fast.
Frequently asked questions
Is Next.js faster than WordPress?
Not automatically. Speed comes from the rendering mode, not the framework, and Next.js can be configured to render every request on demand exactly as an uncached WordPress site does. The closest thing to an answer from field data compares architectures rather than logos: in the 2024 Web Almanac, 41% of prerendered sites passed Core Web Vitals against 33% of dynamic ones. Prerendering wins, by about 8 points, and it still leaves the majority of prerendered sites failing.
Is Next.js good for SEO?
Yes, when your HTML contains your content at crawl time — which a static export does by definition, since the build writes one HTML file per route. The risk is the other configuration, where content is assembled in the browser. Google processes JavaScript in three phases, crawling, rendering and indexing, and queues pages for rendering: the page may stay on that queue for a few seconds, but it can take longer. Server-rendered or prerendered HTML skips the queue entirely.
Should I rebuild my WordPress site in Next.js to make it faster?
Usually not, and certainly not before measuring. A rebuild is the most expensive page cache you can buy. Find out first which part is slow — if it is server response time, a cache and a decent host fix it for a fraction of the cost; if it is a hero image discovered too late, no framework change helps because the same mistake ports straight across. Rebuild when you want the architecture, the control and the near-zero hosting, not as a performance patch.
Can I still use a CMS with Next.js?
Yes. A headless CMS, or WordPress itself used only as an editing back end, both work and both keep the editing experience your team already knows. What does not go away is the build step: content changes become a build and a deploy rather than an instant publish. If that pipeline is well set up it takes a minute; if nobody owns it, it is the thing that quietly breaks.
What can a Next.js static export not do?
The framework documents the list: no cookies, no request-reading route handlers, no Server Actions, no Incremental Static Regeneration, no draft mode, no image optimisation with the default loader, and no dynamic routes without generateStaticParams. Redirects, rewrites and headers move from the framework config to your host. None of that is a flaw — it is what makes the output pure static files — but a site that needs any of it needs a server, and that is a different project.
Which one is cheaper?
The shapes differ more than the totals. WordPress is cheap to start and carries a permanent maintenance line: core, plugins, PHP versions, security. A static Next.js site costs more to build, then costs almost nothing to host, and its maintenance is rare but lumpy — dependency and framework upgrades that arrive all at once rather than a little every month. Pick the shape that matches who is going to be responsible for it in two years.
Sources (verified August 2026): Web Almanac 2024 — Jamstack; Web Almanac 2025 — Performance; Google Search Central — JavaScript SEO basics; Next.js — Static exports.