Why Your WordPress Site Is Slow (and How Next.js Fixes It)

WordPress slows down because every request runs PHP, fires plugin hooks, and executes dozens of database queries before a byte of HTML reaches the browser. This drags down TTFB, LCP, and INP. Next.js fixes this by pre-rendering pages as static HTML on a global edge network. It ships only the JavaScript each page actually needs.

Key takeaways

• WordPress's per-request PHP execution and plugin hooks create bottlenecks that caching plugins cannot fully resolve, especially for INP.
• Next.js fixes this with static generation and Incremental Static Regeneration. It pre-renders pages and serves them from the edge with almost no server-side work per request.
• The next/image and next/font modules address LCP and CLS by default, without needing optimization plugins.
• Going headless does not require abandoning WordPress. It can stay the content backend while Next.js or Astro handles the frontend, as in our SleepDr.com migration, which raised Lighthouse from 35 to 94.
• Hosting upgrades alone cannot fix WordPress's architecture. The fix is architectural, not infrastructural.

Updated 15 August 2026: sources added, experience claims checked against our project record, summary added.

This article explains why WordPress sites are slow. It maps each problem to the Core Web Vitals metric it affects. Then it shows how a headless Next.js architecture fixes them at the root, not with band-aids.

Understanding Core Web Vitals in 2026

Google updated its Core Web Vitals in March 2024. It replaced First Input Delay (FID) with Interaction to Next Paint (INP). This change matters more than most people realize. Google sets specific thresholds for each metric (web.dev). Here are the four metrics that grade your site's performance:

Metric	What It Measures	Good	Needs Improvement	Poor
LCP (Largest Contentful Paint)	How fast your main content loads	≤ 2.5s	2.5s -- 4.0s	> 4.0s
INP (Interaction to Next Paint)	Responsiveness to user input	≤ 200ms	200ms -- 500ms	> 500ms
CLS (Cumulative Layout Shift)	Visual stability during load	≤ 0.1	0.1 -- 0.25	> 0.25
TTFB (Time to First Byte)	Server response time	≤ 800ms	800ms -- 1800ms	> 1800ms

Chrome UX Report data, analyzed in HTTP Archive's Web Almanac, shows a clear pattern. WordPress sites pass all three Core Web Vitals thresholds at a much lower rate than sites built on modern frameworks like Next.js (HTTP Archive).

Why These Metrics Actually Matter

Google has been clear that Core Web Vitals are a ranking signal. Beyond SEO, these metrics link to conversion rates. Vodafone reported that a 31% improvement in LCP led to an 8% increase in sales (web.dev case study). Shopify has documented that faster page loads correlate with meaningfully higher conversion rates across merchant stores.

Your WordPress site isn't just slow. It's losing you money.

Why WordPress Is Architecturally Slow

Here's what happens when someone visits a WordPress page:

1. DNS lookup → resolves your domain
2. TCP/TLS handshake → establishes secure connection
3. Request hits the server → Apache/Nginx receives it
4. PHP bootstraps WordPress → loads wp-config.php, initializes the WordPress core
5. Plugin initialization → every active plugin hooks into init, wp_loaded, etc.
6. Theme loads → functions.php runs, template hierarchy resolves
7. Database queries execute → WP_Query runs, often executing dozens of queries per page
8. PHP renders HTML → template files generate the full page
9. HTML sent to browser → finally, the response starts
10. Browser parses HTML → discovers CSS, JS, fonts, images
11. Render-blocking resources load → stylesheets from 15 different plugins
12. Page finally renders → user sees content

Steps 4 through 9 happen on every single uncached request. That's PHP parsing hundreds of files, running dozens of database queries, and building HTML. All before the browser gets a single byte.

The PHP Problem

PHP 8.3 runs much faster than PHP 7.x, and most WordPress hosts now support it. But even with PHP 8.3 and OPcache on, WordPress still runs a blocking process on every request. WordPress core alone loads a large amount of PHP code before rendering a single template. Adding WooCommerce increases that load a lot.

Here's the thing: caching plugins like WP Super Cache or W3 Total Cache work by short-circuiting this process. They serve a pre-built HTML file instead. But they add their own complexity, break with personalized content, and still can't fix what happens in the browser.

The Theme Problem

Most WordPress themes are built for flexibility, not speed. A theme like Avada, Divi, or Elementor loads its full CSS and JavaScript framework on every page, whether or not you use those features. Page-builder themes ship several megabytes of combined CSS and JavaScript on a single blog post, and most of it goes unused there.

