Why Your WordPress Site Is Slow (And How Next.js Fixes It)
WordPress is slow because it builds every page from scratch, every time someone visits. Your server runs PHP, hits a database, assembles some HTML, and sends it — on every single request, even when nothing on the page has changed since 2019. Next.js doesn't work that way. It builds the pages once, at deploy time, and serves them from a CDN. That's why Next.js sites load in under a second and WordPress sites spend 800ms just thinking about it.
Why WordPress Is Slow by Design
WordPress was built in 2003. For blogs. Good blogs! Fine blogs! But the architecture hasn't fundamentally changed, and that architecture assumes your server should do all the work every time a visitor shows up.
Every page request triggers a PHP process that queries MySQL, runs a stack of template logic, assembles HTML, and then — finally — sends it. This is fine for a 2003 blog with twelve readers. It's less fine for a business website competing on Google speed benchmarks in 2026.
The HTML for your homepage doesn't change between visits. WordPress rebuilds it every time anyway.
What TTFB Is, and Why WordPress Is Bad at It
TTFB — Time to First Byte — is how long your server takes to respond before the browser gets anything at all. Google's threshold is 800ms. Anything above that and you're already losing.
A shared WordPress hosting plan delivers TTFB of 800ms to 2,000ms on a cold request. Managed WordPress (WP Engine, Kinsta) gets it down to 200ms–600ms with aggressive caching. Next.js on Vercel's edge network: under 50ms.
That's not a gap you close with a caching plugin. That's a different architecture.
The Plugin Problem
The average WordPress site runs 20–30 active plugins. Each one is a potential liability.
A contact form plugin loads its scripts on every page, including pages with no contact form. A slider plugin ships 200KB of JavaScript to someone reading your About page. A security plugin runs database lookups on every single request. A caching plugin promises to fix all of this, then quietly doesn't.
The thing nobody tells you when you install your nineteenth plugin is that each one fires on every page load, regardless of whether it's relevant. You don't have one slow thing. You have twenty things slowing you down a little bit each, compounding into a Lighthouse score in the 40s and a conversion rate that matches.
How Many Plugins Are Too Many?
Performance degrades noticeably above 15–20 active plugins. But the count matters less than how many fire on every request and how poorly they're written.
Deactivating a plugin doesn't always fix the damage either. Some leave orphaned database tables that slow queries long after you've forgotten you ever installed them.
Render-Blocking Scripts
WordPress themes and plugins load stylesheets and scripts in the <head>. The browser can't render anything until those files finish downloading. A typical WordPress install loads 8–15 separate scripts before anything appears on screen.
Lighthouse flags this as "Eliminate render-blocking resources." It's almost impossible to fix inside WordPress without breaking the plugins causing it — a cheerful little catch-22.
Why Caching Plugins Don't Actually Fix This
WP Rocket, Cloudflare, W3 Total Cache — they reduce TTFB by serving cached HTML instead of making the server rebuild the page. That part works. But they don't touch the render-blocking scripts. They don't reduce plugin overhead. They don't change what JavaScript gets sent or when.
A site with 25 plugins and a bloated theme, with a caching layer bolted on top, is still a site with 25 plugins and a bloated theme. You've patched the symptom, not the cause.
What Next.js Actually Does Differently
Next.js is a React framework. It builds pages at deploy time — not request time — and serves them as static files from a CDN. No PHP. No database on the critical path. No per-request server overhead for content that isn't changing.
PHP Rendering → Static Generation
Next.js Static Site Generation (SSG) pre-builds every page when you deploy. The browser gets a complete HTML file in milliseconds. The server isn't doing anything — it's just delivering a file that already exists.
For pages that genuinely need live data — a booking system, a contact form — Next.js uses Server Components or API routes. These run in isolated Node.js functions, not the same monolithic backend WordPress uses for everything including your navigation menu.
Plugin Bloat → Nothing
Next.js doesn't have a plugin ecosystem in the WordPress sense. If you need a contact form, I build a contact form. If you need analytics, I add the script. Nothing runs on pages where it isn't needed. Nothing runs at all that I haven't put there intentionally.
A lean Next.js build sends exactly what each page requires. No more.
Render-Blocking Scripts → Code Splitting
Next.js ships only the JavaScript a page actually uses. It splits code automatically, defers non-critical scripts, and uses next/image for images — lazy-loading, correct sizing, and modern formats like WebP, with no configuration required.
This is why Next.js sites score 90–100 on Lighthouse by default. It's not magic. It's just not doing unnecessary things.
WordPress vs. Next.js: The Numbers
| Metric | WordPress (Shared) | WordPress (Managed) | Next.js on Vercel |
|---|---|---|---|
| TTFB (cold request) | 800ms–2,000ms | 200ms–600ms | 30ms–80ms |
| Lighthouse Performance | 40–65 | 55–75 | 90–100 |
| JavaScript payload | 400KB–1.5MB | 300KB–900KB | 80KB–200KB |
| Core Web Vitals pass rate | Low | Medium | High |
| Plugin overhead | High | High | None |
Managed hosting and caching help. They don't get you to 90+. Getting to 90+ on WordPress requires stripping the site back until it barely resembles a WordPress site any more — at which point you're spending a lot of effort to do a worse version of what Next.js does by default.
Should You Switch?
A rebuild makes sense when:
- Your Lighthouse Performance score is below 70 and caching hasn't moved it
- Core Web Vitals are failing (LCP above 2.5s, CLS above 0.1, INP above 200ms)
- You're running 20+ plugins and the site gets slower with every update
- Your TTFB is above 600ms even on managed hosting
It doesn't make sense if your site is genuinely well-optimised and the problem is actually something else — a hosting misconfiguration, uncompressed images, a bad third-party script you could just remove.
What a Rebuild Costs
A base Next.js site — landing page, contact form, SEO setup — starts at €3,000 and takes around 5 days. Additional pages are €1,000 each. Booking systems, e-commerce, and authentication are fixed-price add-ons.
The rebuild pays for itself when a faster site starts ranking better, converting better, or just stops being the thing you apologise for when you send someone the link.
Frequently Asked Questions
Is Next.js faster than WordPress?
Yes. Significantly. Next.js serves pre-built pages from a CDN with TTFB under 80ms. WordPress builds pages on the server using PHP, with TTFB ranging from 200ms to 2,000ms depending on hosting and how many plugins you've installed.
Why is my WordPress site so slow?
Probably all three of these at once: PHP server rendering on every request, too many plugins adding scripts and database queries to every page load, and render-blocking JavaScript in the <head> before anything can render. Caching helps with the first one. It doesn't fix the other two.
Will a caching plugin fix my WordPress speed?
Partially. It'll improve your TTFB. It won't fix render-blocking scripts, plugin overhead, or your JavaScript payload. You'll go from a 43 on Lighthouse to maybe a 58. Which is still not good.
What is TTFB and why does it matter?
TTFB (Time to First Byte) is how long your server takes to respond before the browser gets anything. Google considers anything above 800ms slow. WordPress on shared hosting regularly delivers TTFB over 1,000ms. Next.js on a CDN typically delivers it under 80ms.
Can I switch from WordPress to Next.js?
Yes. It's a rebuild — your content migrates, your design gets rebuilt properly, and the functionality you need gets built as code rather than installed as plugins. Most rebuilds take 5–15 days depending on complexity.
How much does a Next.js rebuild cost?
A base site starts at €3,000. Additional pages are €1,000 each. Booking systems, authentication, and e-commerce are fixed-price add-ons.
What Lighthouse score should I aim for?
90+. Below 70 and you're failing Core Web Vitals, which is a confirmed ranking factor. Below 50 and you're actively losing visitors who click back before the page loads. A well-built Next.js site reaches 90–100 by default. A well-optimised WordPress site tops out around 75, if you're lucky.
Why do WordPress sites fail Core Web Vitals?
Slow LCP from server TTFB, CLS from fonts and images loading late, INP from too much JavaScript blocking the main thread. These are structural. You can't fully fix them inside WordPress without hollowing the site out until it's basically a static page with extra steps — at which point, just use Next.js.
If you've read this far, you already know what the problem is. The instant quote calculator at /start takes two minutes and involves no phone calls. Go and break it.
People Also Ask
Is Next.js faster than WordPress?
Yes, significantly. Next.js pre-builds pages and serves them from a CDN, delivering TTFB under 80ms. WordPress generates pages on the server using PHP — TTFB ranges from 200ms to over 2,000ms depending on hosting. Caching reduces the gap; it doesn't close it.
Why is my WordPress site so slow?
Almost certainly a combination of three things: PHP server rendering on every request, too many plugins loading scripts and running database queries on every page load, and render-blocking JavaScript in the head before anything can render. Caching helps with the first one. It doesn't fix the other two.
Will a caching plugin fix my WordPress speed?
Partially. WP Rocket and Cloudflare reduce TTFB by serving cached HTML. They don't fix render-blocking scripts or plugin overhead — you'll go from a 43 on Lighthouse to maybe a 58. Which is still not good.
What is TTFB and why does it matter?
TTFB (Time to First Byte) measures how long your server takes to respond before the browser gets anything. Google considers anything above 800ms slow. WordPress on shared hosting regularly delivers TTFB over 1,000ms. Next.js on a CDN delivers it under 80ms.
Can I switch from WordPress to Next.js?
Yes. It's a rebuild — your content migrates, your design gets rebuilt properly, and the functionality you need gets built as code rather than installed as plugins. Most rebuilds take 5–15 days depending on complexity. Your URLs, SEO settings, and content carry over.
How much does a Next.js rebuild cost?
A base site (one page, contact form, SEO) starts at €3,000. Additional pages are €1,000 each. Booking systems, authentication, and e-commerce are fixed-price add-ons.
What Lighthouse score should I aim for?
90+. Below 70 and you're failing Core Web Vitals, which is a confirmed ranking factor. Below 50 and you're actively losing visitors who click back before the page loads. A well-built Next.js site scores 90–100 by default. A well-optimised WordPress site tops out around 75, if you're lucky and you've stripped it back significantly.
Why do WordPress sites fail Core Web Vitals?
Slow LCP from server TTFB, CLS from fonts and images loading late, INP from too much JavaScript blocking the main thread. These are structural problems. You can't fully fix them inside WordPress without hollowing the site out until it's basically a static page with extra steps — at which point, just use Next.js.
