Ich habe letzten Monat eine Marketing-Website ausgeliefert, die in allen Lighthouse-Kategorien 100 Punkte erreicht. Gesamte JavaScript an den Client: null Bytes. Nicht "fast null" oder "minimal" -- buchstäblich nichts. Die Formulare funktionieren, die Navigation funktioniert, es gibt einen Dark-Mode-Toggle und die Seitenübergänge fühlen sich schnell an. Vor fünf Jahren hätte das ernsthafte Kompromisse erfordert. In 2026 hat die Plattform einen Stand erreicht, bei dem Zero-JS keine Einschränkung ist -- es ist eine legitime architektonische Entscheidung.

Aber hier ist das, was die meisten Artikel über progressive Enhancement falsch verstehen: Es geht nicht darum, ein Purist zu sein oder JavaScript zu hassen. Es geht darum, bewusste Entscheidungen zu treffen, was wo läuft. Ich zeige dir, wie wir das bei Social Animal angehen, was sich in 2026 geändert hat, das Zero-JS für mehr Projekte denn je möglich macht, und wann du absolut noch Client-seitigen Code greifen solltest.

Inhaltsverzeichnis

Progressive Enhancement & Zero-JS Websites in 2026

Was Progressive Enhancement in 2026 tatsächlich bedeutet

Progressive Enhancement gibt es schon seit den frühen 2000er Jahren, aber die meisten Entwickler, mit denen ich spreche, verstehen es immer noch falsch. Sie denken, es bedeutet "build zuerst eine schlechte HTML-Version, mache sie dann mit JavaScript gut". Das ist verkehrt.

Progressive Enhancement bedeutet, dass deine Baseline-Experience funktioniert. Punkt. HTML ist deine Grundlage. CSS fügt die visuelle Ebene hinzu. JavaScript -- falls du es brauchst -- fügt Interaktivität oben drauf hinzu. Jede Ebene ist additiv. Wenn eine Ebene fehlschlägt, funktionieren die Ebenen darunter immer noch.

In 2026 ist diese Philosophie praktischer denn je, weil sich die Baseline-Fähigkeiten von HTML und CSS dramatisch erweitert haben. Dinge, die vor fünf Jahren JavaScript brauchten, haben jetzt native Plattformlösungen:

  • Akkordeons und Disclosure-Widgets → <details> und <summary>
  • Modals und Dialoge → <dialog>-Element
  • Formularvalidierung → Constraint Validation API
  • Sanftes Scrollen → scroll-behavior: smooth
  • Dark Mode → @media (prefers-color-scheme) mit :has()-Selector-Tricks
  • Karussells → CSS Scroll Snap mit scrollbar-width
  • Popovers und Tooltips → Popover API
  • Anchor Positioning → CSS Anchor Positioning
  • View Transitions → View Transitions API (Level 2 für Cross-Document)

Die Web-Plattform in 2026 ist nicht die Web-Plattform von 2020. Wir haben eine massive Erweiterung dessen, was ohne Scripting möglich ist.

Die Plattform hat alles verändert

Die Popover API

Die Popover API erreichte vollständige Cross-Browser-Unterstützung 2024 und ist jetzt überall produktionsbereit, wo es darauf ankommt. Vorher brauchte jeder Tooltip, jedes Dropdown-Menü und jede Toast-Benachrichtigung JavaScript. Jetzt:

<button popovertarget="my-menu">Menu</button>
<nav popover id="my-menu">
  <a href="/about">About</a>
  <a href="/work">Work</a>
  <a href="/contact">Contact</a>
</nav>

Das war's. Klick den Button, das Popover erscheint. Klick außen, es verschwindet. Drücke Escape, es verschwindet. Der Focus wird verwaltet. Standardmäßig barrierefrei. Zero JavaScript.

CSS Anchor Positioning

Das ist dasjenige, das die Dinge wirklich geöffnet hat. Ein Tooltip relativ zu seinem Trigger zu positionieren brauchte früher JavaScript, um DOM-Positionen zu messen. CSS Anchor Positioning (Baseline in 2025, jetzt vollständig stabil) handhabt es deklarativ:

.trigger {
  anchor-name: --my-trigger;
}

.tooltip {
  position: fixed;
  position-anchor: --my-trigger;
  top: anchor(bottom);
  left: anchor(center);
  translate: -50% 8px;
}

Kombiniere das mit der Popover API und du hast vollständig positionierte, barrierefreie Tooltips ohne Client-seitigen Code.

