Spokes.wiki Search Graph Growth About

static-site-wiki

log

Synthesis

The evolving thesis for the static-site / Jamstack spoke. Updated on every ingest.

Current thesis

The web’s publishing substrate is shifting from request-time, database-backed CMS (the wordpress model) toward build-time pre-rendering (static-site-generator

  • jamstack). The opening cohort of sources captures both halves of that story: the incumbent’s first sustained decline and the rising tooling that benefits.

Two distinct “fast”s. Don’t conflate them: eleventy wins build speed (~12× faster than Astro on 4k files); astro wins runtime experience (66–67% Core Web Vitals pass rate). A team chooses on which axis hurts more. The build-speed axis now has a Rust entrant: zola, a single-binary engine (Tera templates, batteries-included Sass/search/ images) that claims sub-second whole-site builds — the direct counterpart to hugo (Go single binary), reinforcing that “no Node toolchain + one executable” is its own coherent design lane.

A documentation-SSG sub-genre is now legible. Three docs-first generators span the major language ecosystems — docusaurus (React), vitepress (Vue, Vite-powered, the VuePress 1 successor), mkdocs (Python, single-YAML config, Material theme) — all converging on the same shape: Markdown content + a default doc theme → static HTML, differing mainly in runtime stack (and whether they hydrate into an SPA, as VitePress/Docusaurus do, vs. stay near-zero-JS). That convergence is itself evidence on the open question below: even as the frameworks differ, the SSG form factor is stable.

Astro leads its weight class, not the field. Independent CrUX data (core-web-vitals-wordpress-astro) puts Astro 4th of 7 — behind hosted site builders (Duda 85%, Wix 80%, Shopify 79%) but ahead of every self-hosted CMS (Drupal, Joomla, wordpress last at 49%). So the win is “best among open developer frameworks,” and the wordpress performance gap is real and third-party-confirmed.

It’s a whole pipeline, not just a generator swap. The displacement of the monolithic CMS has two more layers beyond the SSG itself. netlify — which coined “Jamstack” (founded 2014, runs Jamstack Conf) — is the deployment substrate: git push → build the SSG → serve generated files from a global CDN, with deploy previews and serverless/edge functions filling the dynamic gaps a pre-rendered site can’t (vercel in cloud-wiki is the React/Next-leaning sibling; Netlify is framework-agnostic). headless-cms is the content-management half — a back-end-only content repository exposed over an API (REST/GraphQL), decoupling content from presentation, the direct answer to “drop WordPress, and where does editable content live?” (git-based variants like Decap commit Markdown to the repo; SaaS variants like Contentful/Sanity serve via API). The pipeline — headless content → SSG build → Netlify CDN — has each layer doing one job the wordpress monolith did all at once.

The displacement also needs a turnkey-template layer — and it’s filling in. One thing the wordpress monolith always had that bare SSGs didn’t: pick-a-theme-and-go, a non-developer’s path to a finished site. astro-themes is that layer arriving for the SSG world — Astro’s official gallery of ~900 community-submitted ready-made sites (free and paid) across the same use cases WordPress themes cover (blog, portfolio, e-commerce, SaaS, docs, education). It runs on the same open-submission model as the awesome-static-generators / jamstack-generators-list catalogs, but applied to finished sites rather than tools. So displacement is not only the per-layer pipeline above (content / build / delivery) but also ecosystem maturity: the SSG side growing the turnkey-site economy that made WordPress the default. (Vendor-self-reported count, volatile listing — an adoption signal, not a benchmark.)

The static-first core now extends into the dynamic. astro-server-islands (server:defer) is the server-side complement to islands-architecture: ship a build-time static, CDN-cacheable shell immediately, then fetch only personalized fragments on demand as HTML, with little to no client JS. That dissolves the old SSG bargain (“pre-render everything, but then personalization can’t fit”) without becoming a full SSR meta-framework — Astro now spans static shell → server islands (no-JS dynamic) → client islands (hydrated), a finer spectrum than the static/SSR binary, and evidence on the SSG-vs-meta-framework question that the static-first core extends into per-request rendering rather than abandoning build-time. (Caveat: server islands need a runtime/adapter, not pure static hosting.)

