WordPress is Not Dead. But Core Web Vitals are Condemning it

WordPress runs 43% of the web. It’s a statistic that comes up every time someone declares that WordPress is dead, as a definitive argument to close the discussion.

But market share doesn’t measure the quality of the user experience. Google measures that with Core Web Vitals — and here the comparison becomes uncomfortable.

What are Core Web Vitals (and why they really matter)

Since 2021, Google has included three metrics in its ranking algorithm:

LCP (Largest Contentful Paint) — how long it takes to render the main element of the page. Good threshold: under 2.5s.
INP (Interaction to Next Paint) — latency between a user interaction and the visual response. Good threshold: under 200ms.
CLS (Cumulative Layout Shift) — layout shifts during loading. Good threshold: under 0.1.

These are not theoretical metrics. They impact SEO ranking and conversion rate. Amazon estimated that every 100ms of extra latency costs 1% of sales. A slow WordPress isn’t just a technical problem — it’s a business problem.

The structural problem of WordPress

WordPress is a PHP monolith from 2003 that does everything: manages content, builds pages, serves HTML, executes plugins, queries the database — all in the same process, for every single request.

The typical flow of a WordPress page:

HTTP Request
  → PHP starts execution
  → WordPress loads core (~50 files)
  → Activates all plugins (~20-60 typical plugins)
  → Database queries (even 30-50 queries per page)
  → Template engine builds HTML
  → HTML response to browser

Every step adds latency. The average TTFB (Time to First Byte) of an unoptimized WordPress is between 800ms and 2s. A static Astro or Next.js site responds in 20-80ms from an edge CDN.

Caching plugins help, but they are a patch: they hide the problem without solving it, and they break as soon as content changes or the cache is invalidated.

Headless: Separating writer from server

Headless architecture breaks that monolith into two distinct responsibilities:

CMS (WordPress, Contentful, Sanity) — manages only content, exposes a REST or GraphQL API.
Frontend (Astro, Next.js, Nuxt) — consumes the API, generates static HTML at build time, distributes on CDN.

The end user never touches PHP, MySQL, or plugins. They receive pre-generated HTML from the CDN node closest to them — which in Europe can mean 5-15ms of TTFB instead of 800ms.

Numerical comparison on a real project I migrated:

Metric	WordPress + WooCommerce	Headless (Astro + WP API)
TTFB	1.2s	38ms
LCP	4.1s	1.1s
CLS	0.18	0.02
PageSpeed (mobile)	41	94

This isn’t a lab test. It’s production, same content, same basic hosting.

When WordPress still makes sense

Headless architecture isn’t free. It adds complexity:

Build time that can become long on sites with thousands of pages
Content preview is harder to manage
Deployment pipeline needs configuration
Infrastructure cost is higher if managed services aren’t used

For a personal blog, a simple corporate site, or a client who wants to manage everything themselves without ever touching a console: WordPress with a lightweight theme and a CDN in front remains a reasonable choice.

For an e-commerce, an editorial site, or anything where performance affects revenue: the numbers speak for themselves.

Conclusion

WordPress is not dead. But the idea that it is still the default solution for any web project is what should die.

Architecture choice is a technical decision that has measurable SEO, UX, and business consequences. Core Web Vitals have taken that argument away from the level of personal preference and put it on the level of numbers — and numbers don’t lie.