Cross-Document View Transitions

View Transitions Level 2 ist das, das Zero-JS-Sites wie SPAs fühlen lässt. Du fügst eine CSS-Regel hinzu und plötzlich haben Navigationen zwischen Seiten sanfte animierte Übergänge:

@view-transition {
  navigation: auto;
}

::view-transition-old(root) {
  animation: fade-out 0.2s ease;
}

::view-transition-new(root) {
  animation: fade-in 0.2s ease;
}

Chrome, Edge und Safari unterstützen das jetzt. Firefox sollte später dieses Jahr folgen. Diese eine Feature eliminiert einen der größten Gründe, warum Teams SPAs wählten -- wahrgenommene Performance durch animierte Übergänge.

Der `:has()`-Selector

Der :has()-Selector (manchmal "Parent Selector" genannt) ist seit 2024 stabil und er ist wirklich transformativ für CSS-only-Interaktivität:

/* Dark Mode ohne JS umschalten */
html:has(#dark-mode:checked) {
  color-scheme: dark;
  --bg: #1a1a2e;
  --text: #eee;
}

Mit einer versteckten Checkbox und einem <label> hast du einen funktionierenden Dark-Mode-Toggle. Kein JavaScript. Der Status bleibt während der Sitzung erhalten und du kannst ihn sogar mit einem winzigen Enhancement-Script auf localStorage synchronisieren, wenn du Persistenz über Besuche hinweg möchtest.

CSS-Only-Muster, die JavaScript ersetzen

Lass mich die Muster katalogisieren, die wir regelmäßig nutzen. Ich spreche nicht über CSS-Kunst oder Novelty-Demos -- das sind produktive Muster, die wir an echte Clients ausliefern.

| Muster | Alter Ansatz (JS) | 2026 Ansatz (CSS/HTML) | Browser-Unterstützung | |--------|-------------------|--------------------------|------------------|| | Dropdown-Menüs | Event Listener, Focus Traps | Popover API + :has() | 95%+ | | Akkordeons | Toggle Classes, ARIA Management | <details> + ::details-content | 96%+ | | Modals | Focus Trap Bibliotheken, Scroll Lock | <dialog> + ::backdrop | 97%+ | | Tabs | Show/Hide Panels, ARIA Tabs | Radio Buttons + :has() + scroll-snap | 95%+ | | Karussells | Swiper.js, Flickity | scroll-snap + scroll-timeline | 93%+ | | Tooltips | Popper.js, Floating UI | Popover API + Anchor Positioning | 90%+ | | Formularvalidierung | Custom Validation Logic | Constraint Validation + :user-valid | 95%+ | | Scroll-Animationen | Intersection Observer, GSAP | animation-timeline: scroll() | 88%+ | | Theme Toggle | localStorage + DOM Manipulation | Checkbox + :has() + color-scheme | 96%+ | | Page Transitions | Client-seitige Routing | Cross-Document View Transitions | 85%+ |

Diese Tabelle stellt wahrscheinlich 80% der interaktiven Muster auf einer typischen Marketing-Site oder Content-Plattform dar. Alles ohne Auslieferung eines einzigen Kilobytes JavaScript erreichbar.

Das Tabs-Muster

Hier ist eins, das mir besonders gefällt. CSS-only Tabs mit Radio Buttons:

<div class="tabs">
  <input type="radio" name="tab" id="tab1" checked>
  <label for="tab1">Features</label>
  <input type="radio" name="tab" id="tab2">
  <label for="tab2">Pricing</label>
  <input type="radio" name="tab" id="tab3">
  <label for="tab3">FAQ</label>
  
  <div class="panels">
    <div class="panel" id="panel1">Features content...</div>
    <div class="panel" id="panel2">Pricing content...</div>
    <div class="panel" id="panel3">FAQ content...</div>
  </div>
</div>