Open questions

  • Is “SSG” still a coherent category? The top of jamstack-generators-list is React meta-frameworks (Next.js, Gatsby, docusaurus) that also do server rendering. The boundary between “static site generator” and “web framework” is blurring — Astro itself spans both. Worth a dedicated source on SSG-vs-meta-framework. Partial evidence (2026-06-09): the docs-SSG trio docusaurus/vitepress/mkdocs and the single-binary pair hugo/zola show the core is stable (Markdown + theme → static HTML); the blur is specifically at the SPA-hydration edge (VitePress/Docusaurus ship a client framework) vs. the near-zero-JS edge (astro, zola, mkdocs). The category coheres on build-time HTML; it splits on how much client JS rides along.
  • How much of WordPress’s decline is technology vs. governance? The source leans hard on the Mullenweg / WP Engine drama and only secondarily on perf/usability. Causation is asserted by correlation; a neutral source would help. (See tension.)
  • Where’s the neutral benchmark? Partially resolved. core-web-vitals-wordpress-astro uses CrUX field data (more neutral) and independently corroborates astro (~67% vs its self-reported 66%) and wordpress (49% vs ~48%). Eleventy’s build-speed numbers are still self-reported — that one’s open.
  • Scope cut — React meta-frameworks removed (2026-06-03, human directive). Next.js and Gatsby were deleted as product pages: they’re full-stack React meta-frameworks, the web-framework side of the very boundary the open question above flags — a different category from build-time SSGs. They remain plain-text comparison examples only. Retained as their own pages: build-only SSGs hugo, eleventy, jekyll and the React-based docs SSG docusaurus. So the wiki now deliberately scopes to SSGs and treats React meta-frameworks as out-of-scope neighbours rather than subjects. (Routing note: future Next.js/Gatsby/Remix sources should not auto-land here — see ../wikis.md.)

Contradictions / tensions

  • What counts as winning? eleventy markets build speed; astro markets runtime core-web-vitals. Not a contradiction, but competing definitions of “performance” — a reader could pick either tool citing “it’s faster.”
  • Cause of the WordPress decline. wordpress-market-share-decline foregrounds governance/trust drama; astro/jamstack-generators-list would frame the same shift as technology (Core Web Vitals, DX) winning. Both narratives explain the same numbers; recorded here rather than resolved.
  • Page weight vs. architecture (cross-wiki contradiction). core-web-vitals-wordpress-astro argues real-world CWV is driven by architecture and efficient delivery, NOT minimal payload — exhibit A: Shopify, heaviest median page (3.77 MB) yet 3rd-fastest in the field. This directly contradicts the byte-budget / page-weight-minimalism thesis of the sibling webperf-wiki. Genuine disagreement worth a neutral tie-breaker; flagged, not resolved.

Cross-wiki adjacency

This spoke borders the sibling webperf-wiki (page-weight minimalism, byte budgets) at exactly core-web-vitals and the zero-JS ethos. They’re kept separate: webperf is about measuring and minimizing bytes; this spoke is about the tools and the publishing-platform landscape. Logged as the runner-up at routing time (see ../log.md). Note the live disagreement above: our source says bytes aren’t destiny, which is in direct tension with webperf-wiki’s core premise — a good question to put to both wikis.

Index

Catalog of every page, grouped by schema.org @type. Read this first when answering a query, then drill into the relevant pages. Updated on every ingest.

NewsArticle (sources)

WebPage / ItemList (sources)

  • awesome-static-generators — curated GitHub list of SSGs, organized by use case · source · github.com
  • jamstack-generators-list — jamstack.org ranking of SSGs by GitHub stars · source · jamstack.org
  • astro-themes — Astro’s official themes gallery: ~900 community-submitted ready-made sites (free/paid); the SSG turnkey-template layer maturing vs WordPress · source · T3 · astro.build

SoftwareApplication

  • astro — content-first JS framework; islands, zero-JS default; best Core Web Vitals · source · astro.build
  • eleventy — minimal zero-config Node SSG; fastest builds; 13+ template langs · source · 11ty.dev
  • hugo — Go SSG, #2 by stars; single-binary, build-speed-focused
  • zola — Rust single-binary SSG; batteries-included, sub-second builds; the Rust counterpart to Hugo · source · getzola.org
  • docusaurus — React/Markdown SSG (#3 by stars) specialized for documentation sites
  • vitepress — Vue + Vite docs SSG (VuePress 1 successor); Markdown + Vue components · source · vitepress.dev
  • mkdocs — Python docs SSG; single-YAML config, Material theme; Sphinx alternative · source · mkdocs.org
  • jekyll — Ruby SSG; the genre’s early standard-bearer, engine behind GitHub Pages
  • wordpress — incumbent request-time CMS; the model being displaced

TechArticle (sources)

  • astro-server-islands — Astro server:defer: static shell + on-demand server-rendered dynamic fragments; the server-side extension of islands · source · docs.astro.build

DefinedTerm

  • static-site-publishing — umbrella: build-time pre-rendering as a publishing model (generator → architecture → CDN), displacing the request-time CMS · domain
  • static-site-generator — build-time HTML compilation; the wiki’s hub concept · mechanism
  • jamstack — pre-rendered markup + APIs architecture · mechanism
  • islands-architecture — per-component hydration; how Astro ships zero JS by default · mechanism
  • core-web-vitals — Google’s runtime performance yardstick; bridge to webperf-wiki · standard
  • headless-cms — back-end-only content-as-API; the content-management half that pairs with SSGs · source · wikipedia · mechanism

Organization / Platform

  • netlify — the platform that coined Jamstack; git→build→CDN deploy substrate for SSG output · source · wikipedia

Synthesis

  • synthesis — the evolving thesis, open questions, and tensions