WordPress zu Astro: Wie wir Lighthouse 100 beim Rebuild erreichten
Ehrlich gesagt: Unsere alte WordPress-Website war peinlich. Nicht weil sie schlecht aussah — sie sah eigentlich ziemlich gut aus. Aber unter der Haube? Eine Time to Interactive von 3,2 Sekunden, ein Lighthouse-Performance-Score um die 58 und ein Plugin-Stapel, der sich bei jedem Deployment wie das Entschärfen einer Bombe anfühlte. Wir sind eine Web-Development-Agentur. Wir bauen schnelle Websites für Kunden. Und unsere eigene Website war... nicht schnell.
Also haben wir sie abgerissen und mit Astro neu aufgebaut. Das Ergebnis: perfekte 100er in allen vier Lighthouse-Kategorien — Performance, Accessibility, Best Practices und SEO. Nicht auf einer einzelnen Seite. Auf jeder Seite. Das ist die Geschichte, wie wir dorthin kamen, was unterwegs kaputtging und was wir anders machen würden.
Inhaltsverzeichnis
- Warum wir WordPress verlassen haben
- Warum wir uns für Astro entschieden haben
- Die Migrationsstrategie
- Architekturentscheidungen, die den Unterschied machten
- Performance-Optimierungen im Detail
- Die Lighthouse-100-Auswertung
- Vorher und nachher: Die Zahlen
- Was wir unterwegs falsch gemacht haben
- Lektionen für Ihre eigene Migration
- FAQ
Warum wir WordPress verlassen haben
Schauen Sie, WordPress betreibt etwa 43% des Webs. Es ist keine schlechte Plattform. Wir haben viele WordPress-Websites für Kunden gebaut und werden das weiterhin tun, wenn es die richtige Wahl ist. Aber für unsere eigene Agentur-Website — eine überwiegend statische Marketing-Website mit einem Blog — war WordPress ein Overkill in der schlimmsten Form.
So sah unser WordPress-Setup aus:
- Theme: Custom Theme basierend auf Sage (Roots.io)
- Plugins: 14 aktive Plugins, darunter Yoast SEO, WP Rocket, Advanced Custom Fields Pro, Gravity Forms und noch einige andere
- Hosting: WP Engine Professional Plan für 60 $/Monat
- CDN: Cloudflare Pro für 20 $/Monat
- Build-Komplexität: PHP-Templating, Webpack für Assets, MySQL-Datenbank
Selbst mit WP Rocket, das aggressives Caching betrieb, waren unsere Core Web Vitals mittelmäßig. Die Largest Contentful Paint (LCP) lag auf dem Mobilgerät bei 2,4 Sekunden. Cumulative Layout Shift (CLS) lag bei 0,12 — nicht schrecklich, aber nicht gut. Und jedes Mal, wenn wir ein Plugin aktualisierten, bestand eine gewisse Wahrscheinlichkeit, dass etwas kaputtgehen würde.
Das Echte Problem? Wir zahlten 80 $/Monat für Hosting-Kosten für eine Website, die etwa 3.000 Besuche pro Monat hatte. Das ist nicht viel Traffic, und das ist viel Geld für das, was im Grunde eine Broschüren-Website mit einem Blog war.
Der Wendepunkt
Der letzte Strohhalm kam im Januar 2025. Ein WordPress-Core-Update brach unsere benutzerdefinierten Gutenberg-Blöcke. Das Beheben erforderte die Aktualisierung von ACF Pro, was die Aktualisierung unserer Theme-PHP-Versionskompatibilität erforderte, was die Aktualisierung der Hosting-Umgebung erforderte. Was eine routinemäßige Aktualisierung hätte sein sollen, wurde zu einem ganzen Arbeitstag.
Ich sagte zu unserem Team: „Wir empfehlen Kunden, auf Headless zu gehen. Warum essen wir nicht selbst unser eigenes Essen?"
Warum wir uns für Astro entschieden haben
Wir evaluierten vier Optionen für den Neuaufbau:
| Framework | Vorteile | Nachteile | Unser Fazit |
|---|---|---|---|
| Next.js | Wir kennen es gut, großes Ökosystem | Zu viel für eine Content-Website, erfordert Server oder Edge-Runtime | Zu schwer |
| Astro | Content-fokussiert, sendet standardmäßig null JS, Island-Architektur | Kleineres Ökosystem, neuere | Perfekter Fit |
| Eleventy | Einfach, schnelle Builds, reif | Begrenztes Komponenten-Modell, weniger modernes DX | Knapp dahinter |
| Hugo | Blitzschnelle Builds, einzelnes Binär | Go-Templating ist schmerzhaft, begrenzte Flexibilität | Nicht für uns |
Wir bauen viele Next.js-Projekte für Kunden, und es ist unsere erste Wahl für alles mit dynamischer Funktionalität. Aber für eine inhaltsreiche Marketing-Website? Next.js sendet unabhängig davon eine JavaScript-Runtime zum Browser. Selbst mit statischem Export wird React an den Browser gesendet.
Astros Philosophie sprach uns an: Sendet HTML, fügt JavaScript nur dort hinzu, wo ihr es braucht. Ihre Island-Architektur bedeutet, dass Sie eine vollständig interaktive React-Komponente neben völlig statischem HTML haben können, und die statischen Teile senden null JavaScript. Das war genau das, was wir brauchten.
Wir hatten auch während des ganzen Jahres 2024 mehr Astro-Entwicklungsarbeit für Kunden geleistet, also war das Team mit dem Framework vertraut. Es war keine Lernübung — es war ein Werkzeug, dem wir bereits vertrauten.
Die Frage der Content-Ebene
Eine Entscheidung, die wir früh trafen: Wir würden keinen Headless CMS für unsere eigene Website verwenden. Für Client-Projekte empfehlen wir oft Headless-CMS-Setups mit Contentful, Sanity oder Storyblok. Aber für unseren Blog, bei dem jeder Autor ein Entwickler ist, der mit Markdown und Git vertraut ist? Content Collections in Astro mit MDX-Dateien, die ins Repo committed sind, war einfacher und schneller.
Keine API-Aufrufe zur Build-Zeit. Kein Content Delivery Network für Inhalte. Kein zusätzlicher Service, den man verwalten oder bezahlen muss. Nur Dateien in einem Ordner.
Die Migrationsstrategie
Wir machten keine Big-Bang-Migration. Hier ist unser phasierter Ansatz:
Phase 1: Content-Audit (1 Woche)
Wir exportierten alle WordPress-Inhalte mit wp-cli und konvertierten Posts mit einem benutzerdefinierten Script mit turndown (HTML-zu-Markdown-Konverter) plus etwas Regex-Cleanup in MDX. Wir hatten damals 47 Blog-Posts. Etwa 12 davon waren veraltet oder gering performant, also leiteten wir diese auf relevantere neuere Inhalte um und migrierten sie nicht.
Phase 2: Design System in Astro (2 Wochen)
Wir bauten unsere Komponenten-Bibliothek als Astro-Komponenten um. Buttons, Cards, Section Layouts, Navigation — alle als .astro-Dateien. Für keine davon war ein Framework nötig. Reines HTML und CSS mit scoped Styles.
Phase 3: Page Build (2 Wochen) Startseite, Capability-Seiten, About, Contact, Blog-Listing, einzelne Blog-Posts, 404. Wir bauten sie alle als Astro-Seiten mit unserer Komponenten-Bibliothek.
Phase 4: Performance Tuning (1 Woche) Hier fand die echte Lighthouse-100-Arbeit statt. Mehr dazu unten.
Phase 5: Launch und Redirect (2 Tage) Wir richteten ordnungsgemäße 301-Umleitungen für jede alte URL ein, verifizierten mit Screaming Frog, dass nichts kaputtwar, reichten die neue Sitemap bei der Google Search Console ein und wechselten DNS.
Gesamtzeitrahmen: etwa 6 Wochen Teilzeitarbeit neben Client-Projekten.
Architekturentscheidungen, die den Unterschied machten
Null JavaScript standardmäßig
Unsere gesamte Website wird mit ungefähr 2KB JavaScript insgesamt ausgeliefert. Das ist kein Tippfehler. Zwei Kilobyte. Und das meiste davon ist ein kleines Script für die mobile Navigation-Toggle und Analytics.
Hier ist unsere mobile Navigation — kein Framework, keine Abhängigkeiten:
---
// MobileNav.astro
---
<button id="menu-toggle" aria-expanded="false" aria-controls="mobile-menu">
<span class="sr-only">Menü umschalten</span>
<svg><!-- Hamburger-Icon --></svg>
</button>
<nav id="mobile-menu" hidden>
<slot />
</nav>
<script>
const toggle = document.getElementById('menu-toggle');
const menu = document.getElementById('mobile-menu');
toggle?.addEventListener('click', () => {
const expanded = toggle.getAttribute('aria-expanded') === 'true';
toggle.setAttribute('aria-expanded', String(!expanded));
menu?.toggleAttribute('hidden');
});
</script>
Das <script>-Tag in einer Astro-Komponente wird automatisch gebündelt und dedupliziert. Es ist winzig, es ist Vanilla JS, und es funktioniert überall.
CSS-Strategie: Scoped Styles + eine minimale globale Ebene
Wir verwendeten Astros eingebaute scoped CSS für Komponenten-Level-Styles und ein einzelnes globales Stylesheet (etwa 8KB minifiziert) für Typografie, Reset, Custom Properties und Utility-Klassen. Kein Tailwind. Umstrittener Take, ich weiß.
Wir lieben Tailwind für größere Anwendungen und Client-Projekte. Aber für eine Website dieser Größe hat es Build-Komplexität und Dateigröße hinzugefügt, die wir nicht brauchten. Unser handgeschriebenes CSS ist kleiner, als Tailwinds Output auch mit Purging hätte sein sollen.
/* Globale Custom Properties */
:root {
--color-text: #1a1a2e;
--color-bg: #ffffff;
--color-accent: #e94560;
--color-accent-dark: #c81e45;
--font-body: 'Inter', system-ui, sans-serif;
--font-heading: 'Cal Sans', var(--font-body);
--max-width: 72rem;
--space-unit: 0.25rem;
}
Statische Generierung mit intelligentem Preloading
Jede Seite wird zur Build-Zeit statisch generiert. Wir verwenden Astros eingebaute prefetch-Integration, um Links bei Hover vorzuladen, was Navigation augenblicklich fühlt:
// astro.config.mjs
import { defineConfig } from 'astro/config';
import mdx from '@astrojs/mdx';
import sitemap from '@astrojs/sitemap';
export default defineConfig({
site: 'https://socialanimal.dev',
integrations: [mdx(), sitemap()],
prefetch: {
prefetchAll: false,
defaultStrategy: 'hover',
},
build: {
inlineStylesheets: 'auto',
},
});
Performance-Optimierungen im Detail
Um zu Lighthouse 100 zu gelangen, geht es nicht nur darum, das richtige Framework zu wählen. Astro gibt dir einen guten Start, aber die letzten 10-15 Punkte erfordern bewusste Anstrengung. Hier ist, was wir getan haben.
Bildoptimierung
Astros eingebaute <Image />-Komponente handhabt responsive Bilder mit automatischer Formatkonvertierung (WebP/AVIF), Lazy Loading und ordnungsgemäßen width/height-Attributen, um CLS zu verhindern.
---
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.jpg';
---
<Image
src={heroImage}
alt="Social Animal-Entwicklungsteam, das an Headless-Architektur arbeitet"
widths={[400, 800, 1200]}
sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px"
format="avif"
fallbackFormat="webp"
quality={80}
loading="eager"
/>
Für das Hero-Bild verwenden wir speziell loading="eager", da es über dem Fold liegt. Alles andere bekommt standardmäßig loading="lazy".
Wir gingen auch durch jedes Bild auf der Website und fragten: „Muss das ein Bild sein?" Mehrere dekorative Elemente wurden stattdessen zu CSS-Gradienten oder SVGs. Unser Hero-Sektioneningung-Hintergrund ist zum Beispiel ein CSS-Gradient mit einer subtilen Rausch-Textur, die über ein winziges Inline-SVG angewendet wird.
Font-Loading-Strategie
Schriften sind ein Lighthouse-Killer. Hier ist unser Ansatz:
Alles selbst hosten. Kein Google Fonts CDN. Wir haben Inter und Cal Sans heruntergeladen und servieren sie von unserer eigenen Domain. Das beseitigt eine DNS-Abfrage, TCP-Verbindung und TLS-Handshake zu fonts.googleapis.com.
Aggressiv subsetten. Wir verwendeten
glyphhanger, um zu analysieren, welche Zeichen wir tatsächlich verwenden, und subsettierten dann unsere Fonts mitpyftsubset. Unser Inter Regular WOFF2 ging von 96KB auf 18KB.Verwende
font-display: swapmit einem sorgfältig ausgewählten System-Font-Fallback, das Metriken eng übereinstimmt, um Layout-Shift während des Swaps zu minimieren.Preload die kritischen Font-Dateien:
<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin />
<link rel="preload" href="/fonts/cal-sans-latin-600.woff2" as="font" type="font/woff2" crossorigin />
Hosting: Cloudflare Pages
Wir wechselten von WP Engine (60 $/Monat) zu Cloudflare Pages (kostenlos). Ja, kostenlos. Unsere Website bleibt gut innerhalb der Limits von Cloudflares kostenlosem Plan — 500 Builds pro Monat, unbegrenzte Bandbreite, unbegrenzte Anfragen.
Cloudflare Pages wird von Git Push aus bereitgestellt, von ihrem globalen Edge-Netzwerk bedient und handhabt Cache-Header automatisch. Die Build-Zeiten betragen durchschnittlich 22 Sekunden für unsere gesamte Website. Vergleichen Sie das mit unserem WordPress-Setup, bei dem eine Cache-Bereinigung allein länger dauern konnte.
Die monatlichen Hosting-Kosten sanken von 80 $ auf 0 $.
Kritisches CSS-Inlining
Astro inlinet automatisch kleine Stylesheets, wenn Sie build.inlineStylesheets: 'auto' setzen. Für unsere Seiten wird jeder kritische Style in den <head> inlinet, was bedeutet, dass es keine render-blocking CSS-Anfragen gibt. Der Browser kann sofort mit dem Malen beginnen.
Third-Party-Script-Disziplin
Hier verlieren die meisten Websites ihre perfekten Scores. Jedes Third-Party-Script ist eine potenzielle Performance-Katastrophe. Wir limitierten unsere gnadenlos:
- Analytics: Wechsel von Google Analytics (70 KB+ JavaScript) zu Plausible Analytics (< 1 KB Script, asynchron geladen). Wir zahlen 9 $/Monat für Plausible, und die Datenqualität ist ehrlich gesagt besser für unsere Bedürfnisse.
- Formulare: Unser Kontaktformular auf /contact verwendet ein einfaches HTML-Formular mit serverseitiger Handhabung über Cloudflare Pages Functions. Kein JavaScript-Formular-Bibliothek.
- Keine Chat-Widgets. Keine Social-Media-Embeds. Keine Cookie-Zustimmungs-Banner (wir verwenden keine Cookies, die Zustimmung erfordern).
Die Lighthouse-100-Auswertung
Hier sind unsere tatsächlichen Lighthouse-Scores ab Mai 2025, gemessen mit Chrome DevTools auf einer gedrosselten Verbindung (Standard-Lighthouse-Mobil-Simulation):
| Metrik | Score |
|---|---|
| Performance | 100 |
| Accessibility | 100 |
| Best Practices | 100 |
| SEO | 100 |
| First Contentful Paint | 0,6s |
| Largest Contentful Paint | 0,8s |
| Total Blocking Time | 0ms |
| Cumulative Layout Shift | 0 |
| Speed Index | 0,8s |
Die Total Blocking Time von 0ms ist meine Lieblings-Statistik. Null. Es gibt im Grunde kein JavaScript, das den Main Thread blockiert. Überhaupt nicht.
Vorher und nachher: Die Zahlen
| Metrik | WordPress (Vorher) | Astro (Nachher) | Verbesserung |
|---|---|---|---|
| Lighthouse Performance | 58 | 100 | +72% |
| LCP (mobil) | 2,4s | 0,8s | 3x schneller |
| CLS | 0,12 | 0 | Beseitigt |
| TBT | 380ms | 0ms | Beseitigt |
| Seitengröße (Startseite) | 1,8MB | 142KB | 92% kleiner |
| HTTP-Anfragen | 47 | 6 | 87% weniger |
| Versendetes JavaScript | 340KB | 2KB | 99,4% weniger |
| Monatliche Hosting-Kosten | 80 $ | 9 $ (nur Plausible) | 89% günstiger |
| Build/Deploy-Zeit | 3-5 min | 22 sec | ~10x schneller |
| Time to First Byte | 420ms | 18ms | 23x schneller |
Die Seitengröße-Reduktion ist selbst für uns atemberaubend. 1,8MB auf 142KB. Das ist, was passiert, wenn Sie aufhören, jQuery, React, WP Rockets Script-Loader, Yoasts Schema-Markup-Injector und vierzehn Plugin-Stylesheets zu versenden.
Was wir unterwegs falsch gemacht haben
Es war nicht alles glatt. Ehrlichkeitszeit.
Fehler 1: Wir hätten die Content-Verwaltung fast überabgewickelt
Unser erster Instinkt war, Sanity als Headless CMS für den Blog einzurichten. Wir verbrachten zwei Tage damit, Schemas zu konfigurieren und Sanity Studio einzurichten, bevor wir zurücktraten und fragten: „Wer wird das tatsächlich verwenden?" Die Antwort war... wir. Entwickler. Die sich perfekt wohl fühlen, MDX in VS Code zu schreiben. Wir rissen Sanity heraus und gingen mit Astro Content Collections. Sparage laufende Kosten und Komplexität.
Fehler 2: Font-Subsetting hat Sonderzeichen gebrochen
Unser anfängliches Font-Subset war zu aggressiv. Wir schälten Zeichen ab, von denen wir dachten, dass wir sie niemals verwenden würden, veröffentlichten dann einen Blog-Post mit einem Em-Strich und ein paar Anführungszeichen, die als Kästchen erschienen. Lektion: Testen Sie Ihre Subsets mit echten Inhalten, nicht nur „ABCDEFG."
Fehler 3: Wir vergaßen die OpenGraph-Bilder
Wir starteten ohne dynamische OG-Bilder. Wenn jemand einen Blog-Post auf Twitter/X oder LinkedIn teilte, zeigte es einen generischen Fallback. Wir mussten zurückgehen und eine OG-Bild-Generierungs-Pipeline mit @astrojs/og (die Satori unter der Haube verwendet) bauen. Hätte im ursprünglichen Umfang sein sollen.
Fehler 4: Die 301-Redirect-Map hatte Lücken
Trotz der Verwendung von Screaming Frog zum Zuordnen alter URLs, verpassten wir eine Handvoll Bild-URLs, auf die externe Websites verlinkt waren. Wir fanden diese etwa eine Woche nach dem Start in Cloudflares Analytics und fügten die fehlenden Umleitungen hinzu. Überprüfen Sie immer Ihre Server-Logs nach einer Migration — Google Search Console wird nicht alles erfassen.
Lektionen für Ihre eigene Migration
Wenn Sie in Betracht ziehen, von WordPress zu einem Static-First-Framework zu wechseln, hier ist, was ich Ihnen sagen würde:
Überwachen Sie, bevor Sie migrieren. Eliminieren Sie Inhalte, die nicht performant sind. Eine Migration ist eine großartige Gelegenheit zum Ausmisten.
Passen Sie das Werkzeug an die Aufgabe an. Astro war perfekt für uns, weil wir überwiegend Inhalte haben. Wenn Sie schwere Interaktivität brauchen, könnte Next.js oder ein ähnliches Framework die bessere Wahl sein.
Cargo-Cultify nicht Ihre alte Architektur. Wir versuchten nicht, unser WordPress-Setup in Astro zu replizieren. Wir überlegten alles von Grund auf neu. Brauchen wir wirklich ein Form-Plugin? Nein, ein
<form>-Element mit einer serverlosen Funktion funktioniert prima.Messen Sie vorher, messen Sie nachher, messen Sie kontinuierlich. Wir richteten einen Lighthouse-CI-Job in GitHub Actions ein, der bei jedem Pull Request läuft. Wenn ein PR einen Score unter 95 senkt, schlägt der Check fehl.
Budgetieren Sie für die „letzten 5%". Von Lighthouse 85 zu 95 zu gelangen, ist einfach. Von 95 zu 100 zu gelangen, erfordert Font-Subsetting, kritische CSS-Analyse, Bildformat-Optimierung und Third-Party-Script-Auditing. Planen Sie Zeit dafür ein.
Ihre Hosting-Kosten sollten Ihr altes Setup beschämen. Wenn Sie statische Dateien servieren und immer noch bedeutende Hosting-Gebühren zahlen, stimmt etwas nicht. Static Hosting ist jetzt eine Commodity.
Wenn Sie interessiert sind, wie eine solche Migration für Ihr Projekt aussehen würde, schauen Sie sich unsere Pricing-Seite an oder kontaktieren Sie uns. Wir haben diese Migrationsstrecke jetzt für mehrere Clients durchgeführt, und die Performance-Gewinne sind durchweg dramatisch.
FAQ
Wie lange dauert es, eine WordPress-Website zu Astro zu migrieren? Für unsere Website (etwa 50 Seiten inklusive Blog-Posts) dauerte es rund 6 Wochen Teilzeitarbeit. Eine größere Website mit Hunderten von Posts und komplexen benutzerdefinierten Post-Typen könnte 8-12 Wochen dauern. Die eigentliche Entwicklung ist normalerweise schneller als das Content-Audit und die Redirect-Zuordnung.
Können Sie mit Next.js statt Astro Lighthouse 100 erreichen? Es ist möglich, aber deutlich schwieriger. Next.js sendet eine JavaScript-Runtime zum Browser selbst für statische Seiten (die React-Hydrations-Schicht). Sie können nahe kommen — Scores von 95-99 sind mit sorgfältiger Optimierung erreichbar. Aber Astros Null-JS-standardmäßig-Ansatz macht perfekte Scores für Content-Websites viel erreichbarer.
Was ist mit WordPress-Funktionen wie Kontaktformularen und Suche? Kontaktformulare funktionieren prima mit einfachen HTML-Formularen und einem serverseitigen Funktions-Backend (Cloudflare Pages Functions, Netlify Functions, etc.). Für die Suche verwenden wir eine clientseitige Suche mit Pagefind, die einen Such-Index zur Build-Zeit erstellt und nur 5KB JavaScript versendet. Es ist schnell und funktioniert offline.
Schadet die Migration von WordPress zu Astro der SEO? Nicht, wenn Sie es ordnungsgemäß handhaben. Wir richteten 301-Umleitungen für jede URL ein, behielten unsere URL-Struktur wo möglich bei, reichten eine neue Sitemap ein und behielten alle strukturierten Daten. Unser organischer Traffic stieg tatsächlich in den drei Monaten nach der Migration um 23%, wahrscheinlich aufgrund verbesserter Core Web Vitals.
Wie handhaben Sie dynamische Inhalte wie Kommentare auf einer Astro-Website? Wir haben keine Kommentare auf unserem Blog — sie waren auf WordPress ohnehin meist Spam. Wenn Sie Kommentare brauchen, funktionieren Services wie Giscus (GitHub Discussions-basiert) oder Hyvor Talk gut als eingebettete Komponenten. Sie laden als Astro Islands, also beeinflussen sie das anfängliche Seitenladen nicht.
Ist Astro produktionsreif für große Websites? Absolut. Astro 5.x (Ende 2024 veröffentlicht) ist reif und stabil. Unternehmen wie Porsche, Google, Microsoft und Netlify verwenden es in der Produktion. Die Build-Performance skaliert auch gut — Websites mit Tausenden Seiten bauen in unter einer Minute mit der richtigen Konfiguration.
Wie ist die laufende Wartung im Vergleich zu WordPress? Dramatisch weniger. Keine Plugin-Updates, keine Datenbankwartung, keine Sicherheits-Patches für PHP. Wir aktualisieren Astro und seine Abhängigkeiten vielleicht einmal im Monat über Dependabot PRs. Jede Aktualisierung dauert etwa 5 Minuten zum Überprüfen und Mergen. Vergleichen Sie das mit dem WordPress-Update-Laufband.
Können nicht-technische Mitglieder des Teams Inhalte auf einer Astro-Website weiterhin bearbeiten? Mit unserem Setup (MDX-Dateien im Git) müssen Sie sich mit Markdown und grundlegenden Git-Workflows auskennen. Für Teams mit nicht-technischen Redakteuren empfehlen wir, Astro mit einem Headless CMS wie Sanity, Contentful oder Storyblok zu koppeln. Die Redakteure bekommen eine visuelle Schnittstelle, und Sie erhalten immer noch alle Performance-Vorteile der statischen Generierung.