Deine Agentur predigt Performance, aber deine eigene WordPress-Website ist langsam. Unsere war es auch — 3,2 Sekunden bis zur Interaktivität, Lighthouse steckte bei 58 fest, ein Plugin-Stack, den wir nicht aktualisieren trauten. Jede Client-Demo bedeutete, DevTools auf ihrer blitzschnellen Static Site zu öffnen und zu hoffen, dass sie nicht nach unserer fragen würden. Wir sind socialanimal.dev — wir bauen sub-sekunden-schnelle Next.js- und Astro-Erfahrungen für SaaS-Marken. Also haben wir unsere Site in Astro neu aufgebaut, WordPress vollständig gelöscht und perfekte 100er in jeder Lighthouse-Kategorie erreicht. Time to Interactive fiel auf 0,4 Sekunden. Gesamte Bundle-Größe: 47 KB. Keine Plugins, keine Datenbankabfragen, keine Schande.

Also haben wir alles 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 gekommen sind, was unterwegs kaputt ging und was wir anders machen würden.

Inhaltsverzeichnis

WordPress zu Astro: Wie wir Lighthouse 100 in unserem Rebuild erreicht haben

Warum wir WordPress verlassen haben

Schau, WordPress betreibt etwa 43% des Webs. Es ist keine schlechte Plattform. Wir haben viele WordPress-Sites für Clients gebaut und werden das weiterhin tun, wenn es passt. Aber für unsere eigene Agency-Website — eine meist statische Marketing-Site mit einem Blog — war WordPress Overkill auf die schlimmste Art.

So sah unser WordPress-Setup aus:

  • Theme: Custom Theme gebaut auf Sage (Roots.io)
  • Plugins: 14 aktive Plugins inkl. Yoast SEO, WP Rocket, Advanced Custom Fields Pro, Gravity Forms und 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 aggressiv Cache betrieb, waren unsere Core Web Vitals mittelmäßig. Largest Contentful Paint (LCP) war 2,4 Sekunden auf Mobile. Cumulative Layout Shift (CLS) war 0,12 — nicht schrecklich, aber nicht gut. Und jedes Mal, wenn wir ein Plugin aktualisierten, gab es eine Chance, dass etwas kaputt ging.

Der eigentliche Knackpunkt? Wir zahlten 80 $/Monat für Hosting für eine Site, die vielleicht 3.000 Besuche pro Monat bekam. Das ist nicht viel Traffic, und das ist viel Geld für das, was im Wesentlichen eine Broschüren-Website mit einem Blog war.

Der Wendepunkt

Der letzte Strohhalm kam im Januar 2025. Ein WordPress-Core-Update brach unsere custom Gutenberg-Blöcke. Das Beheben erforderte das Aktualisieren von ACF Pro, was das Aktualisieren unserer Theme-PHP-Versionskompatibilität erforderte, was das Aktualisieren der Hosting-Umgebung erforderte. Was eine Routine-Aktualisierung hätte sein sollen, wurde zu einem ganzen Arbeitstag.

Ich schaute mein Team an und sagte: "Wir erzählen Clients, dass sie headless gehen sollen. Warum essen wir nicht unsere eigenen Hundefutter?"

Warum wir Astro gewählt haben

Wir haben vier Optionen für den Rebuild evaluiert:

Framework Vorteile Nachteile Unser Urteil
Next.js Wir kennen es gut, großes Ökosystem Overkill für eine Content-Site, erfordert Server oder Edge-Runtime Zu schwer
Astro Content-fokussiert, versandt null JS standardmäßig, Island-Architektur Kleineres Ökosystem, neuere Perfekte Passung
Eleventy Einfach, schnelle Builds, reif Limitiertes Component-Modell, weniger modernes DX Zweiter Platz
Hugo Blitzschnelle Builds, einzelne Binary Go-Templating ist schmerzhaft, begrenzte Flexibilität Nicht für uns

Wir bauen viele Next.js-Projekte für Clients, und es ist unsere Go-to für alles mit dynamischer Funktionalität. Aber für eine content-schwere Marketing-Site? Next.js versandt eine JavaScript-Runtime, ob du sie brauchst oder nicht. Selbst mit statischem Export sendest du React zum Browser.

