What WordPress Was Still Fighting Against
Before the relaunch, I ran the old WordPress site through Google's PageSpeed Insights to get an honest read on where it stood technically, not just visually. (New to these reports? Here's how to read PageSpeed Insights diagnostics.) The scores themselves were reasonable, because Nitropack was doing real work. But the diagnostics underneath told a more specific story:
- Image delivery — flagged with an estimated 407 KiB (mobile) and 520 KiB (desktop) in potential savings from unoptimized images
- Forced reflow — JavaScript triggering layout recalculation mid-load (what forced reflow is), a common symptom in plugin-heavy WordPress builds where multiple scripts are manipulating the DOM independently
- LCP request discovery — the page's largest visible content wasn't being prioritized early enough in the load sequence (why request discovery matters for LCP)
- Network dependency tree warnings, tied to that same load-order problem
- More than 4
preconnect connections — flagged directly by Google's own tooling, which explicitly recommends using preconnects sparingly (how many preconnect hints is too many). This one probably comes from plugin stacking: Nitropack, plus whatever other plugins were running, probably each adding their own preconnect hints without any coordination between them
I walk through the same report, item by item with real data.
PageSpeed Insights diagnostics for the old WordPress site, mobile
PageSpeed Insights diagnostics for the old WordPress site, desktop
Some of these, like image delivery, can be fixed inside WordPress. Others, like forced reflow and the preconnect count, trace back to how a plugin stack assembles a page.
The Real Numbers (Being Honest About What They Show)
Here's the actual before-and-after on mobile, plus where the new site stands on desktop, and I want to be upfront that it isn't a dramatic story.
- Old WordPress site (mobile): Performance 81, Accessibility 94, Best Practices 100, SEO 100
- New Next.js site (mobile): Performance 95, Accessibility 96, Best Practices 100, SEO 100
- New Next.js site (desktop): Performance 99, Accessibility 96, Best Practices 100, SEO 100
PageSpeed scores for the new Next.js site desktop
PageSpeed scores for the new Next.js site mobile
Mobile performance improved from 81 to 95 in our single runs — a 14-point increase. That's encouraging, but a single run on each site doesn't establish how much of that improvement came from the migration itself. PageSpeed scores vary between tests, and Nitropack was already doing legitimate optimization work on the old site. This was never a case of "before was broken, after was perfect" on mobile; the architectural reasons for migrating still matter independently of the score.
On desktop, the new site scores 99. Accessibility improved slightly on mobile too, from 94 to 96.
If the migration were justified purely by the Lighthouse score jump, the mobile number alone would make a fairly weak case. It isn't the main reason I moved. The main reasons are structural, and a single performance score doesn't capture them.
The Real Reasons I Moved
A caching plugin manages symptoms. Static generation removes the cause. Nitropack was doing exactly what a good caching/optimization plugin should do — it was compensating for a page-assembly process that generates real overhead on every request. That's genuinely useful, and it's also a ceiling. It can hide the cost of plugin-driven JavaScript and layout work, but it can't eliminate that cost, because the underlying page is still built the same way underneath the caching layer. A statically generated Next.js site sidesteps the problem at the source: the page is already built ahead of time, so there's no plugin-stack assembly happening on each visit for a plugin to compensate for.
No plugin dependency stack to maintain or break. Every plugin added to a WordPress site is a moving part with its own update schedule, its own compatibility assumptions, and its own way of quietly interacting with every other plugin installed alongside it. The preconnect warning in the diagnostics above is a likely example of that, with several plugins each adding hints that look reasonable alone. A custom-built Next.js site has no plugin stack in that sense. What's running is what was actually written for this site, nothing more, which means there's a much smaller surface area for something to silently degrade over time the way the indexing setting did in Post 1.
Full ownership, closing the loop from Post 2. The custom admin panel in the last post exists so my brother isn't dependent on a developer for basic content control. Leaving WordPress entirely extends that to the infrastructure. There's a smaller surface for a setting like the one in Post 1 to hide in, though a static site can still ship a stray noindex, so checking Search Console stays part of the routine.
Fewer moving parts, more predictable deploys. The Publish/Rebuild flow from Post 2 is part of this too — every content change goes through an explicit rebuild step (what "rebuild to publish" means) rather than going live instantly and unpredictably the way a WordPress save does. That's a small trade-off in immediacy for a real gain in predictability: what gets published is always the result of a deliberate step, not a background plugin interaction nobody remembers making.
When WordPress Is Still the Right Call
To be fair to WordPress, because this isn't a "WordPress is bad" post: it's still a reasonable choice for a lot of situations. If you need a huge plugin ecosystem, a non-technical owner who wants a familiar interface, a tight budget, or you simply don't need custom admin functionality, WordPress remains a legitimate, well-supported option. Plenty of fast, well-run sites are built on it.
Where it's worth reconsidering is closer to what happened here: plugin bloat accumulating over time, recurring performance issues that a caching plugin can only partially paper over, a need for genuinely custom admin tooling, or a situation where technical debt and neglected maintenance have already caused real, measurable damage — as it did for seven months on this site. For the general trade-offs, here's WordPress vs. Next.js with real migration data.
The Whole Arc
A site sat invisible to Google for seven months because of one setting. Fixing it got the site indexed, but a deeper audit found it was still unfinished underneath: placeholder content, broken links, no real design. I rebuilt it with a proper theme and a custom admin panel that gave my brother independent control, and moved it off WordPress onto Next.js, not because the fixes didn't work but because they were solving symptoms of an architecture that would likely keep producing new ones.
You can see the finished result at getcoretech.net.
Related Posts
This is Post 3 of 3 in Rebuilding a Dead WordPress Site: The Full Series, on rebuilding getcoretech.net. Post 1 covers the checkbox that kept the site out of Google. Post 2 covers the audit and the custom admin panel.
Comments
No comments yet — be the first.