Why Progressive Web Apps (PWAs) and Headless CMS Are Still Relevant in 2024

Introduction

I rebuilt a client’s e-commerce site as a PWA with a headless CMS in 2022. Their old WordPress site took 4.2 seconds to load on mobile. The PWA loaded in 0.8 seconds. Conversion rates increased 34%.

Two years later, they asked me to add a mobile app. I reused the same headless CMS, connected it to a React Native frontend, and shipped in three weeks. No backend changes. No API development. Just a new frontend consuming existing content.

PWAs and headless CMS aren’t “future of web development.” They’re the present for teams that need to ship fast across multiple platforms without maintaining separate backends.

This article is for developers who’ve built traditional monolithic CMSs and felt the pain of inflexibility when requirements change. If you haven’t tried to add a mobile app to a WordPress site or reused content across web, mobile, and IoT, this isn’t your problem yet. Build a coupled system first, experience the limitations, then come back.

I’m going to tell you when PWAs and headless CMS actually solve problems, what breaks when you implement them incorrectly, and why most case studies skip the operational complexity.

Enjoying this? 👉 Tip a coffee and keep posts coming

Here’s who this is for: Developers building content-driven applications across multiple platforms. Teams managing websites that need mobile apps, kiosks, or IoT interfaces. Anyone maintaining WordPress or Drupal and wondering if there’s a better way.

Not for: Developers building simple blogs or single-platform applications. This assumes you need content reusability across platforms.

The question isn’t “are PWAs and headless CMS still relevant?” It’s “why are we still coupling content management to presentation?”

The Core Judgment: Separate Content from Presentation, or Maintain Multiple Backends

Here’s my default architecture after building content platforms for multi-channel distribution: use headless CMS for content that needs to appear across multiple frontends. Use PWAs when you need web applications that work offline and install like native apps.

Not buzzwords. Architecture.

Most teams build WordPress sites because they’re familiar, then discover they need a mobile app and realize WordPress wasn’t designed for API-first content delivery. They add WP REST API, build a React Native app, discover performance problems, and spend months optimizing what a headless CMS solves by default.

I’ve built both architectures. Traditional CMS with mobile app: six months of development, ongoing sync issues, separate deployment pipelines. Headless CMS with PWA: eight weeks, one content backend, deploy anywhere.

Traditional CMSs are optimizing for the wrong thing. They optimize for simplicity in a single-platform world. But we don’t live in a single-platform world anymore. Users expect your content on web, mobile, smartwatches, kiosks, and voice assistants.

The mistake teams make is thinking “WordPress can do APIs” solves multi-platform content. It doesn’t. WordPress was designed for server-rendered websites. Its API capabilities are retrofitted. Headless CMSs were designed API-first from the start.

I see this constantly: teams build WordPress sites, add custom post types, install ACF, configure REST API endpoints, build authentication, handle caching, and wonder why it feels fragile. Headless CMS platforms solve all of this with first-class API support, CDN integration, and webhook-based deployments.

The decision isn’t “which CMS is easier?” It’s “how many frontends will consume this content?”

How This Works in the Real World

The reason headless CMS and PWAs feel powerful is that they solve distribution problems traditional systems create.

You think WordPress is “good enough” because it works for websites. You’re missing the point. Websites aren’t the endpoint anymore. They’re one frontend among many.

Here’s what actually happens when you separate content from presentation:

Traditional setup: Your WordPress site manages content and renders HTML. When you need a mobile app, you either use WordPress’s REST API (slow, not optimized for mobile) or build a separate content backend for mobile. Either way, you maintain two systems or suffer performance penalties.

Headless setup: Your CMS (Contentful, Strapi, Sanity) manages content via API. Your web frontend is a PWA built with Next.js, Gatsby, or vanilla React. Your mobile app uses React Native or Flutter consuming the same API. Your smartwatch interface hits the same endpoints. One content backend, infinite frontends.

PWAs add offline capabilities and installability. Users can add your web app to their home screen. It works without internet. Push notifications engage users. Service workers cache content intelligently.

What surprised me when I moved production systems to headless CMS with PWA:

1. Development velocity increased 3x. No more “we need to rebuild this feature for mobile.” Build it once as a frontend component. Wire it to the CMS. Done.

2. Content editors became more productive. Traditional CMS editors see content mixed with presentation concerns. Headless CMS editors see pure content. They don’t accidentally break layouts. They focus on writing.

3. Performance became predictable. Static site generation with headless CMS means pages load in milliseconds. PWA caching means repeat visits are instant. Traditional WordPress sites slow down under load. Headless systems scale linearly.

A Real Example: When WordPress Couldn’t Scale Multi-Platform

I built a media publication’s website in 2020. They needed web, iOS app, Android app, and AMP pages. Initial architecture: WordPress with mobile apps consuming WP REST API.

Problems appeared immediately. WordPress queries were slow—300-500ms response times. Mobile apps felt sluggish. AMP pages required separate templates. Content editors broke mobile layouts by changing WordPress themes. Every platform needed custom caching strategies.

I rebuilt with Strapi (headless CMS) and Next.js PWA in two months. Same content. Three fewer systems to maintain.

Results:

• API response times: 30-50ms (10x faster)
• Mobile apps stayed synchronized automatically (same data source)
• AMP pages generated from the same content templates
• Content editors couldn’t break anything—they only edited content, not presentation
• Added a smart TV app in three weeks using the same API

What I’d do differently: Never couple content management to presentation in multi-platform projects. Start headless from day one when you know you’ll need mobile, IoT, or multiple web properties.

Common Mistakes I Keep Seeing

Building a headless CMS when you only have one frontend. Headless architecture adds complexity. If you’re building a single website with no plans for mobile, IoT, or multiple web properties, WordPress or traditional CMS is simpler. Don’t over-architect.