Astros Philosophie hat uns angesprochen: versand HTML, füge JavaScript nur hinzu, wenn du es brauchst. Ihre Island-Architektur bedeutet, dass du eine vollständig interaktive React-Komponente neben völlig statischem HTML haben kannst, und die statischen Teile versenden null JavaScript. Das war genau das, was wir brauchten.

Wir hatten auch in den letzten Jahren mehr Astro-Entwicklungsarbeit für Clients gemacht, also war das Team mit dem Framework vertraut. Es war keine Lernübung — es war ein Tool, dem wir bereits vertrauten.

Die Content-Layer-Frage

Eine Entscheidung, die wir früh trafen: Wir würden kein Headless-CMS für unsere eigene Site verwenden. Für Client-Projekte empfehlen wir oft Headless-CMS-Setups mit Contentful, Sanity oder Storyblok. Aber für unseren Blog, wo jeder Autor ein mit Markdown und Git vertrauter Entwickler ist? Content Collections in Astro mit MDX-Dateien, die ins Repo committed werden, war einfacher und schneller.

Keine API-Aufrufe zur Build-Zeit. Kein Content Delivery Network für Content. Kein zusätzlicher Service zum Verwalten oder Bezahlen. Nur Dateien in einem Ordner.

Die Migrationsstrategie

Wir haben keine Big-Bang-Migration gemacht. Hier ist unser phasierter Ansatz:

Phase 1: Content Audit (1 Woche) Wir haben alle WordPress-Inhalte mit wp-cli exportiert und Posts mit einem custom Script, gebaut mit turndown (HTML-zu-Markdown-Konverter) plus etwas Regex-Aufräumung, zu MDX konvertiert. Wir hatten zu dieser Zeit 47 Blog-Posts. Etwa 12 davon waren veraltet oder hatten schlechte Performance, also haben wir diese zu relevanterem neuerem Content weitergeleitet und haben sie nicht migriert.

Phase 2: Design System in Astro (2 Wochen) Wir haben unsere Komponenten-Bibliothek als Astro-Komponenten neu aufgebaut. Buttons, Cards, Section-Layouts, Navigation — alle als .astro-Dateien. Kein Framework nötig für irgendwelche davon. Reines HTML und CSS mit scoped Styles.

Phase 3: Page Build (2 Wochen) Home-Seite, Capabilities-Seiten, About, Contact, Blog-Listing, einzelne Blog-Posts, 404. Wir haben sie alle als Astro-Seiten mit unserer Komponenten-Bibliothek gebaut.

Phase 4: Performance-Tuning (1 Woche) Hier ist wo die echte Lighthouse 100 Arbeit passierte. Mehr darüber unten.

Phase 5: Launch und Redirect (2 Tage) Wir haben richtige 301-Redirects für jede alte URL eingerichtet, mit Screaming Frog verifiziert, dass nichts kaputt ist, die neue Sitemap zu Google Search Console eingereicht und DNS geflippt.

Gesamte Timeline: etwa 6 Wochen Teilzeitarbeit neben Client-Projekten.

WordPress zu Astro: Wie wir Lighthouse 100 in unserem Rebuild erreicht haben - Architektur

Architekturentscheidungen, die den Unterschied machten

Null JavaScript standardmäßig

Unsere gesamte Site versandt ungefähr 2KB JavaScript insgesamt. Das ist kein Tippfehler. Zwei Kilobyte. Und das meiste davon ist ein kleines Script für Mobile-Navigations-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 Global Layer

Wir verwendeten Astros integriertes Scoped CSS für Component-Level-Styles und ein einzelnes Global-Stylesheet (etwa 8KB minifiziert) für Typografie, Reset, Custom Properties und Utility-Klassen. Kein Tailwind. Kontroverse Ansicht, ich weiß.

Wir lieben Tailwind für größere Anwendungen und Client-Projekte. Aber für eine Site dieser Größe hätte es Build-Komplexität und Dateigröße hinzugefügt, die wir nicht brauchten. Unser handgeschriebenes CSS ist kleiner als Tailwinds Output wäre, selbst mit Purging.