.tabs:has(#tab1:checked) .panels { --active: 0; }
.tabs:has(#tab2:checked) .panels { --active: 1; }
.tabs:has(#tab3:checked) .panels { --active: 2; }

.panels {
  display: flex;
  overflow: hidden;
  translate: calc(var(--active) * -100%) 0;
  transition: translate 0.3s ease;
}

.panel {
  min-width: 100%;
}

Sanfter, animierter Tab-Wechsel ohne JavaScript. Füge role="tablist" und passende ARIA-Attribute für Barrierefreiheit hinzu und du hast eine produktionsreife Komponente.

Progressive Enhancement & Zero-JS Websites in 2026 - architecture

HTML-First-Interaktivität

Über CSS hinaus ist HTML selbst viel fähiger geworden. Lass mich Muster hervorheben, die wir nutzen.

Das ``-Element

Ich weiß, dass <dialog> schon eine Weile gibt, aber viele Teams greifen immer noch zu einer Modal-Bibliothek. Nicht tun. Das native Dialog handhabt Focus Trapping, Scroll Locking, Escape zum Schließen und das ::backdrop Pseudo-Element für Overlays.

Der eine Haken: du brauchst ein winziges bisschen JavaScript, um ein Modal Dialog zu öffnen (Aufrufen von .showModal()). Aber für progressive Enhancement kannst du den Trigger zu einem Link auf einer separaten Seite machen, dann mit JS erweitern, wenn verfügbar:

<a href="/contact" class="js-dialog-trigger" data-dialog="contact-form">
  Get in touch
</a>

<dialog id="contact-form">
  <form method="dialog">
    <!-- form fields -->
    <button type="submit">Send</button>
  </form>
</dialog>

Ohne JavaScript: der Benutzer navigiert zu /contact. Mit JavaScript: das Dialog öffnet sich inline. Beide funktionieren. Das ist progressive Enhancement.

Formulare ohne JavaScript

Formulare sind der größte Gewinn für Zero-JS-Ansätze. Native HTML-Formulare senden Daten an Server. Das ist, wofür sie designed wurden. Mit modernen Server-seitigen Frameworks brauchst du keine e.preventDefault() und fetch()-Aufrufe:

<form action="/api/contact" method="POST">
  <input type="email" name="email" required>
  <textarea name="message" required minlength="10"></textarea>
  <button type="submit">Send</button>
</form>

Die :user-valid und :user-invalid Pseudo-Classes (jetzt Baseline) lassen dich Validierungszustände ohne JS stylen, aber nur nach Benutzerinteraktion -- keine roten Borders beim Seitenladen mehr.

input:user-invalid {
  border-color: var(--error);
  outline-color: var(--error);
}

input:user-valid {
  border-color: var(--success);
}

Server-seitige Frameworks, die Zero-JS ausliefern

Die Wahl des richtigen Frameworks ist für progressive Enhancement enorm wichtig. Hier ist, wie die großen Player in 2026 sich stapeln.

Astro

Astro bleibt der Gold Standard für Zero-JS-Output. Es liefert HTML und CSS standardmäßig aus und du entscheidest dich für JavaScript pro-Komponente mit client:-Direktiven. Wir nutzen es umfangreich für Marketing-Sites, Dokumentation und Content-Heavy-Plattformen -- siehe unsere Astro-Entwicklungsfähigkeiten für Einzelheiten.

---
// Diese Komponente liefert ZERO JavaScript aus
const posts = await fetch('https://api.example.com/posts').then(r => r.json());
---
<ul>
  {posts.map(post => <li><a href={post.url}>{post.title}</a></li>)}
</ul>

Astro 5 (stabil seit Anfang 2025) fügte Server Islands und verbesserte Content Layer APIs hinzu. Das mentale Modell ist einfach: alles wird server-rendered, es sei denn, du sagst explizit etwas anderes.

Eleventy (11ty)

Eleventy 3.0 bleibt ausgezeichnet für Zero-JS-Sites. Es ist ein reiner Static Site Generator -- keine Meinungen über Client-seitiges JavaScript überhaupt. Falls du es möchtest, fügst du es manuell hinzu. Wir haben es ideal für kleinere Sites und Blogs gefunden, wo die Build-Zeit-Einfachheit zählt.

Next.js mit Server Components

Next.js ist interessant hier. Server Components (das Default in App Router) liefern kein JavaScript an den Client aus. Aber die Next.js Runtime selbst fügt ein Baseline-JS-Payload für Hydration, Routing und Prefetching hinzu. Du kannst mit Next.js nicht zu echtem Zero-JS kommen, aber du kannst erschreckend nah dran kommen für interaktive Anwendungen. Check unsere Next.js-Entwicklungsarbeit aus -- wir haben diese Grenze auf mehreren Projekten verschoben.

SvelteKit

SvelteKit lässt dich JavaScript pro-Seite mit export const csr = false deaktivieren. Der Output ist reines HTML/CSS. Es ist ein großartiger Mittelweg -- du bekommst die Developer Experience von Svelte Components aber kannst selektiv Client-seitiges Rendering deaktivieren.

| Framework | Standard-JS-Output | Zero-JS Möglich? | Am besten für | |-----------|-------------------|--------------------|----------|| | Astro 5 | 0 KB | Ja (Standard) | Content-Sites, Marketing | | Eleventy 3 | 0 KB | Ja (Standard) | Blogs, Docs, Simple Sites | | Next.js 15 | ~85-100 KB | Nein (Runtime erforderlich) | Web Apps, Dynamic Content | | SvelteKit 2 | ~15-25 KB | Ja (Pro-Page Opt-out) | Hybrid Sites | | Fresh (Deno) | 0 KB | Ja (Island Architecture) | Deno-basierte Projekte | | Enhance | 0 KB | Ja (HTML-First) | Web Component Sites |

Wann Zero-JavaScript die falsche Wahl ist

Ich würde dir einen Bärendienst erweisen, wenn ich nur über die Zeiten spreche, wenn Zero-JS funktioniert. Hier ist, wenn es nicht funktioniert:

Echtzeit-Zusammenarbeit. Falls du etwas wie Figma, Google Docs oder eine Chat-Anwendung baust, brauchst du WebSockets und Client-seitige State-Management. Es gibt keinen Weg um es herum.

Komplexe Datenvisualisierung. D3, Observable Plot oder deck.gl für Karten -- diese brauchen JavaScript. Du könntest statische Charts als SVG server-rendern (und wir tun das), aber alles Interaktive braucht Client-Code.

Rich-Text-Editoren. ProseMirror, TipTap, Lexical -- diese sind inhärent Client-seitige Anwendungen. Progressive Enhancement hier bedeutet Bereitstellung eines <textarea>-Fallbacks, das ist eigentlich ziemlich vernünftig.

Client-seitige Suche. Falls du sofortige Such-während-du-tippst ohne Server-Hit auf jedem Keystroke möchtest, brauchst du Client-seitige Suchindizes (Pagefind, Lunr, Fuse.js). Pagefind ist besonders erwähnenswert -- es ist ein Build-Zeit-Suchindex, der nur ~5 KB initial lädt.

Authentifizierungs-Flüsse. OAuth-Redirects funktionieren ohne JS, aber Token-Refresh, Session-Management und geschützte Client-seitige Routen brauchen typischerweise ein bisschen Scripting.

Video/Audio-Player. Custom Player brauchen JavaScript. Aber <video> und <audio> Elemente mit nativen Controls funktionieren perfekt ohne.

Das Muster, das ich empfehle: starten mit Zero-JS und füge es chirurgisch dort hinzu, wo die User Experience es wirklich verlangt. Das ist genau das, was Astros Island Architecture ermöglicht -- 95% der Seite ist statisches HTML und das eine interaktive Widget wird hydrated.

Performance-Benchmarks: JS vs. Zero-JS

Wir haben die Performance über unsere Client-Projekte verfolgt. Hier sind echte Zahlen aus Production-Sites, die wir in 2025-2026 gebaut haben.

| Metrik | Typische React SPA | Next.js (App Router) | Astro (Zero-JS) | Verbesserung | |--------|-------------------|---------------------|------------------|-------------|| | First Contentful Paint | 1.8s | 0.9s | 0.4s | 78% schneller | | Largest Contentful Paint | 2.5s | 1.3s | 0.6s | 76% schneller | | Time to Interactive | 3.2s | 1.8s | 0.4s | 87% schneller | | Total Blocking Time | 450ms | 180ms | 0ms | 100% Reduktion | | JS Transfer Size | 280 KB | 105 KB | 0 KB | 100% Reduktion | | Lighthouse Performance | 65-75 | 85-95 | 100 | -- | | Core Web Vitals Pass Rate | 55% | 82% | 99% | -- |

Diese Zahlen zählen für echte Business-Ergebnisse. Google ist zunehmend transparent über CWV-Auswirkungen auf Search-Rankings. Eine 2025-Studie von Searchmetrics fand heraus, dass Sites, die alle Core Web Vitals bestanden, 24% höhere durchschnittliche Ranking-Positionen hatten als diejenigen, die fehlschlagen. Und diese Lücke wächst.

Für unsere Clients haben wir gemessene Verbesserungen gesehen: eine E-Commerce-Marke sah eine 15% Anstieg im organischen Traffic nach Migration von einer React SPA zu einem Astro-basierten Storefront mit selektiver Hydration. Ihre Headless-CMS-Architektur blieb gleich -- wir änderten nur, wie das Frontend Content konsumierte und renderte.

Aufbau einer Progressive-Enhancement-Strategie

Hier ist das praktische Playbook, das wir folgen:

Schritt 1: Audit dein JavaScript

Bevor du etwas Neues baust, schau dir an, was JavaScript du jetzt auslieferst und frage: muss das auf dem Client laufen?

# Schnelle Weise, JS-Verwendung in Chrome DevTools zu prüfen
# Coverage Tab → Reload → Sehe, wie viel JS tatsächlich executed

Wir finden regelmäßig heraus, dass 40-60% des ausgelieferten JavaScript nie bei initialer Page Load executed. Es ist Dead Code, ungenutzte Polyfills oder Features, die nicht getriggert wurden.

Schritt 2: Kategorisiere deine Interaktivität

Lege jede interaktive Feature in einen von drei Buckets:

  1. Platform-Native -- Kann nur mit HTML/CSS gemacht werden (nutze Plattform)
  2. Enhancement -- Funktioniert ohne JS, besser mit ihm (Progressive Enhancement)
  3. Braucht JS -- Unmöglich ohne Client-seitigen Code (liefere es)

Sei ehrlich mit dir selbst. Die meisten Dinge landen in Bucket 1 oder 2.

Schritt 3: Wähle das richtige Framework

Falls du eine Content-Site, Dokumentation, Marketing-Seiten oder einen Blog baust -- greife zu Astro oder Eleventy. Wähle nicht Next.js für eine Marketing-Site nur weil dein Team React kennt. Der architektonische Mismatch kostet dich Performance.

Falls du eine Anwendung mit signifikanter Client-seitiger Interaktivität baust, macht Next.js oder SvelteKit mit selektiver Server-Rendering mehr Sinn. Nutze Server Components wo möglich und Client Components nur wo notwendig.

Wir helfen Teams diese Entscheidungen genau zu treffen -- schau dir unsere Fähigkeiten an oder kontaktiere uns, falls du deine spezifische Situation durchsprechen möchtest.

Schritt 4: Teste ohne JavaScript

Das ist der Schritt, den jeder überspringt. Deaktiviere JavaScript in deinem Browser und navigiere deine Site. Funktioniert es? Können Benutzer:

  • Content lesen? ✓
  • Zwischen Seiten navigieren? ✓
  • Formulare einreichen? ✓
  • Kritische Informationen abrufen? ✓

Falls nicht, hat deine Enhancement-Strategie Löcher.

Echte Architektur für Zero-JS-Sites

Lass mich eine konkrete Architektur teilen, die wir für mehrere Client-Projekte genutzt haben:

┌─────────────────────────────────────────┐
│              CDN (Cloudflare)            │
│         Static HTML/CSS assets          │
├─────────────────────────────────────────┤
│          Astro SSG / SSR Layer          │
│     Fetches content at build/request    │
├─────────────────────────────────────────┤
│            Headless CMS                 │
│    (Sanity / Storyblok / Payload)       │
├─────────────────────────────────────────┤
│          Form Handler Service           │
│     (Cloudflare Workers / Resend)       │
└─────────────────────────────────────────┘

Content lebt in einem Headless CMS. Astro zieht es bei Build-Zeit (oder Request-Zeit für häufig aktualisiertem Content). Der Output ist reines HTML und CSS, deployed an einem CDN Edge. Formulare submitten an eine Serverless Function, die Validierung und Email-Zustellung handhabt.

Das ganze Frontend hat Zero JavaScript. Das CMS gibt Content-Editoren eine große Experience. Formulare funktionieren ohne Client-seitigen Code. Page Transitions nutzen Cross-Document View Transitions. Es ist schnell, barrierefrei und widerstandsfähig.

Für Sites, die selektive Interaktivität brauchen -- sagen wir, ein Product Configurator auf einer Seite -- nutzen wir Astros Island Architecture, um nur diese Komponente zu hydrate. Der Rest der Site bleibt statisch.

Das ist die Art Architektur, die wir regelmäßig bauen. Falls du neugierig auf Pricing für diesen Ansatz bist, check unsere Pricing-Seite -- Zero-JS-Sites sind typischerweise schneller zu bauen und billiger zu hosten.

FAQ

Ist Progressive Enhancement immer noch relevant in 2026?

Relevanter denn je. Mit 95%+ Browser-Unterstützung für Features wie die Popover API, CSS :has(), View Transitions und <dialog>, kann die Web-Plattform Interaktivität handhaben, die früher JavaScript verlangte. Progressive Enhancement ist keine Philosophie aus der Vergangenheit -- es ist eine praktische Engineering-Strategie, die zu schnelleren, widerstandsfähigeren und barrierefreieren Websites führt.

Kannst du eine ganze Website mit Zero-JavaScript bauen?

Absolut. Marketing-Sites, Blogs, Dokumentation, Portfolios und sogar E-Commerce-Storefronts können mit Zero Client-seitigen JavaScript gebaut werden. Formulare submitten nativ, Navigation nutzt Standard-Links (mit View Transitions für Polish) und interaktive Komponenten wie Akkordeons, Modals und Tooltips haben alle HTML/CSS-native Lösungen. Die Sites, die du nicht ohne JS bauen kannst, sind Echtzeit-Apps, Rich-Text-Editoren und komplexe Datenvisualisierungen.

Wie beeinflußt Zero-JavaScript SEO?

Positiv, in fast jedem Fall. Suchmaschinen können HTML-Content sofort indexieren ohne auf JavaScript-Execution zu warten. Core Web Vitals Scores verbessern sich dramatisch -- besonders Total Blocking Time, was auf null fällt. Googles Ranking-Systeme belohnen schnelle, barrierefreie Seiten und Zero-JS-Sites erreichen konsistent höhere Lighthouse Scores und bessere CWV Pass-Raten.

Was ist das beste Framework für Zero-JavaScript-Websites in 2026?

Astro ist die stärkste Wahl für die meisten Zero-JS-Projekte. Es gibt Zero JavaScript standardmäßig aus und lässt dich Client-seitige Interaktivität pro-Komponente wenn nötig hinzufügen. Eleventy ist eine weitere ausgezeichnete Option für einfachere Sites. Beide haben reife Ecosysteme, gute Dokumentation und aktive Communities. Die Wahl zwischen ihnen kommt meist darauf an, ob du komponentenbasierte Authoring (Astro) oder Template-basierte Einfachheit (Eleventy) möchtest.

Funktionieren CSS-only interaktive Komponenten für Barrierefreiheit?

Native HTML-Elemente wie <details>, <dialog> und die Popover API sind standardmäßig barrierefrei -- sie handhaben Focus-Management, Keyboard-Navigation und ARIA-Semantik automatisch. CSS-only Muster mit Checkbox-Hacks brauchen mehr Sorgfalt: du solltest passende ARIA-Rollen hinzufügen und Keyboard-Operabilität sicherstellen. Generell sind native HTML-Lösungen barrierefreier als custom JavaScript Implementierungen, weil Browser-Vendor die Barrierefreiheit-Arbeit für dich getan haben.

Wie funktionieren View Transitions ohne JavaScript?

Cross-Document View Transitions (Level 2 der Spec) funktionieren vollständig durch CSS. Du fügst eine @view-transition { navigation: auto; } Regel hinzu und der Browser erstellt automatisch animierte Übergänge zwischen Page-Navigationen. Du kannst die Animationen mit ::view-transition-old() und ::view-transition-new() Pseudo-Elementen customizen. Kein JavaScript erforderlich. Chrome, Edge und Safari unterstützen das in 2026, Firefox-Unterstützung wird bald erwartet.

Welcher Prozentanteil der User hat JavaScript deaktiviert?

Nur etwa 1-2% der User deaktivieren aktiv JavaScript. Aber das ist nicht der Punkt. JavaScript fehlgeschlagen für viele mehr User als das -- flaky Connections, Corporate Firewalls, Browser Extensions, CDN Outages und Parsing Errors verursachen alle JS-Fehler. Der UK Government Digital Service fand heraus, dass 1.1% der User JavaScript Enhancements nicht bekamen, obwohl JS enabled war. Progressive Enhancement schützt all diese User.

Kann ich ein Headless CMS mit einem Zero-JavaScript Frontend nutzen?

Ja, und es ist eine der besten Kombinationen. Das CMS bietet eine große Edit-Experience für Content-Teams, während das Frontend (gebaut mit Astro oder Eleventy) Content bei Build-Zeit über API konsumiert und reines HTML/CSS ausspuckt. Das CMS JavaScript läuft im Editor's Browser, nicht in deinen Visitors Browsern. Diese Entkopplung gibt dir das Beste von beiden Welten: großartige Authoring Experience und Zero-JS Performance für End User.