Treating PWAs like websites with a manifest. Adding a manifest.json doesn’t make your site a PWA. Real PWAs need service workers for offline functionality, optimized caching strategies, and thoughtful UX for installation prompts. Half-baked PWAs frustrate users.

Not implementing proper caching strategies. Headless CMS APIs can get expensive at scale. Every page load hitting the API costs money and adds latency. Implement static site generation, edge caching, or incremental static regeneration. Don’t query the CMS on every request.

Ignoring content modeling. Headless CMS platforms give you flexibility to model content however you want. Teams model content like database tables—flat, denormalized, repetitive. Model content semantically. Think about reusability. Use references and relationships.

Tradeoffs and When This Architecture Is Wrong

I’m not saying headless + PWA works for everything. I’m saying it works for multi-platform content distribution.

Use headless CMS + PWA when:

• You need content across web, mobile, IoT, or multiple web properties
• Performance and scalability matter (high traffic, global distribution)
• Your editorial team shouldn’t touch presentation code
• You want to change frontend technology without migrating content

Don’t use headless CMS + PWA when:

• You’re building a single website with no expansion plans
• Your editors need WYSIWYG and visual page builders
• Your team lacks JavaScript expertise for frontend development
• You need WordPress plugins for specific functionality (e-commerce, forums, LMS)

Real limitations:

• Increased frontend complexity. You’re responsible for building the entire frontend. No themes. No plugins. Just code. This requires skilled frontend developers.

• Content preview is harder. Traditional CMS shows you exactly what published content looks like. Headless CMS requires building preview functionality. Some platforms handle this well (Sanity, Contentful). Others don’t.

• Hosting costs can be higher initially. Headless CMS subscriptions cost money. JAMstack hosting costs money. At scale, this is cheaper than WordPress hosting under load. At low traffic, traditional hosting is cheaper.

The honest answer: if you’re building a blog or simple marketing site, WordPress is fine. If you’re building a platform that needs omnichannel content delivery, headless CMS is worth the complexity.

Best Practices I Actually Follow

Use Static Site Generation when possible. Generate HTML at build time from your headless CMS. Serve static files from a CDN. This is faster and cheaper than server-rendering or client-rendering. Next.js, Gatsby, and Astro all support this.

Implement Incremental Static Regeneration for dynamic content. You don’t need to rebuild your entire site when one article changes. ISR rebuilds individual pages on-demand. Next.js handles this well.

Design content models for reusability. Create content types that work across platforms. An “Article” should have fields that make sense on web, mobile, and voice. Don’t create separate “Web Article” and “Mobile Article” types.

Use webhooks to trigger builds. When editors publish content, your headless CMS should trigger a build of your frontend. This keeps content synchronized without manual deployments.

Implement proper error boundaries. PWAs work offline. Your app needs to handle API failures gracefully. Show cached content when the API is unreachable. Queue writes for later sync.

When Traditional CMS Is Genuinely Better

Content editors need visual builders. If your team builds pages with drag-and-drop builders, headless CMS won’t work. You need a traditional CMS like WordPress with Elementor or Webflow.

You need WordPress plugins. WooCommerce, BuddyPress, LearnDash—these are WordPress-specific. Headless CMS platforms don’t have this ecosystem. Replicating their functionality is expensive.

You have one website and no expansion plans. Building a company blog? Use WordPress or Ghost. The simplicity wins. Headless architecture is over-engineering.

Your team lacks JavaScript skills. Headless CMS requires building frontends in React, Vue, Svelte, or similar frameworks. If your team only knows PHP, WordPress makes more sense.

Conclusion

WordPress and traditional CMSs aren’t obsolete. They’re the right choice for single-platform projects, teams that need plugins, and content editors who require visual builders. But for multi-platform content distribution, headless CMS architecture solves problems traditional systems create.

After years of building both architectures, I’ve learned that the best CMS is the one that matches your distribution requirements. One frontend? Traditional CMS. Multiple frontends? Headless CMS.

The future isn’t “headless or traditional.” It’s choosing architecture based on how many channels consume your content.

Build headless when you need platform flexibility. Use traditional CMS when you need ecosystem maturity. Don’t force one solution everywhere.

Frequently Asked Questions (FAQs)

Can I make WordPress headless?

Yes. Use WP REST API or WPGraphQL. But WordPress wasn’t designed for this. Performance suffers. You’ll spend time optimizing what purpose-built headless CMSs handle natively. Possible, but not ideal.

Which headless CMS should I use?

Depends on requirements. Contentful (enterprise, expensive, reliable). Strapi (open source, self-hosted). Sanity (developer-friendly, real-time). Prismic (simple, affordable). Ghost (focused on publishing). Evaluate based on content modeling needs, budget, and team expertise.

Do PWAs really work offline?

Yes, with proper service worker implementation. You control what gets cached. Static assets cache automatically. API responses cache selectively. The app functions without internet—users see stale content until reconnection.

How do I handle authentication in a headless setup?

Use JWT tokens, OAuth, or third-party auth (Auth0, Clerk). Your headless CMS provides APIs. Your frontend handles authentication UI. Pass tokens in API requests. Most headless CMSs support role-based permissions.

What about SEO? Don’t client-rendered SPAs hurt SEO?

They can, if implemented wrong. Use server-side rendering (SSR) or static site generation (SSG). Next.js, Nuxt, SvelteKit all support this. Search engines see fully-rendered HTML. Client-only SPAs without SSR do hurt SEO—avoid them for content sites.

Your turn: How many platforms consume your content? If that number is greater than one, are you maintaining separate backends or reusing a single source?

Enjoying this? 👉 Tip a coffee and keep posts coming