Custom Code vs WordPress: An Honest Comparison

Neither answer is right in general, and the argument the industry uses to settle it is measurably wrong. The usual claim is that custom code is fast and WordPress is slow. In the field, the opposite ordering shows up: WordPress sites pass Core Web Vitals on mobile more often than Next.js sites do. So the choice has to be made on something else, and this guide is about what that something else is.

We build both. We build custom websites in Next.js and we build WordPress sites, and the way we decide between them for a client has nothing to do with which one is technically superior. It has to do with who is going to touch the site in year two.

What the field data actually says

HTTP Archive publishes a Core Web Vitals Technology Report built on the Chrome User Experience Report, which records real page loads from Chrome users who opted into data sharing. It is the largest public comparison of how technologies perform for actual visitors rather than in a lab. For the July 2026 crawl, across all countries and all rank groups, this is the share of mobile origins that passed all three Core Web Vitals.

WordPress sits slightly below the web-wide average of 53.2%. Next.js sits fifteen points below WordPress. Astro, Shopify and Wix — one static-first framework and two hosted platforms — sit well above everything else.

Read the caveat before you use the number, because it is the whole point. This is a population comparison, not an experiment. Nobody held hosting, page type or budget constant. A large share of WordPress sites are brochure sites on shared hosting; a large share of Next.js sites are applications with dashboards and interactive state, which are harder to make fast by nature. The data cannot tell you that WordPress causes better performance, and we are not claiming it does.

What it can tell you is narrower and more useful: choosing a modern framework does not produce a fast site. If it did, the sites built on modern frameworks would be fast, and across the 349,852 Next.js origins in the HTTP Archive sample they are not. Performance comes from decisions made inside the build, which is the argument our Core Web Vitals guide makes in detail.

The two stacks fail in opposite places

Aggregate pass rates hide the finding that actually helps you choose. Break the same two technologies apart by metric — still HTTP Archive, July 2026, mobile — and the failure modes invert.

WordPress loses on Time to First Byte: only 24.4% of its mobile origins are rated good, against 46.1% for Next.js and 46.0% for the web as a whole. That is a server problem — cheap shared hosting, uncached PHP, a database query per request.

Next.js loses on Interaction to Next Paint: 58.8% rated good, against 91.0% for WordPress. That is a main-thread problem — JavaScript that has to parse, hydrate and execute before the interface answers a tap.

The difference between those two failures is the practical one, because a TTFB problem is something you can buy your way out of and an INP problem is something you have to rebuild. Moving a WordPress site to better hosting with proper page caching is a purchase with a known price and a same-week result. Reducing the JavaScript a React application ships means changing what the application is. If you are choosing a stack, you are also choosing which of those two bills you would rather receive.

WooCommerce deserves a separate line here. At 40.1% overall and only 13.3% good TTFB on mobile, it is the weakest common configuration in the dataset — a shop is a WordPress site with the caching disabled on the pages that matter most. We covered what that means for platform choice in WooCommerce vs Shopify vs custom.

Which of these stacks Türkiye's popular sites actually run, measured across 162 home pages, is in Next.js vs WordPress.

Why "custom is more secure" stopped being automatic

The security argument is usually made with a shrug: WordPress runs 40.7% of all websites, so it is what attackers target. That number is real — W3Techs measured it on 5 September 2026 across a sample of more than 20 million sites, and it puts WordPress at 58.9% of all sites whose CMS is known. But being a target is a fact about attention, not about defence, and July 2026 gave us a much better test.

Two vulnerabilities in WordPress core, CVE-2026-60137 and CVE-2026-63030, could be chained into unauthenticated remote code execution on default installations. CISA added both to its Known Exploited Vulnerabilities catalog on 21 July 2026 and gave federal agencies deadlines of 24 July and 4 August. This is the catalogue of vulnerabilities confirmed to be exploited in the wild, and it is worth knowing that of its 1,695 entries only six concern WordPress at all — the other four are plugins and a hosting panel, added years earlier.

