Back to home

Why we build this way

Headless CMS vs WordPress

Every project we ship uses a Headless CMS with a Next.js frontend, rendered with SSR or SSG. Here's why that beats a traditional WordPress build — and what those acronyms actually mean.

How each request is handled

SSG
BrowserCDN EdgeglobalPre-built HTMLinstant
SSR
BrowserEdge fnserverlessHTML~20ms
WordPress
BrowserApache/NginxPHPMySQLTemplateHTML400–800ms

WordPress fires PHP and a database query for every uncached visit. Caching plugins (WP Rocket, W3 Total Cache) help, but cold-starts and plugin overhead create a performance ceiling you'll eventually hit under real traffic.

Performance benchmarks

Typical uncached install — Vercel/Netlify-hosted Next.js vs. shared-hosting WordPress.

TTFBTime to First Byte

How long before the browser receives the first byte of HTML. Under 200ms is Google's target.

Headless
120ms
WordPress
600ms
LCPLargest Contentful Paint

When the main visible content finishes rendering. Core Web Vitals target: under 2.5s.

Headless
1.1s
WordPress
3.2s
PerfLighthouse Performance

Google's composite performance score. Below 50 hurts SEO rankings.

Headless
95/100
WordPress
55/100
SEOLighthouse SEO

Checks for crawlability, metadata, structured data, and mobile-friendliness.

Headless
98/100
WordPress
82/100
TTITime to Interactive

When the page first responds to user clicks. High TTI means the page looks loaded but is still frozen.

Headless
1.8s
WordPress
4.5s

Glossary

What these terms actually mean, in plain language.

SSGStatic Site Generation

Pages are pre-built as plain HTML files at deploy time. The server does nothing at request time — visitors get a file straight from the CDN. Fastest possible delivery.

SSRServer-Side Rendering

HTML is generated on the server (or a serverless edge function) for each request, then sent to the browser. Next.js can do this in ~20ms from a global edge network without touching a database.

CDNContent Delivery Network

A global network of servers (Vercel Edge, Cloudflare, Fastly) that caches your files and serves them from the location closest to the visitor. Eliminates round-trip latency to a single origin.

TTFBTime to First Byte

The time from when a browser sends a request to when it receives the first byte of the response. Google uses TTFB as a ranking signal — under 200ms is the target.

LCPLargest Contentful Paint

When the largest visible element (usually a hero image or headline) finishes rendering. One of Google's Core Web Vitals. Under 2.5s = Good; over 4s = Poor.

TTITime to Interactive

When the page can reliably respond to user input. A page can look fully loaded (LCP done) but still be frozen while JavaScript initialises — TTI captures that gap.

Headless CMSHeadless CMS

A content management system that stores and manages content via a structured API, with no built-in frontend. You connect it to any frontend (Next.js, mobile app, etc.). Examples: Sanity, Contentful, Payload.

Side-by-side comparison

How a page is delivered

Headless CMS

SSG: pre-built HTML served instantly from a CDN edge node near the visitor. SSR: HTML generated on a serverless edge function in ~20ms with no database call.

WordPress

PHP runs on every uncached request — queries the MySQL database, loads plugins, renders the template, then sends HTML. Each step adds latency.

Database calls per request

Headless CMS

Zero at request time — content is fetched at build time (SSG) or cached at the CDN edge (SSR). The database is never on the critical path.

WordPress

Typically 10–40 queries per page load: posts, meta fields, widgets, menus, sidebar content. Each round-trip to MySQL adds time.

Plugin surface and security

Headless CMS

The CMS API is the only surface exposed. Frontend and content are fully decoupled — a compromised plugin can't inject code into your live site.

WordPress

30+ plugins is a typical install. Each plugin is a potential attack vector. Plugins share the PHP process, so one bad one can affect the whole site.

Scaling under traffic spikes

Headless CMS

Static files and CDN edge caches absorb any spike for free — no origin server involved. Serverless functions auto-scale with zero configuration.

WordPress

The origin server and database handle every request. Needs WP Rocket + caching layer + autoscaling + a database that can keep up. Still fails under sudden spikes.

Editor experience

Headless CMS

Structured content in a purpose-built CMS (Sanity, Contentful) with typed schemas, real-time previews, and no risk of theme drift from plugin updates.

WordPress

WYSIWYG block editor is tightly coupled to the active theme and installed plugins. Visual layout can break whenever a plugin or theme updates.

Hosting cost at scale

Headless CMS

Static hosting (Vercel, Netlify) has a generous free tier and scales to zero. Serverless functions only cost when invoked.

WordPress

Requires an always-on server and managed database. Costs scale linearly with traffic — a viral moment means a surprise bill or downtime.

Want to see it in action?

Tell us about your project and we'll explain how our stack fits your needs.