Jamstack or WordPress is a constraint decision
Prerendering does not make a site fast by itself. In the 2020 Web Almanac, Next.js pages hit good LCP on 23% of mobile loads and WordPress on 25%. The decision belongs to editing model and maintenance.
Contents
Neither architecture is better in general. Jamstack fits sites whose content changes on a predictable schedule and whose team can own a build pipeline. WordPress fits sites where non-technical people publish daily and expect the change to be live at once. The deciding constraints are the editing model, request-time behavior and maintenance.
Key takeaways
- The 2020 Web Almanac found more than 42% of web pages running on a CMS. WordPress held a 31% usage share of all pages crawled and 74.2% of CMS pages.
- Jamstack was detected on 0.84% of mobile pages and 0.91% of desktop pages in the same crawl, up from 0.34% and 0.50% a year earlier.
- Prerendering does not guarantee speed: good LCP on mobile reached 74% for Jekyll but 23% for Next.js and 18% for Nuxt.js, against 25% for WordPress.
- WordPress has shipped REST API content endpoints since version 4.7 in December 2016, so running it headless is a configuration choice rather than a migration.
What the two architectures actually are
Jamstack builds the front end into static pages and assets ahead of time and serves them from a CDN. Backend services are reached through APIs, at build time or from the browser. The two ideas underneath it are prerendering and decoupling.
WordPress renders pages from a database on request, through PHP, usually with a caching layer in front. Both models can put a fast document in front of a visitor. They differ in when the HTML is produced and in who can change it without a developer.
Prerendering does not guarantee a fast page
This is the part most comparisons get wrong. The 2020 Web Almanac measured Core Web Vitals by framework, and the spread inside Jamstack is wider than the gap between Jamstack and WordPress.
In the 2020 Web Almanac, mobile loads with good Largest Contentful Paint reached 74% for Jekyll and 69% for Hugo. Gatsby reached 36%, Next.js 23% and Nuxt.js 18% (HTTP Archive, 9 December 2020). WordPress sat at 25% (CMS chapter).
The generators that ship almost no JavaScript hold their advantage. The ones that hydrate a full application put the cost back on the client, and the 2.5-second LCP threshold does not care where the delay came from. Choosing Jamstack for speed and then adding a heavy client runtime returns the site to where it started. That pattern also shows up in what a business actually buys when it buys a website.
Who edits, and how often
Start here, because it eliminates one option faster than any benchmark. WordPress ships an editor, a media library, roles and permissions, previews and scheduled publishing. A marketing team can operate it without a developer, and WordPress 5.0 in December 2018 made block-based editing the default.
A Jamstack site has none of that until you add a headless CMS: another vendor, another set of accounts, another integration to maintain. If the site publishes twice a year, that overhead is irrelevant. If it publishes daily and the build takes six minutes, editors wait six minutes to see a typo fix.
Anything that has to be true at request time
Prerendering means the HTML was correct at build time. Stock levels, prices, personalized dashboards and search results are not, so they move to client-side calls or serverless functions.
That is a fine trade for a few components. It stops being fine on the main content of the highest-traffic pages. At that point you have rebuilt a dynamic site with more moving parts than the one you replaced.
The cost is maintenance, not hosting
Hosting is the cheapest line in both models and the one most proposals argue about. The recurring cost is elsewhere.
WordPress accumulates a plugin surface that needs patching, and every unpatched plugin is an open door. Jamstack accumulates build dependencies that break on their own schedule, plus a build that must keep succeeding for anyone to publish. Neither disappears at handover, which is one reason we quote scope rather than hours.
Four questions that settle it
- How often does content change, and can the person changing it read a pull request?
- Does any high-traffic page have to be correct at request time rather than at build time?
- Who owns the build pipeline in eighteen months, by name and role?
- What happens to publishing if the build fails at 18:00 on a Friday?
Answer those before the architecture debate and the debate usually ends. They are the same class of question as the three that decide whether a project fails.
WordPress has exposed REST API content endpoints for posts, comments, terms, users, meta and settings since version 4.7, released on 6 December 2016 (WordPress.org). A WordPress backend with a prerendered front end is therefore a valid third option, not a contradiction.
FAQ
Is Jamstack always faster than WordPress?
No. In the 2020 Web Almanac, Jekyll reached good mobile LCP on 74% of loads and Hugo on 69%, but Next.js on 23% and Nuxt.js on 18%, while WordPress reached 25%. Prerendering removes server render time; a large client-side runtime puts it back.
Can WordPress be used headless?
Yes. REST API content endpoints have been in core since WordPress 4.7 in December 2016. Editors keep the admin interface they know, and the front end is built and deployed separately. The trade is two systems to operate instead of one.
What makes Jamstack a bad fit?
Daily publishing by non-technical editors, long build times, and pages that must be correct at request time. Any of the three alone is survivable. Together they turn a build pipeline into a bottleneck sitting between the marketing team and its own website.
How much of the web actually runs on each?
The 2020 Web Almanac found more than 42% of pages on some CMS, with WordPress at a 31% usage share. Jamstack was detected on 0.84% of mobile pages, up from 0.34% in 2019. The gap is large, and the growth rate is not.
Decide the editing model first
Write down who publishes, how often, and what has to be true at request time. Then pick the architecture that fits those three answers, and only then argue about frameworks. Twelve months on, the honest test is whether anyone outside the development team published without asking for help. The second test is whether mobile still meets the Core Web Vitals thresholds at the 75th percentile.
