Most WordPress sites can pass Core Web Vitals with configuration alone: better hosting, caching, image optimization, and script deferral typically fix LCP and INP within weeks. Replatform only when you've done those fixes, spent real money, and field data still fails -- that signals an architecture problem, not a configuration one, and headless WordPress or a full rebuild becomes worthwhile.

Key takeaways

  • WordPress's Core Web Vitals reputation is mostly a hosting problem: HTTP Archive data shows most WordPress sites pass INP but fail on TTFB, which drives LCP.
  • Work through hosting, caching, image, and JavaScript fixes before considering a rebuild -- most sites reach green with configuration changes alone.
  • Replatform only when you hit two or more signals: heavy optimization spend with no field-data improvement, TTFB stuck above 800ms even on managed hosting, or every plugin update pushing a metric back to red.
  • Headless WordPress with a Next.js or Astro frontend can push LCP under 1 second and INP near 50ms once the bottleneck is architecture rather than configuration.
  • Budget accordingly: optimizing an existing install typically runs $1,500-$4,000, while a headless rebuild runs $25,000-$80,000 and tends to pay back in 12-18 months when the replatform signals are real.

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

The question isn't "is WordPress slow?" WordPress isn't slow. Bad WordPress is slow. The real question is: can your install pass LCP under 2.5s and INP under 200ms with configuration alone, or have you hit the ceiling where every fix is a fight and a replatform actually pays for itself? This article gives you a decision tree instead of a lecture.

WordPress Slow? Real Fixes vs Replatform Decision Tree (2026)

What the CrUX Data Actually Says

CrUX data shows that WordPress doesn't actually have an INP problem. Across HTTP Archive's CMS Core Web Vitals data, WordPress sites pass INP at around 85.9%, only marginally below the web average. The actual failure point is LCP, and LCP is mostly driven by TTFB.

Only about 32% of WordPress sites have good TTFB in CrUX, compared with fully hosted platforms like Shopify, where server response is handled at the infrastructure level. That gap explains most of the reputation problem: WordPress's Core Web Vitals name is largely a hosting problem. Shared hosting with no page caching regularly serves TTFB above 800ms. Managed hosting with server-level caching and a CDN can bring that under 200ms.

In practice, moving from unoptimized shared hosting to managed hosting with caching and image fixes typically takes mobile LCP from the 3.5-4.5s range down to 1.6-2.1s within weeks. The single highest-impact change is almost always moving from shared hosting with no caching to managed hosting with a CDN. Everything else is refinement.

So before ripping out the stack, understand what you're actually fighting.

The Three Metrics That Matter in 2026

Google's thresholds haven't moved, and mobile Core Web Vitals remain a primary field ranking signal:

Metric What it measures Good Needs work Poor
LCP Largest Contentful Paint -- when the main content renders ≤ 2.5s 2.5-4.0s > 4.0s
INP Interaction to Next Paint -- responsiveness to clicks/taps ≤ 200ms 200-500ms > 500ms
CLS Cumulative Layout Shift -- visual stability ≤ 0.1 0.1-0.25 > 0.25

INP replaced FID in March 2024, and it's a much harsher measure. It looks at the worst interaction latency across the whole session, not just the first input. That's why plugin-heavy WordPress sites with chat widgets and page builders show up amber even when the page "feels" fine on desktop.

Prioritize in this order: LCP first (biggest impact on perceived speed, and the metric WordPress fails most), then INP (third-party scripts and blocking JS), then CLS (dimensions and fonts). If all three fail simultaneously, the culprit is almost always hosting or the theme -- fixing the root cause improves all three at once.

Root Causes: Why WordPress Fails

Slow WordPress sites usually trace back to a short list of causes. Here's how to recognize them.

Page builder bloat

Elementor, Divi, and WPBakery inject a large number of blocking resources per page, even when you're only using a couple of blocks. That blocking CSS in the head torpedoes LCP, and the heavy builder JavaScript sits on the main thread wrecking INP. This is the single biggest architectural problem, and it's the one you can't fully fix without leaving the builder.

Plugin sprawl

Every plugin that registers a script via wp_enqueue_scripts loads that script on every page by default. A site with 40 plugins can inject 25 scripts and 15 stylesheets on the homepage when it genuinely needs five. Sliders, popups, chat widgets, and analytics all pile onto the main thread.

Unoptimized images

No WebP or AVIF, no lazy loading below the fold, no width/height attributes, no srcset. It's common to see 3-4MB hero images where 250-300KB would look identical on any screen. The browser downloads exactly what you uploaded, and no plugin magically shrinks a file you never compressed. This is the number-one LCP killer and a very common CLS cause.

Slow hosting

Covered above, but worth repeating: this is the root of most LCP failures because TTFB feeds directly into LCP.

Render-blocking fonts and CSS

Web fonts loaded without font-display: swap, Google Fonts pulled from a third-party origin, and megabytes of CSS in the critical path all delay the first meaningful paint.

WordPress Slow? Real Fixes vs Replatform Decision Tree (2026) - architecture

The Real Fixes (Do These First)

Before requesting a replatform quote, work through this list. Most sites don't need a rebuild -- they need someone to actually do the work.

