WordPress powers a large share of the web, and most of the arguments made against it by agencies selling something else are overstated or simply wrong. So let's start by being clear about where WordPress is the right answer, because that's more useful than a sales pitch — and because getting this decision wrong in either direction is expensive.
WordPress is the correct choice when non-technical people need to publish frequently and independently, when you need a specific plugin ecosystem, when the budget doesn't support custom development, or when you need something live next week. A well-hosted, lightly-plugged WordPress site on modern PHP is fast, secure, and entirely respectable.
A custom Next.js build is the correct choice when the site is closer to an application than a brochure, when performance is a business constraint rather than a preference, when you need integrations that don't have plugins, or when you're carrying real technical debt from plugin accumulation.
Now the detail.
Where the performance difference actually comes from
The common claim is that Next.js is fast and WordPress is slow. The mechanism matters more than the slogan, because it tells you when the difference will actually show up.
A default WordPress request runs PHP, queries MySQL several times, assembles the page, and returns it. Every request. Add ten plugins, each adding queries and its own CSS and JavaScript, and you accumulate work per visitor.
A statically generated Next.js page was rendered once at build time and is served from a CDN edge node as a file. There's no database, no template rendering, no per-request work.
But that comparison is not apples to apples. A WordPress site with proper page caching — via a caching plugin or at the CDN — also serves a static file to most visitors. The gap narrows dramatically. Cached WordPress versus statically generated Next.js is a much closer race than uncached WordPress versus Next.js, and honest benchmarks compare the former.
Where Next.js retains a real, structural advantage:
- Automatic image optimisation.
next/imagehandles modern formats, correct sizing per device, and lazy loading with reserved space. Achievable on WordPress, but it takes plugins and discipline. - Font loading.
next/fontself-hosts and preloads, eliminating a common layout-shift source. - JavaScript shipped. A custom build ships the code you wrote. A plugin-heavy WordPress site ships whatever each plugin enqueues site-wide, including on pages that don't use it.
- Layout stability. Explicit dimensions everywhere by construction, rather than by remembering.
That last set is where Core Web Vitals scores separate. It's less about raw response time and more about everything after the first byte.
On specific numbers: any figure quoted without naming the hardware, the network, the page, and the plugin set is marketing. Measure your own site. PageSpeed Insights gives you lab and field data for free, and your field data is the only number that matters.
Core Web Vitals and rankings: Next.js vs WordPress SEO
Google uses page experience signals — Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift — as a ranking factor. That much is confirmed and worth optimising for.
The part that gets oversold: it's a tiebreaker, not a lever. Google has been consistent that relevance and content quality dominate. A fast page with thin content does not outrank a slower page that better answers the question. If you're rebuilding primarily to win rankings through speed, you will be disappointed.
Where speed reliably pays is conversion, particularly on mobile and particularly on slower connections. That's a real business case, and it doesn't depend on any ranking claim.
Security, honestly
The usual argument — "static sites have no database, so no SQL injection" — is true only for genuinely static sites.
If your Next.js application has a login, a contact form, a CMS, or a dashboard, it has a database and an attack surface. It's a different surface, not an absent one. Our own experience auditing Next.js applications is that they fail on authorisation logic, unvalidated Server Actions, and unverified webhooks — vulnerabilities WordPress sites simply don't have because they never implemented those things.
The genuine differences:
WordPress's risk is largely supply chain. Most breaches trace to outdated plugins and themes, not to WordPress core, which has a mature security team. Ten plugins means ten codebases you didn't write, each needing prompt updates. That's a real, ongoing operational burden.
Next.js's risk is largely your own code. No plugin ecosystem means no plugin vulnerabilities. It also means every access check is one you wrote, and any mistake is yours. You've traded a supply-chain problem for an implementation problem.
A truly static marketing site genuinely is lower risk. If it's pre-rendered HTML with no forms and no database, there isn't much to attack. That's a legitimate advantage, and it applies to a narrower set of sites than people claim.
Which risk you prefer depends on whether you'd rather patch dependencies or trust your own engineering. Neither is "secure by default."
What you actually give up
The honest cost side, which is usually omitted:
| WordPress | Custom Next.js | |
|---|---|---|
| Non-technical editing | Excellent, out of the box | Needs a CMS wired in |
| New page templates | Often a plugin or theme setting | A developer |
| Time to first launch | Days | Weeks |
| Upfront cost | Low | Substantially higher |
| Ongoing cost | Hosting + plugin licences | Hosting + developer availability |
| Finding help later | Enormous talent pool | Smaller, more expensive |
| Plugin ecosystem | Vast | Build it yourself |
The editing question is the one that sinks projects. If your marketing team publishes weekly and the new site requires a developer for every change, you've made the organisation slower regardless of the Lighthouse score. Budget for a headless CMS — Sanity, Payload, Strapi, or similar — as part of the build, not as a later addition. A custom site nobody can update becomes a site nobody updates.
And "you'll need a developer" is a permanent condition, not a launch cost. If you have no ongoing engineering relationship, WordPress is more honest about what it will demand of you.
The middle option
Headless WordPress — WordPress as the editing interface, Next.js rendering the front end via the REST or GraphQL API — is frequently the pragmatic answer and gets overlooked because it doesn't suit either side's pitch.
Your team keeps the editor they know. You get the front-end performance and the freedom to build interfaces WordPress themes can't express. You keep the plugin ecosystem for content workflows.
The cost is two systems to maintain and a more complex deployment. But if the actual problem is "our WordPress front end is slow and inflexible" rather than "WordPress is the wrong tool," this addresses the real complaint at meaningfully lower risk than a full rebuild.
How to decide
- Who edits the site, and how often? Frequent edits by non-technical staff pushes hard toward WordPress or headless.
- Is it a site or an application? Custom flows, dashboards, calculators, real-time features — Next.js. Pages and posts — WordPress.
- Is performance a business constraint or a preference? If you can point to conversion or ad-cost impact, the investment justifies itself. If it's a Lighthouse score you'd like to be greener, it probably doesn't.
- Do you have ongoing engineering access? If not, be very careful about custom.
- What's actually wrong today? "Our site is slow" often has a cheaper fix — caching, image optimisation, removing four plugins — than a rebuild.
That last question is worth asking sincerely. We've told prospective clients their existing WordPress site needed a week of optimisation rather than a rebuild, and it was the right answer. A rebuild that solves a problem you could have fixed for a tenth of the cost isn't a win.
Want a straight assessment?
We build custom Next.js applications, and we'll tell you when you don't need one. If you want an honest read on whether a rebuild is justified for your site, talk to us about web development.