Is Next.js faster than WordPress?

It has a higher ceiling and no guaranteed floor. A well-built theme on decent hosting beats a Next.js application that ships too much JavaScript, and we have measured that more than once. What the framework buys is the ability to defend the number in CI instead of rediscovering it every quarter.

Can editors keep using WordPress if we move the front end?

Yes, that is headless WordPress and it is usually the sensible version of this. The thing to get right is preview: editors who cannot see a draft as it will actually look stop trusting the system within a month, and the project gets judged on that rather than on rendering.

What happens to our search traffic if we move?

That depends almost entirely on whether the URLs stay the same. A move that keeps every URL and improves the markup is low risk. A move that also redesigns the information architecture is two changes at once, and when the traffic drops you will not know which of them did it.

Do we have to move the whole site at once?

No, and you should not. Take the templates carrying traffic first and leave the rest on WordPress. A site running on two systems looks untidy on a diagram and costs far less than a rewrite that has to land in one go.

WordPress vs Next.js: When a Theme Stops Being Enough

Both render HTML for a browser, so unlike most comparisons this one is head to head. For most sites WordPress wins on cost of ownership. Here is the boundary where that stops.

Published September 22, 20264 min read

Most pages answering this question are written by a company that sells one of the two. So, the disclosure first: we build Next.js applications, and for a large share of the sites that land here, our answer is that you should stay on WordPress.

The honest starting position

A brochure site, a blog, a small business site, a publication with editors. WordPress does that job well, cheaply, and with a maintenance path that does not need a front-end team. Moving it to Next.js buys a faster theoretical page and costs you an editing experience, a plugin ecosystem, and a hosting bill that used to be trivial.

If nobody on your side will own a JavaScript codebase after we leave, that is not a detail to work around. It is the whole answer.

What you actually give up

This is the part the comparison pages skip, so here it is as a list.

The editor. Not the text field, the whole thing. Preview, revisions, scheduled publishing, media handling, and the block editor your team has muscle memory for. Some of it comes back. None of it comes back for free.

Forms. A contact form is a plugin in WordPress. In Next.js it is four decisions: where it posts, what stops spam, where the submission is stored, and who gets told about it.

The SEO plugin. Yoast and its relatives put metadata, sitemaps, redirects and schema behind a UI a marketer can operate. In Next.js those are code. That is better in the end, because the wrong tag becomes impossible rather than merely discouraged, but on day one it is work somebody has to do.

Redirects. Managed in an admin screen, or managed in the codebase. Only one of those can be done by your marketing team at five o'clock on a Friday.

Where a theme stops being the right container

There is a real boundary and it is not traffic, and not page count.

It is when the front end starts having application behaviour. Logged-in state that changes what a page shows. Filtering across thousands of items that has to be fast and linkable. A design system shared with a product that is not the website. Personalisation. A checkout you actually control.

A theme can be pushed into all of those. We have seen it done. The result is PHP templates with several thousand lines of jQuery on top, a caching layer that has to be bypassed for half the routes, and nobody willing to touch the header.

Core Web Vitals, which is not the argument you think

A well-built WordPress theme on decent hosting beats a badly built Next.js application. We have measured both often enough to be blunt about it.

The framework is not the variable. What decides LCP is when the request for the largest element starts, and a Next.js site gets that wrong as easily as a theme does. What Next.js gives you is a better ceiling and the tools to defend it in CI. It does not hand you the floor.

If somebody is selling a rebuild on the promise of a green score, ask what the score is now and what is causing the number. Usually it is three images and a font.

Headless WordPress, the middle path

Keep WordPress as the editing surface. Render with Next.js. Editors keep the tool they know, the URLs stay yours, and the front end gets the boundary it needed.

It is a legitimate architecture and often the cheapest path. It is also where these projects go wrong, in one specific way: preview. If editors cannot see a draft as it will actually appear, they stop trusting the system within a month, and the whole thing is written off for reasons that have nothing to do with rendering.

How to decide without a rewrite

Take the two or three templates that carry your traffic and your conversions. Not the whole site.

If what makes them bad is images, fonts and a plugin doing something silly, that is a WordPress problem with a WordPress fix, at a fraction of the cost of a rebuild. If what makes them bad is that the page has to be an application and it is a template, you have your answer. Move those routes first and leave the rest of the site where it is.

Where the front end genuinely has to become an application, that is the build. Where it does not, and the honest answer is that Next.js is the wrong tool for the site you have, there is a page about that too.

A store on Shopify is a different conversation again, and a shorter one. Shopify stays either way there, so what is actually being decided is who renders the storefront.