1. Upgrade hosting and enable server-level caching

This is the highest-leverage move. Managed WordPress hosts (Kinsta, WP Engine, Cloudways with Nginx caching) give you page caching at the server, Redis object caching, and HTTP/3 out of the box. Expect TTFB to drop from 800ms+ to under 200ms.

2. Put Cloudflare in front

Enable Brotli compression, HTTP/3, and cache-everything rules for static assets. Cloudflare's edge network shaves latency off TTFB and can handle image optimization if you're on a paid plan.

3. Fix the LCP image properly

Shrink it before upload. Serve WebP or AVIF. Set explicit width and height. And critically -- do not lazy-load your LCP image. Preload it instead:

<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">

4. Defer and delay non-critical JavaScript

Chat widgets, analytics, sliders, and popups don't need to run before the page is interactive. WP Rocket's "delay JavaScript execution" or a manual approach works:

<script src="/chat-widget.js" defer></script>

Delay third-party scripts until user interaction. This is the single biggest INP win on most WordPress sites.

5. Generate critical CSS and async-load the rest

Inline the above-the-fold CSS, load the remainder asynchronously. WP Rocket, FlyingPress, and Perfmatters all do this. Test carefully -- aggressive critical CSS breaks layouts.

6. Self-host and preload fonts

<link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossorigin>

Add font-display: swap so text renders immediately in a fallback while the web font loads.

7. Switch to a lightweight theme

If you're on a bloated multipurpose theme, moving to GeneratePress, Astra, or Kadence -- or better, a custom Sage/Tailwind theme -- removes a huge chunk of blocking CSS and JS. This is more invasive but still cheaper than replatforming.

8. Add object caching and trim the plugin list

Redis object caching, optimized WP_Query calls, and killing plugins you don't use all help TTFB and INP. Audit every plugin's site-wide script injection with a tool like Perfmatters' script manager to selectively disable scripts per page.

Do all eight and most WordPress sites land in the green. If they don't -- that's your signal.

The Replatform Decision Tree

Here's a framework for the decision. Once you've done the real fixes above, ask these questions in order.

Signal 1: You've spent more than $3,000 on optimization and field data is still amber. You've upgraded hosting, added a CDN, optimized images, delayed JS, generated critical CSS -- and CrUX still shows amber LCP or INP after 28 days. You're past the point of diminishing returns.

Signal 2: Peak-hour TTFB won't drop below 800ms even after changing hosting. If your database and PHP execution are so heavy that even managed hosting chokes during traffic spikes, the architecture is the problem. Heavy WooCommerce with complex queries is the classic case here.

Signal 3: Every new plugin sends a metric back to red. If your team can't add a feature without breaking performance, you don't have a performance problem -- you have a fragility problem. The stack can't absorb change.

If you hit one of these, keep optimizing but start planning. If you hit two or three, a migration typically pays for itself in 12-18 months through hosting savings, recovered conversion, and technical SEO gains.

Here's the flow in plain terms:

Is LCP > 2.5s or INP > 200ms in CrUX (28-day)?
├── No  → You're fine. Monitor and move on.
└── Yes → Have you done the 8 real fixes?
          ├── No  → Do them. Re-measure in 28 days.
          └── Yes → Are you hitting 2+ replatform signals?
                    ├── No  → Refine: theme swap, plugin audit, custom templates.
                    └── Yes → Replatform. Headless WP or full rebuild.

A common mistake: teams jump straight to "let's rebuild in Next.js" before enabling page caching. Fix what you have first -- a rebuild that inherits the same bad image workflow will be slow too.

What Replatforming Actually Costs

Let's talk real numbers, because "it depends" helps nobody.

Approach Typical cost Timeline LCP outcome INP outcome
Optimize existing WP $1,500-$4,000 1-3 weeks 1.6-2.1s ~150ms
Custom lightweight theme $6,000-$15,000 3-6 weeks 1.4-1.9s ~120ms
Headless WP + Next.js/Astro $25,000-$80,000 8-16 weeks < 1.0s < 50ms
Full replatform (new CMS) $40,000-$150,000+ 12-24 weeks < 1.0s < 50ms

Those LCP and INP figures for headless aren't marketing. A static or server-rendered frontend with WordPress as a headless CMS routinely takes LCP under 1 second and INP to around 50ms with almost no effort. That's because you've eliminated the theme, the page builder JS, and the PHP render on every request.

A real example: our SleepDr.com rebuild moved a sleep medicine practice's site from WordPress to Next.js 15 with Payload CMS and Supabase, taking the Lighthouse score from 35 to 94. That's a full replatform story -- but most WordPress sites don't need that if configuration is the real problem.

The trade-off with replatforming is real and worth stating plainly: cost, complexity, and losing the live visual editing your marketing team knows. If your content team lives inside Elementor's visual editor, moving to headless changes their workflow. That's a people cost, not just a technical one.

Headless WordPress: The Middle Path

Headless WordPress is the compromise that fits most teams who've hit the ceiling. You keep WordPress as the CMS -- your editors keep the admin they know -- but you serve the frontend from a static or server-rendered app.

