Joost de Valk has been pushing a “back to basics” take on the web: if AI systems and search crawlers struggle with JavaScript-heavy experiences, then simpler, more static-by-default sites start to look like the smartest path again. In his post Build websites like it’s 2005 (and win in 2025), he argues that modern sites can become “invisible” when the content is buried behind client-side rendering, and that clear HTML, accessibility, and speed are the fundamentals that still win.
He’s not wrong about the fundamentals.
But founders, operators, and marketing teams aren’t losing sleep over whether a site is “technically elegant.” They’re losing sleep because they can’t ship updates fast enough. And that’s where the no-CMS dream runs into the real world: speed without publishing velocity stalls growth.
What Joost (and the no-CMS camp) gets right
Let’s give the argument its full credit. A static site (or static-first build) can deliver legitimate advantages:
Blazing performance and cleaner Core Web Vitals
Static delivery typically means fewer moving parts at runtime: no database queries per pageview, fewer backend bottlenecks, and more aggressive caching/CDN behavior.
That matters because real UX performance is measurable—and it ties directly to conversion outcomes. If you want a practical refresher on why this stuff still matters, TopOut’s breakdown Do core web vitals matter for search ranking? is a good starting point, and Google’s own Web Vitals overview shows how these metrics are measured and surfaced in tools like PageSpeed Insights and Search Console.
Fewer security headaches
No admin panel and no plugin ecosystem can mean a smaller attack surface. In practice, many CMS compromises happen through outdated plugins and themes—WordPress security reporting from vendors like Wordfence and vulnerability tracking from Patchstack make it clear how fast this ecosystem moves (and how quickly “set it and forget it” turns into risk).
Static isn’t “invincible,” but it often reduces the number of doors you have to lock.
Better crawlability when JavaScript gets in the way
Joost’s core warning is real: if your content requires heavy JavaScript rendering, some systems may struggle to process it reliably. Google can render plenty of JavaScript, but it’s not unlimited, and implementation details matter. Google’s JavaScript SEO basics is the most practical “read this before you ship” doc for teams building JS-forward sites.
In other words: simple output HTML is still a competitive advantage.
Where the no-CMS vision breaks: founders can’t wait for “the next deploy”
Here’s the pattern we see over and over:
- A founder buys into the “static is simpler” pitch (often for speed, security, and cost).
- The site launches and performs well… technically.
- Then the business evolves—offers change, positioning changes, landing pages multiply, and content needs to move weekly, not quarterly.
- Every update becomes a ticket, a Slack message, or a dev sprint.
- Marketing slows down because publishing is blocked.
That “immobilized by update barriers” feeling is not hypothetical. Even teams with a CMS hit this wall when the CMS is poorly implemented—Tenet describes it well in When a CMS becomes a bottleneck instead of an enabler: when simple changes require developer help, momentum dies.
Now remove the CMS entirely, and the bottleneck risk doesn’t disappear—it often becomes the default operating mode.
The hidden cost isn’t development time. It’s missed compounding.
A “fast” site that doesn’t get updated fast is like a gym membership you never use. The value is in repetition:
- New pages that match new search demand
- Fresh proof points (case studies, testimonials, updated numbers)
- Iterated messaging based on sales calls
- Conversion tests (headlines, forms, layouts)
- Ongoing SEO content that actually ships
That’s why we talk so much about measurable content systems—not just “content.” (If you’re building a plan for this, start with Crafting a content strategy that hits the peak.)
Speed vs. flexibility is a false choice (if you build the right CMS stack)
The strongest middle-ground approach in 2026 is rarely “pure static” or “classic CMS pages assembled on every request.”
It’s usually one of these:
- CMS + static generation (publish in a CMS, deploy fast static pages)
- Hybrid rendering (static where possible, dynamic where necessary)
- Modern visual CMS with guardrails (marketers can ship changes safely, developers keep structure clean)
Joost’s main point—“make the output simpler”—can coexist with a CMS. You can still generate clean HTML, keep JavaScript under control, and deliver a fast experience while letting non-developers publish.
The headless trap: “flexible” for engineers, frustrating for everyone else
A lot of teams try to solve the static-vs-CMS tension with headless CMS. Sometimes it’s the right call. Sometimes it’s an expensive detour.
The common failure mode is that the “headless” model decouples content from the editing experience so much that marketers lose the ability to confidently preview, adjust layout, or launch pages without engineering support. Builder.io makes this critique bluntly in Why headless CMSs are a huge step back for content management.
Headless can be fantastic when:
- You have structured content needs across many channels
- You have engineering capacity
- You invest in a real editorial experience (not just an API)
But for many founder-led teams, “headless” becomes “hopeless” the moment the first urgent landing page request hits.
A practical comparison: what to choose when the business will change
| Approach | What it’s great at | Where it breaks | Best fit |
|---|---|---|---|
| Static-only (no CMS) | Speed, security, low runtime complexity | Publishing velocity, content iteration, dependency on dev | Truly small sites that rarely change |
| Traditional CMS (plugin-heavy) | Quick publishing, familiar workflows | Performance drift, plugin risk, messy governance over time | Teams that need speed now and can maintain it |
| CMS + static/hybrid build | Fast pages + fast publishing (when implemented well) | Requires thoughtful architecture and guardrails | Growing brands that need both performance and agility |
| Modern visual CMS (with governance) | Marketer autonomy, fast iteration, cleaner systems | Needs strong setup to avoid chaos | Teams that test offers, ship pages often, and measure results |
How often will we need to change the site to reflect how the business is evolving?
If the answer is “weekly,” a no-CMS approach will eventually feel like a ceiling.
What we recommend at TopOut: build for the next version of your business
At TopOut, we’re performance-minded (fast sites win), but we’re also practical (shipping wins). So our default posture is:
- Build a site that outputs clean, crawlable pages
- Keep performance measurable and monitored
- Give clients a CMS that supports real workflows: landing pages, SEO content, updates, governance, and safe publishing
That’s why our work often blends web development with ongoing CMS care initiatives, plus a system for consistent publishing through content creation. The goal is long-term: a site that stays fast and stays useful as your team and strategy grow.
The takeaway: simple output, scalable editing
Joost is right to push the industry away from brittle complexity. Clean HTML, accessibility, and speed are non-negotiable.
But in the real world, client flexibility wins every time—because the company that publishes and iterates faster compounds faster.
If you want the best of both worlds, don’t choose between static speed and CMS agility. Choose an architecture that delivers both.