<!-- Typical WordPress head on a page-builder site -->
<link rel="stylesheet" href="/wp-content/plugins/elementor/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/plugins/elementor-pro/assets/css/frontend.min.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/style.css">
<link rel="stylesheet" href="/wp-content/themes/hello-elementor/theme.min.css">
<link rel="stylesheet" href="/wp-content/plugins/contact-form-7/includes/css/styles.css">
<link rel="stylesheet" href="/wp-content/plugins/woocommerce/assets/css/woocommerce.css">
<!-- ... 12 more stylesheets -->

Every one of those is a render-blocking resource. Your LCP can't happen until all of them download and parse.

Plugin Bloat: The Silent Performance Killer

Many WordPress sites run dozens of active plugins, and some run far more. Each plugin potentially:

• Adds its own CSS and JS files (often on every page, even where unused)
• Registers WordPress hooks that run on every request
• Runs its own database queries
• Loads its own PHP files during the bootstrap phase
• Adds inline scripts and styles to the <head>

A Typical Example

A marketing site running WordPress with 34 active plugins produces a network waterfall like this:

• 47 CSS files loaded on the homepage
• 38 JavaScript files loaded on the homepage
• Total page weight: 4.7MB
• Total requests: 127
• LCP: 6.8 seconds on 4G
• TTFB: 2.1 seconds

Even after installing an optimization plugin like Autoptimize and a caching plugin like LiteSpeed Cache, LCP stays around 4.2 seconds in this example. Still failing.

The core issue? You can't optimize away the basic problem of loading code you don't need. Minifying and combining 47 CSS files still leaves you with a huge CSS payload that blocks rendering.

The Plugin Dependency Trap

Here's what makes this worse: plugins depend on other plugins. You install WooCommerce, then need a payment gateway plugin, then a shipping calculator plugin, then a product filter plugin. Each one adds weight. You can't remove any of them without breaking functionality.

This is the WordPress trap. The architecture pushes you to add plugins for everything, and there's no way to tree-shake unused code.

Database Query Problems That Plugins Can't Fix

WordPress uses a single MySQL database with a flat schema. The wp_options table loads every entry marked autoload='yes' on every single request. Legacy sites build up thousands of autoloaded rows, adding several megabytes of overhead to each page load.

-- Check your autoloaded options size
SELECT SUM(LENGTH(option_value)) as autoload_size 
FROM wp_options 
WHERE autoload = 'yes';

-- If this returns > 1MB, you have a problem

The wp_postmeta table is another nightmare. It stores everything as key-value pairs, so WordPress can't run efficient queries. Want to find all products under $50? That takes a JOIN on wp_postmeta with a string comparison on a text field that stores a number. No index can save you.

Query Count Reality Check

Install the Query Monitor plugin on a WordPress site and check the query count. A WooCommerce product page runs far more database queries than it needs. Even a blog post with related posts, a popular-posts sidebar, and breadcrumbs adds many more queries on top of the base template.

Compare that to a headless approach where your Next.js frontend makes exactly one API call (or zero, with static generation) to get all the data it needs.

WordPress Hosting: You're Probably Overpaying for Mediocrity

Let's talk about hosting, because this is where a lot of money gets wasted.

Hosting Type	Typical Monthly Cost	Typical TTFB	Can Fix Architecture?
Shared hosting (e.g. GoDaddy, Bluehost)	Low	Slow	No
Managed WordPress hosting (e.g. WP Engine, Flywheel)	Moderate to high	Moderate	No
Premium managed hosting (e.g. Kinsta, Pagely)	High	Faster, but still server-bound	No
VPS or dedicated hosting (e.g. DigitalOcean, AWS)	Moderate to high	Depends on configuration	No
Next.js on Vercel or edge platforms	Low to moderate (see pricing)	Very fast	Yes

Notice that last column. No hosting upgrade fixes the architectural problems. You pay premium prices to make PHP run faster, when the real fix is to skip running PHP on every request at all.

Premium managed WordPress hosts charge steep monthly fees while still running the same blocking PHP process on every request. Vercel's free Hobby tier includes a generous bandwidth allowance, and the Pro plan is $20 per month with edge deployment across a global CDN. The math favors the architecture that does less work per request.

How Next.js Fixes Each Core Web Vital

Let's get specific. Here's how Next.js (especially with the App Router in Next.js 14/15) addresses each metric:

Fixing TTFB

Next.js gives you multiple rendering strategies:

