Why We Build with Next.js + Payload CMS Instead of WordPress

Last updated: August 2026

According to W3Techs, around 40 per cent of all websites worldwide run on WordPress (as of 2026). That is impressive, and no reason to accept it as the default. When we plan client projects today, in most cases we choose Next.js + Payload CMS over WordPress. This article explains why, with technical arguments, concrete figures and an honest admission of when WordPress still makes more sense.

The WordPress problem is not a quality problem

WordPress is not bad. The core is mature, the community large, the ecosystem huge. The problem is structural: WordPress was built for blogs in 2003. Its PHP-based rendering, plugin system and database architecture still carry decisions made more than 20 years ago.

In practice this means:

• Performance: PHP renders every page synchronously on the server. Without aggressive caching (WP Rocket, W3 Total Cache), WordPress sites load slowly, especially with WooCommerce.
• Security: WordPress is the most hacked CMS in the world. Not because the core is insecure, but because 60,000+ plugins have varying quality standards.
• Update debt: plugin updates break other plugins. Many site owners freeze their WordPress version and so risk security gaps.
• Developer experience: PHP template development is tedious in 2026. No TypeScript, difficult testing, global state via WordPress hooks.

What Next.js does differently

Next.js is a widely used framework for modern websites. Depending on need, each page can be generated in advance, built on the server when requested, or made interactive only in the browser. The result:

Core Web Vitals

Core Web Vitals are Google's metrics for loading speed and usability. When blog posts and service pages are generated in advance, the page is already finished when the visitor requests it. No database queries on the user's request, no PHP interpreter overhead. Our Next.js sites regularly achieve Lighthouse scores of 95+ on mobile.

TypeScript end to end

TypeScript from the database schema to the UI component means that when a database field is renamed, the TypeScript compiler shows every place in the front end that needs to be adjusted. With WordPress, the same change means searching manually through PHP templates and JavaScript files.

React component architecture

Reusable React components, testable with Jest/Vitest, documentable with Storybook. WordPress shortcodes and PHP templates are the opposite of that.

Deployment and hosting

Next.js on Vercel deploys automatically on every Git push. Preview deployments for every pull request. Serverless functions without infrastructure management. With WordPress, all of this involves considerable configuration effort.

Why Payload CMS is the right choice as a back end

A headless CMS separates content management (back end) from presentation (front end). Content editors work in a familiar interface, while the development team has full freedom on the front end. There are many headless CMS options. We chose Payload CMS, and for concrete reasons:

• Open source, self-hosted: no monthly SaaS fee, full control of your data. Contentful and Sanity charge considerable monthly fees above a certain amount of data.
• TypeScript-native: the database schema is TypeScript, the API is TypeScript, hooks and access control are TypeScript. Full type safety.
• Collections and globals: the data model adapts to the requirements, not the other way round. Blog posts, service pages, project galleries: everything can be defined freely.
• Lexical rich text: a modern, extensible rich-text editor instead of TinyMCE.
• Direct PostgreSQL integration: no proprietary database layer, direct SQL access possible.

A concrete comparison

The EA Digital Solutions website runs on Next.js 15 + Payload CMS. Typical orders of magnitude compared with a WordPress site with caching (Lighthouse, mobile); the actual values depend heavily on hosting, theme and plugins:

• Lighthouse performance (mobile): Next.js: 97, WordPress with caching: 72
• Time to first byte: Next.js (Vercel Edge): 28 ms, WordPress (managed hosting): 340 ms
• Largest contentful paint: Next.js: 1.1 s, WordPress: 3.8 s

These figures are reflected in Google's Core Web Vitals, which feed directly into the ranking signal.

When WordPress is still the better choice

Honesty matters: in some scenarios WordPress is the right decision.

• Tight budgets with a short timeframe: a WordPress site can be live in days. A Next.js project takes weeks.
• Teams that know WordPress: if the internal team works in WordPress every day and lacks front-end development know-how, switching is counterproductive.
• An extensive plugin ecosystem is required: certain industry plugins only exist for WordPress (LMS systems, certain booking tools).
• Specific WooCommerce integrations: if your entire e-commerce infrastructure is built on WooCommerce, switching is a major project.

How we decide in practice

Our recommendation for client projects follows a clear logic:

• Existing WordPress project: optimise rather than switch, unless there are concrete performance problems or the plugin chaos can no longer be managed.
• New project with standard content: Next.js + Payload CMS is our standard recommendation: better performance, better developer experience, no security plugins to maintain.
• New project with a small budget under €5,000: WordPress with a good theme and minimal plugins can make sense.
• New project with complex logic: Next.js is clearly superior: custom collections in Payload, API routes for integrations, TypeScript everywhere.

Technical details: how Next.js and Payload work together

Payload CMS 3 supports Next.js natively: it runs as a plugin inside the same Next.js project. The back end (admin panel) and the front end share one codebase and one deployment process.

Content types are defined as TypeScript collections. From these, Payload automatically generates the interfaces for other systems (REST and GraphQL), the admin interface and the TypeScript types. The front end consumes these types directly, so the back end and front end cannot drift apart.

For this project we implemented, among other things: multilingual content (DE/EN) with i18n routing, linked service pages and blog posts, SEO fields with Schema.org generation, and Lexical rich text with custom nodes for structured data.