So core was genuinely, seriously breached. Now the part that the security argument never mentions: WordPress shipped 7.0.2 on 17 July, before the catalogue entry, and the WordPress.org team force-enabled automatic updates for every affected version. Sites that had never been logged into were patched by the project itself.

No custom application has that. If a chained RCE lands in a dependency of your bespoke Node site, the fix reaches you when someone reads the advisory, and it ships when someone deploys. The honest comparison is not "WordPress is attacked and custom is not". It is that WordPress carries more incoming risk and a real mechanism for closing it, while custom code carries less incoming risk and no mechanism at all.

The obligation nobody prices

Deferred maintenance is measurable, and it should decide more of these conversations than performance ever does. WordPress.org publishes the version distribution of installations that check in with its update service, and PHP publishes which of its branches still receive security fixes. Put them together as of September 2026:

• 38.7% of WordPress installations run a PHP version with no security support. PHP 8.1 and everything below it is end of life; 17.1% of installations are still on PHP 7.4, which stopped receiving fixes in 2022.
• 32.4% run WordPress 6.9 or older, against 51.8% on the current 7.1 branch.
• PHP 8.2, which 24.8% of installations use, leaves security support on 31 December 2026.

None of that is an argument against WordPress. It is a measurement of what "we'll keep it updated ourselves" turns into across millions of sites, and the same decay happens to custom applications — a Node project with a two-year-old lockfile is in exactly the same position. The difference is that no one publishes that statistic, so it stays invisible until something breaks.

Price the maintenance before you choose the stack. If nobody owns updates in year two, WordPress will tell you loudly through a defacement and a custom build will tell you quietly through a dependency you can no longer upgrade.

The question that actually decides it

Strip out performance and security and one question is left standing: who changes the site after launch, and how often?

If the answer is a marketing team publishing pages weekly, rearranging sections, running campaigns and adding case studies, WordPress is usually correct. The editing model is the product. Handing that team a headless CMS with a bespoke admin means paying to rebuild, badly, the thing WordPress spent twenty years getting right.

If the answer is that content changes a few times a year and what matters is behaviour — a quoting engine, a configurator, a member area, an integration with your ERP — custom is usually correct. You would be writing that behaviour as a plugin anyway, and a plugin is custom code with a CMS underneath it that you still have to maintain.

There is a third answer worth naming: nobody. Plenty of sites are published, then touched twice in five years. For those, the stack barely matters and the hosting matters enormously, which is what the TTFB data above is telling you.

Where we say no

We do not think WordPress is beneath us and we do not recommend it by default either. Two honest limits on our own advice:

We will not build a WordPress site for a client who needs a genuinely custom workflow and wants it done with plugins. That path looks cheaper for about six months, and then every upgrade becomes a negotiation between four vendors who have never met.

We will not build a custom site for a client whose real requirement is publishing. We have seen that decision made for the right technical reasons and it still fails, because the marketing team ends up asking a developer to change a heading. If your bottleneck is editorial throughput, a framework will not fix it.

The full picture of how we scope either one is in our website development guide. If you want a straight answer for your specific case, tell us what the site has to do and we will say which one we would build and why — including when the answer is a platform we do not sell.

Deciding in an afternoon

Answer these five, in order. The first one that produces a clear answer usually ends the discussion.

1. Who edits, and how often? Weekly by non-developers points to WordPress. Rarely, by us, points to custom.
2. Is the value in pages or in behaviour? Pages point to WordPress. Behaviour points to custom.
3. Who owns updates in year two, and is it budgeted? If the answer is nobody, choose the option with forced auto-updates and managed hosting.
4. What does the site do at its worst moment? A campaign spike on a cached WordPress page is fine. A configurator doing live pricing is not a page-caching problem.
5. Can you hire a replacement? WordPress, at W3Techs' measured 40.7% of the web, has a deep labour market. A bespoke stack has yours, and whoever you can persuade to inherit it.

Run those honestly and the two stacks stop competing. They are answers to different questions, and the reason the comparison feels hard is that most articles about it are arguing performance — a case the field data does not support in either direction.