The Headless CMS Pattern

WordPress powers 43% of the web. It is the most battle-tested content management system ever built. It also ships with a PHP frontend that is slow, bloated, and increasingly irrelevant.

We use WordPress every day. We never use its frontend.

What Headless WordPress Means

A headless CMS is a content management system where the admin interface (where you write and manage content) is completely separated from the frontend (what visitors see). The CMS provides content through an API. A separate application — in our case, a custom single-page application — fetches that content and renders it.

WordPress has shipped with a full REST API since version 4.7 (2016). Every post, page, category, media item, and custom field is available as JSON at /wp-json/wp/v2/. Most WordPress sites never use this. They render pages server-side through PHP templates, Elementor blocks, or page builders that generate HTML on every request.

We do the opposite. WordPress handles content creation — the editor, media library, categories, user roles, revision history. Our custom SPA handles everything the visitor sees.

Why We Made This Choice

Performance. A standard WordPress page load involves PHP execution, database queries, template rendering, and plugin processing on every request. A headless setup serves a static HTML shell instantly, then loads content from the API. The difference is measurable: our pages achieve sub-second load times. Most WordPress sites take 3-5 seconds.

Security. WordPress is the most attacked CMS on the internet — not because it’s insecure, but because it’s everywhere. Every plugin, every theme, every PHP file is an attack surface. In our architecture, the WordPress admin is locked behind authentication and not publicly accessible. The only public endpoint is the REST API, which serves read-only JSON. The attack surface is reduced by an order of magnitude.

Design freedom. WordPress themes and page builders constrain your design to what the theme allows. We write our own HTML and CSS with zero constraints. Every pixel is intentional. The CMS doesn’t dictate the design — it provides the content, and our SPA decides how to present it.

Reliability. When a WordPress plugin update breaks a site — and it happens regularly — the entire frontend goes down. In our architecture, a plugin issue affects the admin interface only. The public-facing SPA continues serving cached content regardless of what happens on the WordPress side.

How It Works in Practice

Here is the actual workflow for publishing an article on this site:

• Write the article in WordPress’s editor. Full formatting, media uploads, categories, excerpts — all the familiar tools.
• Publish. The article is saved to the WordPress database and immediately available through the REST API.
• Done. The SPA’s intelligence hub automatically fetches the latest posts from the API. No deployment step, no cache clearing, no manual HTML editing.

The client’s experience of creating content is identical to any WordPress site. The visitor’s experience is dramatically better.

The Technical Architecture

Our setup for a typical client site looks like this:

• WordPress runs in a Docker container (or directly on the server), accessible only via /wp-admin and /wp-json
• Nginx serves static files for the SPA and proxies only admin and API requests to WordPress
• The SPA is a single HTML file, a CSS file, and a JavaScript file. Total: under 30KB
• Content is fetched from the REST API on page load and cached client-side
• Images are served from WordPress’s media library (via /wp-content/uploads)

There is no build step, no static site generator, no CDN invalidation. The SPA loads instantly and fetches fresh content from the API. Updates are live the moment you hit “Publish” in WordPress.

What This Means For Clients

For our clients, the headless approach delivers three things:

A fast website that scores 90+ on Google’s PageSpeed Insights. Not through optimisation tricks — through fundamental architecture. When your frontend is 30KB of vanilla JavaScript instead of a PHP-rendered page with 15 plugins, speed is the default.

A familiar content editor. WordPress’s block editor is mature, well-documented, and intuitive. Clients who have used WordPress before feel immediately at home. Clients who haven’t find it straightforward to learn.

Future-proofing. The REST API is a stable, standards-based interface. If we ever need to replace the frontend (unlikely) or add a mobile app (increasingly likely), the content API is already there. The content is decoupled from the presentation — change one without affecting the other.

The Honest Trade-Offs

Headless WordPress is not without downsides:

• No traditional page builder — yet. Standard WordPress page builders like Elementor don’t work in a headless setup. We’re building our own visual editor — a drag-and-drop interface that outputs clean HTML compatible with our SPA architecture. Content changes are already straightforward through WordPress; visual layout editing is coming soon.
• Plugin limitations. Some WordPress plugins assume they control the frontend (contact form plugins, SEO plugins with frontend output, e-commerce plugins). In a headless setup, these either need API-based alternatives or custom implementation.
• Development cost. Building a custom SPA frontend is more work than installing a theme. This cost is offset by reduced maintenance, better performance, and zero theme-update anxiety.

We believe these trade-offs are worth it for every business website we build. The performance, security, and longevity benefits outweigh the additional upfront development.

The Bigger Picture

The headless CMS pattern is not new — enterprise organisations have been building this way for years. What’s new is that the tools are now mature enough and the browser platform capable enough that a small studio can deliver the same architecture that previously required a team of 20.

WordPress gives us the best content editor in the industry. Vanilla JavaScript gives us the fastest possible frontend. Separating the two gives us security, performance, and flexibility that a traditional WordPress site cannot match.

This is what we mean when we say we build websites backed by intelligence. The intelligence isn’t just in the AI that monitors your market — it’s in the architectural decisions that make your site faster, more secure, and more resilient than your competitors’.

Key Facts: Headless WordPress Architecture

• WordPress REST API: Available since WordPress 4.7 (2016). Full read/write access to all content types via /wp-json/wp/v2/.
• Performance difference: Traditional WordPress: 3-5 second average load time (with plugins). Headless SPA: sub-1-second load time. 3-5x improvement.
• Security surface: Traditional WordPress exposes PHP, themes, and plugins to the public. Headless WordPress exposes only the read-only JSON API. Attack surface reduced by ~90%.
• WordPress market share: 43.1% of all websites (W3Techs, 2026). The content editor is the most widely-used CMS interface in the world.
• SPA frontend size: DESIGN-R.AI SPA: ~30KB total (HTML + CSS + JS). Typical WordPress theme: 500KB-2MB.

Frequently Asked Questions

Q: Can I still use WordPress to edit my content?

A: Yes — that’s the whole point. The WordPress admin interface works exactly as you’d expect. You log in, write content, upload images, and publish. The only difference is that visitors see a custom-built frontend instead of a WordPress theme.

Q: What happens if WordPress goes down?

A: The public-facing website continues to work. The SPA serves from static files and uses cached content. Visitors won’t notice any interruption. Only the admin interface and new content publishing are affected.

Q: Can I install WordPress plugins?

A: Yes, but with caveats. Plugins that operate on content (SEO metadata, custom fields, image optimisation) work normally. Plugins that render frontend output (page builders, contact form plugins, popup tools) won’t affect the custom SPA. We handle those features in the SPA itself.

Q: Is headless WordPress more expensive than a standard WordPress site?

A: The initial build costs more because we write a custom frontend instead of installing a theme. However, ongoing costs are typically lower — fewer plugin updates, fewer security patches, fewer compatibility issues, and zero theme-related maintenance.

Q: Can I add e-commerce later?

A: Yes. WooCommerce exposes its product catalogue through the REST API. A headless e-commerce frontend can be added without rebuilding the existing site. The decoupled architecture makes this significantly easier than retrofitting a traditional WordPress site.

---

Originally published at DESIGN-R Intelligence