Wir haben unseren eigenen Webauftritt von einer Elementor-basierten WordPress-Installation auf Astro 6 umgezogen. Dieser Beitrag ist die ehrliche Bestandsaufnahme: was die Migration ausgelöst hat, wo es hakte, und welche Kennzahlen am Ende für sich sprechen.
Warum überhaupt migrieren
Die alte WordPress-Site war funktional, aber langsam. Largest Contentful Paint lag im Schnitt bei 4,2s, der gesamte JavaScript-Bundle auf der Startseite bei über 1,8 MB. Elementor lud zur Laufzeit Hunderte von Inline-Styles, das Theme zog drei jQuery-Plugins nach, und jede Content-Änderung im Backend brauchte 8–10 Sekunden zum Speichern.
Was uns wirklich gestört hat:
- Performance als ungelöstes Dauerproblem trotz Cache-Plugins und CDN
- DX war schlecht — kein Git, kein lokales Dev-Setup, Branch-Reviews praktisch unmöglich
- Content-Workflow lief über die WordPress-Oberfläche, Markdown war keine Option
- Sicherheits-Updates für Elementor-Plugins waren ein Vollzeit-Hobby
Die Architekturentscheidung
Wir wollten eine statische Site mit Komponenten-Architektur und Markdown-Authoring. Drei Optionen standen zur Wahl: Next.js, Eleventy, Astro. Astro hat gewonnen — wegen der Islands Architecture, dem 0-by-default-JS-Modell und der nativen MDX-Unterstützung.
// src/content.config.ts — Content Collection definieren
import { defineCollection, z } from 'astro:content';
import { glob } from 'astro/loaders';
const blog = defineCollection({
loader: glob({ pattern: '**/*.mdx', base: './src/content/blog' }),
schema: ({ image }) =>
z.object({
title: z.string().max(80),
description: z.string(),
publishDate: z.coerce.date(),
featureImage: image(),
}),
});
export const collections = { blog };Mit dem Content-Layer in Astro 6 bekommt man typisierte Frontmatter, automatische Bild-Optimierung über astro:assets und ein Loader-API, das später auch externe Quellen anzapfen kann.
Was unerwartet kompliziert war
Wir hatten den Aufwand für drei Bereiche unterschätzt:
- Layout-Treue: Pixelgenau die alte Elementor-Optik nachzubauen kostete deutlich mehr Zeit als das technische Setup. Header, Hero, Carousel, Footer — jede Section musste mit dem DOM der alten Site verglichen werden.
- Carousel-Marquee: Das Slick-Slider-Carousel im Partner-Bereich war auf dem Original ein 1500-Zeilen-jQuery-Plugin. Auf Astro haben wir es in 40 Zeilen reines CSS abgebildet — mit Duplikat-Set und
@keyframes. - Sitemap-Plugin-Logik: Die alte WordPress-Site exportierte über Yoast SEO Sitemaps. Wir mussten Equivalent über
import.meta.glob+ Content-Collections selbst bauen.
“Die Migration war zu 30% ein technisches Projekt und zu 70% ein Design-System-Audit.”
Die Performance-Ergebnisse
Lighthouse Mobile, Median aus 10 Runs:
| Metrik | Vorher (WordPress) | Nachher (Astro) | Delta |
|---|---|---|---|
| LCP | 4,2s | 1,3s | −69% |
| TBT | 380ms | 0ms | −100% |
| CLS | 0,18 | 0,00 | −100% |
| JS-Bundle | 1,8 MB | 32 KB | −98% |
| Build-Time | n/a | 4,1s | — |
Die TBT-Reduktion ist der direkte Effekt von Astros JS-by-default-off-Modell. Wir haben auf der Startseite keine Client-JS-Komponente — alle Interaktionen (Mobile-Menu, Carousel-Hover-Pause, Testimonial-Slider) laufen über Inline-Script-Tags mit ~3 KB Total.
Was wir das nächste Mal anders machen würden
- Content-Schema früh festzurren. Wir haben zweimal das
blog-Schema umgebaut nach dem ersten Authoring-Test. Jeder Schema-Change bedeutet manuelles Frontmatter-Pflegen über alle Files. - Visual Regression Testing einbauen. Wir haben Pixelmatch-Snapshots erst spät hinzugefügt; mit einem CI-Snapshot pro Seitenkomponente von Tag 1 wären viele Layout-Bugs früher aufgefallen.
- Tailwind 4 nicht von Anfang an. Tailwind 4 ist neu genug, dass Plugins (
@tailwindcss/typographyetc.) noch nicht alle kompatibel sind. Für den Blog-Prose-Style haben wir eigene Utilities gerollt.
Fazit
Die Migration hat sich gelohnt — nicht primär wegen der Lighthouse-Scores, sondern wegen des Workflows. Pull Requests, lokales Dev, MDX-Content, typisierte Schemas. Ein Inhalt zu publishen ist jetzt ein git commit statt vier Klicks im Backend.
Was wir nicht neu erfunden haben: SEO, Tracking, Analytics. Diese Schicht ist im Wesentlichen 1:1 von der alten Seite übernommen worden — JSON-LD für Strukturierte Daten, Plausible für Analytics, Yoast-Equivalent für Meta-Tags. Astro macht es einfach, diese Dinge zentral im Base.astro-Layout abzulegen.
Wenn ihr selbst an einer WordPress-Ablöse arbeitet: rechnet mit zwei Monaten konsequenter Arbeit, plant ein Visual-Regression-Setup ein, und friert das Content-Schema früh ein.