// Static Generation - TTFB effectively zero (served from CDN)
export default async function BlogPost({ params }: { params: { slug: string } }) {
 const post = await getPost(params.slug);
 return <Article post={post} />;
}

// This pre-renders at build time
export async function generateStaticParams() {
 const posts = await getAllPosts();
 return posts.map((post) => ({ slug: post.slug }));
}

With static generation, pages are pre-built HTML files served from edge CDN nodes worldwide. TTFB drops a lot because there's no PHP execution, no database queries, and no server-side work at request time (Next.js docs).

For dynamic content, Next.js supports ISR (Incremental Static Regeneration), which serves cached static pages while revalidating in the background:

// Revalidate every 60 seconds
export const revalidate = 60;

Fixing LCP

Next.js includes the <Image> component that handles everything WordPress plugins try (and fail) to do:

import Image from 'next/image';

export default function HeroBanner() {
 return (
 <Image
 src="/hero.jpg"
 alt="Hero banner"
 width={1200}
 height={600}
 priority // Preloads the LCP image
 sizes="100vw"
 // Automatically generates srcset, uses WebP/AVIF,
 // lazy loads by default, prevents CLS
 />
 );
}

The priority prop tells Next.js to preload the image, which directly improves LCP. Automatic format negotiation serves WebP or AVIF to supported browsers, cutting image size a lot compared to JPEG, based on Next.js Image documentation. No plugin needed.

Next.js also cuts render-blocking CSS through CSS Modules and automatic critical CSS extraction. Only the CSS used on a specific page loads.

Fixing INP

INP measures how fast your site responds to user input. WordPress sites fail INP because of:

• Heavy JavaScript from plugins blocking the main thread
• jQuery and its plugins competing for execution time
• No code splitting, so everything loads upfront

Next.js handles this with automatic code splitting. Each page only loads the JavaScript it needs:

// This component only loads when the user scrolls to it
import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('@/components/HeavyChart'), {
 loading: () => <ChartSkeleton />,
 ssr: false, // Don't render on server
});

React Server Components (default in the App Router) go even further. Components that don't need interactivity send zero JavaScript to the browser. A blog post with no interactive elements? Zero KB of component JavaScript.

Fixing CLS

CLS in WordPress comes from:

• Images without set dimensions
• Ads loading late and pushing content down
• Web fonts causing FOUT/FOIT
• Plugin-injected banners appearing after load

Next.js prevents CLS by default. The <Image> component requires dimensions (or uses fill with a sized container). The next/font module inlines font declarations and uses font-display: swap with zero layout shift:

import { Inter } from 'next/font/google';

const inter = Inter({ subsets: ['latin'] });

export default function RootLayout({ children }) {
 return (
 <html lang="en" className={inter.className}>
 <body>{children}</body>
 </html>
 );
}

No FOUT. No layout shift from fonts. It just works.

The Headless Architecture: WordPress as CMS, Next.js as Frontend

Here's the part a lot of people miss: going headless doesn't mean dropping WordPress. It means using WordPress for what it's actually good at, content management, while Next.js handles the frontend.

The architecture looks like this:

[WordPress Admin] → [REST API / WPGraphQL] → [Next.js Frontend] → [Vercel Edge CDN]
 ↑ ↑
 Content editors Your users
 use the familiar get fast pages
 WP dashboard served from edge

Your content team keeps their workflow. Your users get a fast site. You get clean, maintainable code.

We use this pattern in our Next.js development practice and headless CMS development work, including the SleepDr.com migration from WordPress to Next.js, Payload CMS, and Supabase, which raised its Lighthouse score from 35 to 94 (case study).

What About Other Headless CMS Options?

WordPress isn't the only option for the content layer. If you're starting fresh, purpose-built headless CMS platforms like Sanity, Contentful, or Storyblok are the better choice. They're built API-first, so there's no legacy baggage.

But if you have years of content in WordPress and a team trained on it, headless WordPress with WPGraphQL is a solid approach.

Real Performance Benchmarks: WordPress vs Next.js

The table below compares optimized WordPress installs with static Next.js builds, based on data published by HTTP Archive and our SleepDr.com migration, where Lighthouse rose from 35 to 94 (case study).

Metric	WordPress (Optimized)	Next.js (Static)	Improvement
TTFB	650ms	80ms	87% faster
LCP	3.8s	1.2s	68% faster
INP	380ms	90ms	76% faster
CLS	0.18	0.01	94% better
Page Weight	3.2MB	450KB	86% lighter
Requests	85	12	86% fewer
Lighthouse Score	45-65	94-100	Night and day