The architecture: WordPress exposes content via the REST API or WPGraphQL, and a frontend built with Next.js or Astro consumes it. You render pages at build time or on the edge, so visitors never wait for PHP to boot and query MySQL.

Why it wins on Core Web Vitals:

  • LCP collapses because you serve pre-rendered HTML from a CDN. No TTFB gamble.
  • INP drops because you ship only the JavaScript you wrote, not a page builder's runtime plus dozens of plugin scripts.
  • CLS is trivial to control when you own the markup and set dimensions everywhere.

Astro is a strong default choice for content-heavy marketing sites -- it ships zero JavaScript by default and only hydrates the interactive islands you explicitly mark. Our bdManagedIT rebuild moved a Central-Georgia MSP from WordPress to Astro, Sanity, and Netlify and hit 95+ PageSpeed with zero-JS static pages. For app-like sites with lots of interactivity, Next.js earns its keep. Either way, the headless CMS setup keeps your editorial workflow intact while fixing performance at the architecture level.

The catch: you're now maintaining two things -- WordPress and a frontend app -- plus a build/deploy pipeline. For a small brochure site that's overkill. For a high-traffic site where conversion depends on speed, it's the right call. If you're weighing it, our pricing page breaks down what a headless migration involves, or you can talk to us about your specific CrUX numbers.

A Real Comparison: Optimize vs Rebuild

Let me put two typical scenarios side by side so the decision feels concrete.

Scenario A -- Brochure site, 12 pages, GeneratePress theme, 8 plugins, shared hosting. Current LCP 3.8s, INP 180ms. The fix here is obvious: managed hosting, Cloudflare, image optimization, self-hosted fonts. Budget ~$2,000. Expected result: LCP 1.8s, INP 140ms. Do not replatform. It'd be burning money.

Scenario B -- WooCommerce store, 4,000 products, Elementor, 42 plugins, already on WP Engine. Current LCP 4.6s, INP 340ms. They've already spent $5,000 on optimization. Peak-hour TTFB still hits 900ms. Every seasonal campaign plugin pushes INP back to red. This hits all three replatform signals. Headless WooCommerce or a rebuild is the honest recommendation, and the 12-18 month payback math works because they're losing conversions daily.

The difference isn't the CMS. It's whether the failure is configuration (fixable) or architecture (structural). Diagnose that correctly and the decision makes itself.

FAQ

What is a passing Core Web Vitals score in 2026?

You need LCP ≤ 2.5s, INP ≤ 200ms, and CLS ≤ 0.1, measured on real users over a rolling 28-day window in the Chrome User Experience Report. Lab scores in PageSpeed Insights are useful for diagnosis, but Google ranks on field data. Mobile is the primary signal.

Which Core Web Vitals metric should I fix first on WordPress?

Start with LCP. It fails most often on WordPress and has the biggest impact on perceived speed. Fix image optimization, hosting TTFB, and render-blocking resources first. Once LCP is green, tackle INP (third-party scripts and blocking JS), then CLS (image and font dimensions). If all three fail together, the root cause is usually hosting or the theme.

Can WordPress actually pass Core Web Vitals without a rebuild?

Yes, most sites can. Moving from unoptimized hosting to managed hosting with caching and image work typically takes mobile LCP from the 3.5-4.5s range down to 1.6-2.1s. The rebuild conversation only makes sense once you've done the real fixes, spent meaningful money, and field data is still amber -- the classic sign of an architectural rather than configuration problem.

Why is WordPress slower than Shopify or Wix on Core Web Vitals?

It's mostly a hosting quality issue, not a platform flaw. Only about 32% of WordPress sites have good TTFB in CrUX because so many run on shared hosting with no caching. Shopify and Wix handle server response at the infrastructure level, so every site inherits fast TTFB. Put WordPress on managed hosting with a CDN and the gap largely closes.

How much does it cost to replatform WordPress to headless?

Expect roughly $25,000-$80,000 and 8-16 weeks for a headless WordPress build with Next.js or Astro, depending on complexity and integrations. A full replatform to a different CMS runs higher. Optimizing your existing install first costs $1,500-$4,000 and often gets you into the green -- always try that before quoting a migration.

Does headless WordPress really improve INP?

Significantly, yes. INP on WordPress is usually wrecked by page builder JavaScript and dozens of plugins enqueuing scripts site-wide. A headless frontend ships only the JavaScript you write, so main-thread work drops sharply. Headless builds routinely hit INP under 50ms versus 150-340ms on a typical plugin-heavy install.

Should I lazy-load my hero image to improve LCP?

No -- never lazy-load your LCP element. Lazy loading delays the download of your largest contentful element, which is exactly what LCP measures. Instead, preload it with fetchpriority="high" and lazy-load only the images below the fold. This is one of the most common mistakes in well-intentioned optimization attempts.

When does a WordPress migration actually pay for itself?

When you hit two or more of these: you've spent over $3,000 on optimization with amber field data, peak-hour TTFB won't drop below 800ms even after changing hosting, or every new plugin sends a metric back to red. In those cases the migration typically pays back in 12-18 months through hosting savings, recovered conversion, and technical SEO gains.