Why a Mature WordPress Property Would Go Static

WordPress is everywhere, whatever the exact market-share number happens to be at any given moment. The more interesting question is why a site that has scaled successfully on WordPress would walk away from it — and what the migration actually costs and returns. Smashing Magazine is a good test case: ten years of operation, thousands of articles, tens of thousands of comments, and a business that had grown well beyond the blog itself.

Smashing’s infrastructure before the move was split across a WordPress blog, a Rails jobs board, a Shopify store, and a separate CMS for the conference site. The publication also had performance problems, had outgrown its caching strategies, and wanted to introduce membership authentication and a redesign. Migrating to a JAMstack architecture — specifically to Netlify — was a way to solve all of those in one pass.

The Core Trade: Build Time for Uptime

The most dramatic change was in reliability. Smashing regularly got spikes from articles shared widely, and those spikes regularly produced database connection errors and outages despite heavy plugin usage. Serving prebuilt files from a CDN removes the database from the request path entirely — the content already exists, so nothing is compiled when a reader arrives.

That also changed the security posture. A static site doesn’t expose wp-login.php, which has long been a common attack vector, so the attack surface is much smaller.

Smashing had also cycled through every WordPress caching plugin with mixed results. Vitaly Friedman of Smashing described the recurring pain point: “The main issues we had were related to ‘Error Establishing Database Connection’ that we kept having every other week, and we literally tried every single WordPress caching plugin out there. The performance was pretty OK (overall), but we were looking to improve it further. Plus, we did want to launch Membership and connect all the different offerings — conferences, job posts, articles, books, eBooks — with one single platform, and it was remarkably difficult to achieve with WordPress in play.”

Netlify’s model avoids those cache headaches differently: HTML files live on the CDN with a high cache-hit rate, but any changed files are invalidated instantly on deploy. Asset URLs are fingerprinted so CSS, images, fonts, and JavaScript can be cached forever, and a new deploy automatically serves updated versions.

A Unified Workflow Across Disparate Properties

The migration was also an exercise in consolidation. Smashing had accumulated a maintenance burden from maintaining several different systems with different stacks. Moving everything to one platform changed development economics — the main site, conference site, subscriptions, and e-commerce all began to work together rather than as distinct codebases.

The WordPress export was the hardest part of the move. The standard WP exporter lost embeds and plugins had altered some content. Netlify wrote scrapers to pull articles, assets, comments, and the homepage separately, then loaded the transformed content into a new GitHub repo. Netlify CMS replaced WordPress for content editing, pulling markdown files directly from the git repo instead of from a database.

For contributors, the git-based workflow removed duplication. Sara Soueidan, who worked on the redesign, described it this way: “Everything that I pushed to the repository is being directly applied to the pattern library which means that you don’t have to maintain two different sets of components... this type of continuity was great! All I have to do is write HTML, CSS, and JavaScript and push to the repo and everything works like magic. The workflow was fantastic.”

That said, Netlify CMS has limits for a site with guest authors and full editorial staff. For a follow-up tutorial, Smashing explored a headless model that keeps the WordPress dashboard for editorial work while serving content via API and maintaining a git-centric development workflow.

The Build Scaling Problem

The cost of the architecture only shows up at publishing time. Because every page is pre-built in advance, a site with thousands of articles needs long builds before anything can be deployed. Smashing addressed this by splitting content into two directories: a large /production-articles folder for the mass of historical articles, and a separate content/articles working directory for actively-edited posts. A gulp task prepared the production articles so the build only processed what was being worked on locally.

This kept development fast, but had drawbacks — the full build still has to run eventually, and at Smashing's scale that slows publication. Smaller publications would not hit the same bottleneck, but it's a real constraint for high-volume sites.

Framework Decisions Evolved Over Time

Smashing’s stack also changed through the project. The initial prototype used minimal Preact with Hugo, since the author focused on performance — but Preact was missing features Smashing needed from React's ecosystem. The team ended up adopting Redux and other React libraries.

Looking back, the original author noted he would have used Vue, and might not have picked Hugo again: Hugo lacked the plugin system needed to programmatically create items like banner ads, requiring script injections that slowed builds. Eleventy or Nuxt would be alternatives he'd consider now, for richer plugin capabilities.

Those choices are particular to Smashing's needs — Hugo is still used for Netlify's own site. The broader lesson is that the generator choice matters less than being honest about the constraints: pre-built pages make the runtime fast, but the tooling has to handle the scale of the content pipeline and the flexibility of the layouts.

Stateless Services for the Hard Parts

Beyond the core content pipeline, Smashing needed to replace three WordPress-dependent functions: e-commerce, comments, and user authentication. Netlify’s open-source, stateless API services handled each:

  • GoTell — an API and build tool built for managing high volumes of comments.
  • GoCommerce — a small Go-based API for e-commerce sites that processes orders and payments.
  • GoTrue — a self-standing Golang API for user registration and authentication, built on OAuth2 and JWT, covering signup, authentication, and custom user data.

Each service required its own migration path and considerations. Those details are beyond the scope here, but are covered extensively in the free book Modern Web Development on the JAMstack, which Matt co-wrote. Follow-up posts plan to include practical deep dives into search and authentication.

What the Move Delivered

The migration held up under real-world conditions. Smashing could serve popular articles without the performance collapse that previously came with traffic spikes. The JAMstack architecture also brought tangible gains in both performance and security.

Markus Seyfferth, then CEO of Smashing Magazine, measured the improvement directly:

“The time to first load is so much faster than before… before we had to wait for the HTML file being served for 800ms and now it’s 80ms.”

The project yielded clear engineering lessons, and the next installment in this series turns those lessons into a practical tutorial and demo. For teams looking to move WordPress to a JAMstack setup, that walkthrough covers the recommended path based on what Smashing learned along the way.

Further Reading

Smashing Editorial