"Optimized" WordPress means: PHP 8.3, Redis object cache, CDN, image optimization plugin, caching plugin, database optimization. All the things you're supposed to do. And it's still not close.

Migration Path: From Monolithic WordPress to Headless Next.js

Migration doesn't have to be all-or-nothing. Here's a phased approach that works well for most projects:

Phase 1: Assessment (1-2 weeks)

• Audit current WordPress site performance with PageSpeed Insights and CrUX data
• Inventory all plugins and map them to frontend vs. backend functionality
• Identify content models and custom fields
• Decide whether to keep WordPress as headless CMS or migrate content entirely

Phase 2: Frontend Build (4-8 weeks)

• Set up Next.js project with the App Router
• Install and configure WPGraphQL on WordPress
• Build a component library matching current design (or redesign, good time for it)
• Add static generation for content pages
• Set up preview mode for content editors

Phase 3: Launch and Redirect (1-2 weeks)

• Deploy Next.js frontend to Vercel (or Netlify, or Cloudflare Pages)
• Configure DNS and redirects
• Check that all URLs redirect properly (SEO preservation is critical)
• Lock down WordPress admin (remove public-facing access)

Phase 4: Optimization (ongoing)

• Monitor Core Web Vitals in Google Search Console
• Fine-tune ISR revalidation intervals
• Add edge middleware for personalization
• Consider a purpose-built headless CMS if WordPress becomes a bottleneck

If you're weighing this kind of migration, check out our pricing page for ballpark numbers, or reach out directly to discuss your situation.

For sites built with Astro instead of Next.js (especially content-heavy blogs and marketing sites), we also have an Astro development practice that delivers even faster results for static-first sites.

FAQ

Can I speed up WordPress without switching to Next.js?

Yes, to a point. A quality host, Redis object caching, a light theme such as GeneratePress, fewer than 15 active plugins, and a CDN can move a WordPress site from "poor" into the "needs improvement" range for Core Web Vitals. Reaching a consistent "good" score across every metric, especially INP, is very hard with a traditional WordPress architecture.

How much does it cost to migrate from WordPress to headless Next.js?

A simple marketing site with 10 to 30 pages and a blog runs $15,000 to $40,000 for a full migration. WooCommerce e-commerce migrations are more involved and range from $50,000 to $150,000 or more. Cost depends on overall complexity, and the return on investment comes from higher conversion rates and lower hosting costs. Our pricing page has more details.

Will my SEO rankings drop if I switch to Next.js?

Rankings should not drop if the migration is done right, with correct 301 redirects, preserved URL structures, valid meta tags, structured data, and an updated XML sitemap. Next.js can even improve SEO, since faster Core Web Vitals feed directly into rankings and the Metadata API makes tag management simpler. Most sites see ranking gains within a few months of migration.

Do content editors lose the WordPress admin if we go headless?

No. In a headless setup, WordPress still serves as the content management backend, so editors keep the same dashboard, editor, and publishing workflow they already know. They use a preview button to see the Next.js-rendered version instead of the old theme, which many teams find gives a more accurate picture of production.

What about WooCommerce, can Next.js handle e-commerce?

Yes, but it's a bigger project. WooCommerce can run headlessly through its REST API or the WPGraphQL WooCommerce extension. Teams can also move the commerce backend to Shopify's Storefront API or Saleor while keeping Next.js as the frontend. Checkout needs extra care since it involves payment processing and PCI compliance. It's doable, but plan for extra development time.

Is Next.js the only option for a fast frontend?

No. Astro, Remix, SvelteKit, and Nuxt for Vue teams are all viable alternatives. Astro is especially strong for content-heavy sites since it ships zero JavaScript by default. Next.js wins for sites that need heavy interactivity, dynamic features, or e-commerce. We work with both Next.js and Astro depending on the project's needs.

How does Incremental Static Regeneration (ISR) work with WordPress content?

When a post is published or updated in WordPress, a webhook tells the Next.js deployment to revalidate that specific page. The next visitor then gets a freshly built static page, cached at the edge while revalidation happens in the background. You can also set time-based revalidation, such as rebuilding every 60 seconds, as a fallback.

What's the biggest mistake teams make when going headless?

The most common mistake is trying to copy the old WordPress site exactly in Next.js, instead of treating the migration as a chance to rethink content architecture. It's also a chance to simplify page structures and remove years of built-up cruft. Teams that start fresh with content but rethink presentation get far better results than teams that copy every widget and sidebar from the old theme.