/* Global 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 Generation mit Smart Preloading

Jede Seite wird zur Build-Zeit statisch generiert. Wir verwenden Astros integrierte prefetch-Integration, um Links beim Hover zu preload, was Navigation sofort anfühlen lässt:

// 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

Lighthouse 100 zu erreichen ist nicht nur davon abhängig, das richtige Framework zu wählen. Astro gibt dir einen Vorsprung, aber die letzten 10-15 Punkte erfordern absichtliche Anstrengung. Hier ist, was wir getan haben.

Bild-Optimierung

Astros integrierte <Image />-Komponente handhabt responsive Bilder mit automatischer Format-Konvertierung (WebP/AVIF), Lazy Loading und richtigen 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 arbeitet an Headless-Architektur"
  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 spezifisch verwenden wir loading="eager", da es über dem Fold ist. Alles andere bekommt standardmäßig loading="lazy".

Wir sind auch durch jedes Bild auf der Site gegangen und fragten: "Muss das ein Bild sein?" Mehrere dekorative Elemente wurden stattdessen zu CSS-Gradienten oder SVGs. Unser Hero-Section-Background beispielsweise ist ein CSS-Gradient mit einer subtilen Rausch-Textur, angewendet über eine winzige inline SVG.

Font-Loading-Strategie

Fonts sind ein Lighthouse-Killer. Hier ist unser Ansatz:

  1. Alles selbst hosten. Keine Google Fonts CDN. Wir haben Inter und Cal Sans heruntergeladen und servieren sie von unserer eigenen Domain. Das eliminiert einen DNS-Lookup, TCP-Verbindung und TLS-Handshake zu fonts.googleapis.com.

  2. Aggressiv subsetten. Wir verwendeten glyphhanger, um zu analysieren, welche Zeichen wir tatsächlich verwenden, dann subsetted unsere Fonts mit pyftsubset. Unsere Inter Regular WOFF2 fiel von 96KB auf 18KB.

  3. Verwende font-display: swap mit einem sorgfältig gewählten System-Font-Fallback, das Metriken eng abgleicht, um Layout-Shift während des Swap zu minimieren.

  4. 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 zogen von WP Engine (60 $/Monat) zu Cloudflare Pages (kostenlos). Ja, kostenlos. Unsere Site liegt gut innerhalb der Limits des kostenlosen Plans von Cloudflare — 500 Builds pro Monat, unbegrenzte Bandbreite, unbegrenzte Anfragen.

Cloudflare Pages wird von einem Git-Push deployt, wird von ihrem globalen Edge-Netzwerk serviert und handhabt Cache-Header automatisch. Build-Zeiten durchschnittlich 22 Sekunden für unsere gesamte Site. Vergleiche das mit unserem WordPress-Setup, wo ein Cache-Purge allein länger dauern konnte.

Monatliche Hosting-Kosten fielen von 80 $ auf 0 $.

Critical CSS Inlining

Astro lined automatisch kleine Stylesheets, wenn du build.inlineStylesheets: 'auto' setzt. Für unsere Seiten wird jeder kritische Style im <head> inlined, was bedeutet, dass es null Render-blocking CSS-Anfragen gibt. Der Browser kann sofort anfangen zu zeichnen.

Third-Party Script Discipline

Hier verlieren die meisten Sites ihre perfekten Scores. Jedes Third-Party-Script ist eine potenzielle Performance-Katastrophe. Wir limitierten unsere erbarmungslos:

  • Analytics: Gewechselt von Google Analytics (70KB+ JavaScript) zu Plausible Analytics (< 1KB Script, async geladen). Wir zahlen 9 $/Monat für Plausible, und die Datenqualität ist ehrlich besser für unsere Anforderungen.
  • Forms: Unser Contact-Formular auf /contact verwendet ein einfaches HTML-Formular mit serverseiter Handhabung über Cloudflare Pages Functions. Keine JavaScript-Form-Bibliothek.
  • Keine Chat-Widgets. Keine Social-Media-Embeds. Keine Cookie-Consent-Banner (wir verwenden keine Cookies, die Zustimmung erfordern).

Die Lighthouse 100 Scorecard

Hier sind unsere aktuellen Lighthouse-Scores Mai 2025, gemessen mit Chrome DevTools bei einer drosselierten Verbindung (Lighthouse Standard-Mobile-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 Wesentlichen kein JavaScript, das jemals den Main Thread blockiert.

Vorher und Nachher: Die Zahlen

Metrik WordPress (Vorher) Astro (Nachher) Verbesserung
Lighthouse Performance 58 100 +72%
LCP (Mobile) 2,4s 0,8s 3x schneller
CLS 0,12 0 Eliminiert
TBT 380ms 0ms Eliminiert
Seite Gewicht (Home) 1,8MB 142KB 92% kleiner
HTTP-Anfragen 47 6 87% weniger
Versandtes JavaScript 340KB 2KB 99,4% weniger
Monatliche Hosting-Kosten 80 $ 9 $ (nur Plausible) 89% billiger
Build/Deploy-Zeit 3-5 min 22 sec ~10x schneller
Time to First Byte 420ms 18ms 23x schneller

Die Seitengröße-Reduktion ist sogar für uns atemberaubend. 1,8MB auf 142KB. Das ist das, was passiert, wenn du aufhörst, jQuery, React, WP Rockets Script-Loader, Yoasts Schema-Markup-Injektor und vierzehn Plugin-Stylesheets zu versenden.

Was wir unterwegs falsch gemacht haben

Es war nicht alles reibungslos. Ehrlichkeits-Zeit.

Fehler 1: Wir hätten Content Management fast überengineert

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 einen Schritt zurücktraten und fragten: "Wer wird das tatsächlich verwenden?" Die Antwort war... wir. Entwickler. Die vollkommen glücklich sind, MDX in VS Code zu schreiben. Wir rissen Sanity heraus und gingen mit Astro Content Collections. Sparte laufende Kosten und Komplexität.

Fehler 2: Font-Subsetting brach Spezial-Zeichen

Unser initiales Font-Subset war zu aggressiv. Wir streiften Zeichen, von denen wir dachten, wir würden sie nie verwenden, dann veröffentlichten wir einen Blog-Post mit einem Em-Dash und ein paar curly Quotes, die als Boxen dargestellt wurden. Lektion: Teste deine Subsets mit echtem Content, nicht nur "ABCDEFG."

Fehler 3: Wir vergaßen 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ück gehen und eine OG-Bild-Generierungs-Pipeline mit @astrojs/og bauen (die Satori unter der Haube verwendet). Hätte im ursprünglichen Scope sein sollen.

Fehler 4: Die 301-Redirect-Karte hatte Lücken

Trotz der Verwendung von Screaming Frog, um alte URLs zu mappen, verpassten wir eine Handvoll Bild-URLs, auf die externe Sites hotlinkten. Wir fingen diese in Cloudflares Analytics etwa eine Woche nach dem Launch und fügte die fehlenden Redirects hinzu. Überprüfe immer deine Server-Logs nach einer Migration — Google Search Console wird nicht alles fangen.

Lektionen für deine eigene Migration

Wenn du in Betracht ziehst, WordPress zu einem Static-First-Framework zu verschieben, hier ist das, was ich dir sagen würde:

  1. Audit vor der Migration. Lösche Content, der nicht performat. Eine Migration ist eine großartige Gelegenheit zu prunen.

  2. Passe das Tool zum Job. Astro war perfekt für uns, weil wir größtenteils Content sind. Wenn du starke Interaktivität brauchst, ist Next.js oder ein ähnliches Framework möglicherweise der bessere Aufruf.

  3. Cargo-Kult nicht deine alte Architektur. Wir versuchten nicht, unsern WordPress-Setup in Astro zu replizieren. Wir haben alles von Grund auf neu durchdacht. Brauchen wir wirklich ein Form-Plugin? Nein, ein <form>-Element mit einer Serverless Function funktioniert prima.

  4. Messe vorher, messe nachher, messe kontinuierlich. Wir haben einen Lighthouse CI Job in GitHub Actions eingerichtet, der bei jedem Pull Request läuft. Wenn ein PR einen Score unter 95 fällt, fehlgeschlagen der Check.

  5. Budget für die "letzten 5%". Von Lighthouse 85 zu 95 zu kommen ist einfach. Von 95 zu 100 zu kommen erfordert Font-Subsetting, Critical-CSS-Analyse, Bild-Format-Optimierung und Third-Party-Script-Auditing. Plane Zeit dafür ein.

  6. Deine Hosting-Kosten sollten dein altes Setup beschämen. Wenn du statische Dateien servierst und zahlst immer noch bedeutende Hosting-Gebühren, etwas ist falsch. Statisches Hosting ist eine Commodity jetzt.

Wenn du daran interessiert bist, wie eine solche Migration für dein Projekt aussehen würde, schau dir unsere Pricing-Seite an oder kontaktiere uns. Wir haben diesen Migrationspfad für mehrere Clients jetzt gemacht, und die Performance-Gewinne sind konsistent dramatisch.

FAQ

Wie lange dauert es, eine WordPress-Site zu Astro zu migrieren?

Für unsere Site (etwa 50 Seiten inklusive Blog-Posts) dauerte es ungefähr 6 Wochen Teilzeitarbeit. Eine größere Site mit hunderten Posts und komplexen Custom Post Types könnte 8-12 Wochen dauern. Die eigentliche Entwicklung ist üblicherweise schneller als das Content-Audit und die Redirect-Kartierung.

Kannst du Lighthouse 100 statt Astro mit Next.js erreichen?

Es ist möglich, aber signifikant schwerer. Next.js versandt eine JavaScript-Runtime zum Browser selbst für statische Seiten (die React-Hydrations-Schicht). Du kannst nah kommen — Scores von 95-99 sind mit sorgfältiger Optimierung erreichbar. Aber Astros Zero-JS-by-Default-Ansatz macht perfekte Scores für Content-Sites viel erreichbarer.

Was ist mit WordPress-Features wie Contact Forms und Suche?

Contact Forms funktionieren prima mit einfachen HTML-Formularen und einem Serverless-Function-Backend (Cloudflare Pages Functions, Netlify Functions, etc.). Für Suche verwenden wir eine Client-seitige Suche mit Pagefind, die einen Such-Index zur Build-Zeit baut und nur 5KB JavaScript versandt. Es ist schnell und funktioniert offline.

Schadet die Migration von WordPress zu Astro der SEO?

Nicht, wenn du es richtig machst. Wir richteten 301-Redirects für jede URL ein, behielten unsere URL-Struktur wo möglich, reichten eine neue Sitemap ein und behielten all unsere strukturierten Daten. Unser organischer Traffic stieg sogar 23% in den drei Monaten nach der Migration, wahrscheinlich aufgrund verbesserter Core Web Vitals.

Wie hältst du dynamische Inhalte wie Kommentare auf einer Astro-Site?

Wir haben keine Kommentare auf unserem Blog — sie waren größtenteils Spam auf WordPress. Wenn du Kommentare brauchst, funktionieren Services wie Giscus (GitHub Discussions-basiert) oder Hyvor Talk gut als eingebettete Komponenten. Sie laden als Astro Islands, also beeinflussen sie nicht das initiale Seite-Laden.

Ist Astro produktionsreif für große Sites?

Absolut. Astro 5.x (Release Ende 2024) ist reif und stabil. Unternehmen wie Porsche, Google, Microsoft und Netlify verwenden es in Produktion. Die Build-Performance skaliert auch gut — Sites mit tausenden Seiten bauen in unter einer Minute mit der richtigen Konfiguration.

Wie sieht die laufende Wartung im Vergleich zu WordPress aus?

Dramatisch weniger. Keine Plugin-Updates, keine Datenbank-Wartung, keine Sicherheits-Patches für PHP. Wir updaten Astro und seine Abhängigkeiten vielleicht einmal im Monat über Dependabot PRs. Jedes Update dauert etwa 5 Minuten zu überprüfen und zu mergen. Vergleiche das mit dem WordPress-Update-Laufband.

Können nicht-technische Team-Mitglieder Content in einer Astro-Site immer noch bearbeiten?

Mit unserem Setup (MDX-Dateien in Git) musst du mit Markdown und grundlegenden Git-Workflows vertraut sein. Für Teams mit nicht-technischen Editoren empfehlen wir, Astro mit einem Headless-CMS wie Sanity, Contentful oder Storyblok zu paaren. Die Editoren bekommen eine visuelle Schnittstelle, und du behältst immer noch alle Performance-Vorteile der statischen Generierung.