Wir haben die Website eines Kunden von einem dedizierten WordPress-Server mit vorgeschaltetem CDN auf eine Astro-gebundene Site auf einem europäischen VPS migriert. Die Ladezeiten sanken von 1,2 Sekunden auf 400–800 Millisekunden. Die monatlichen Hosting-Kosten reduzierten sich um 75 Prozent. Das CDN ist weg. WordPress läuft unverändert. Hier ist, was wir getan haben, warum das Entfernen des CDN die Performance verbessert hat und was die Migration konkret bedeutete.

Was wir vorgefunden haben

Der Kunde betreibt eine inhaltsreiche WordPress-Website, die über Jahre gewachsen ist: ein umfangreicher Blog mit benutzerdefinierten Layout-Blöcken, ACF-Beziehungsfeldern, die Beiträge mit anderen Inhaltstypen verknüpfen, verschachtelten Repeater-Feldern, flexiblen Inhaltsbausteinen für unterschiedliche Layouts und globalen Options-Pages, die siteweite Einstellungen verwalten. Komplex, gut strukturiert, und jeden Cent wert. Die Art von WordPress-Setup, die man nicht einfach abreißt.

Die dahinterliegende Infrastruktur war auf WordPress ausgelegt: ein dedizierter Server, ergänzt durch ein CDN, um die Last zu verteilen und die Auslieferungszeiten zu verbessern. Auf dem Papier solide. In der Praxis: 1,2 Sekunden Time-to-First-Byte an einem guten Tag und eine Hosting-Rechnung, die einen nennenswerten Teil des Jahresbudgets ausmachte.

Die Aufgabe lautete nicht „Website neu bauen". Sie lautete: schneller machen, Kosten senken, Redaktionsprozess nicht anfassen.

WordPress behalten. Vom Frontend entkoppeln.

Keine Neuentwicklung. Eine Entkopplung.

Astro lädt beim Build-Vorgang alle Inhalte aus WordPress: Beiträge, ACF-Felddaten, Beziehungsreferenzen, Repeater-Inhalte, Layout-Block-Konfigurationen, Options-Page-Werte. Diese werden in statisches HTML gerendert und auf dem VPS deployed. Wenn ein Besucher eine Seite aufruft, erhält er vorgerendertes HTML – ohne PHP-Ausführung, ohne Datenbankabfragen, ohne WordPress-Prozess, der den Request verarbeitet.

WordPress läuft exakt wie bisher. Der Kunde meldet sich an, schreibt Beiträge, bearbeitet Felder, verwaltet Inhaltsbeziehungen – der Workflow, den das Team über Jahre aufgebaut hat, ist vollständig erhalten. Kein Umschulen. Keine neue Redaktionsoberfläche. Die Investition in die Inhaltsstruktur bleibt bestehen.

Das überrascht viele, die das Wort „Headless" hören: Man muss nicht zwischen moderner Frontend-Performance und WordPress als CMS wählen. Die Migration führt nicht weg von WordPress. Sie verändert die Rendering-Schicht – und nur die.

Was die ACF-Migration konkret bedeutete

„Komplexes ACF-Setup" ist schnell gesagt. Was es in der Praxis hieß:

Die Website nutzte den vollen Funktionsumfang von ACF. Beziehungsfelder verknüpften Beiträge mit Produkten, Fallstudien und Teammitgliedern – die WordPress REST API liefert diese als IDs, die auf Astro-Seite in vollständige Objekte aufgelöst werden müssen. Verschachtelte Repeater (Repeater-Felder, die weitere Repeater enthalten) kommen als Arrays von Arrays zurück, was sorgfältige Typenbehandlung erfordert, um Build-Fehler zu vermeiden. Options-Page-Daten – globale Einstellungen für die gesamte Site – liegen an einem separaten REST-Endpunkt und benötigen einen eigenen Fetch-Aufruf außerhalb der Standard-Posts-Abfrage.

Die Blog-Layout-Blöcke waren der aufwendigste Teil. Der Blog nutzte flexible Content-Blöcke in WordPress: unterschiedliche Spaltenanordnungen, Bild-Text-Kombinationen, Zitate, Call-out-Blöcke – jeder mit eigenem Template im WordPress-Theme. Jeder dieser Blocktypen wurde zu einer Astro-Komponente. Da Astro kein clientseitiges Rendering kennt, läuft die Block-Typ-Unterscheidung vollständig beim Build, nicht zur Laufzeit.

Das Ergebnis: Jeder Layout-Block, den der Kunde in WordPress aufgebaut hat, wird nun in Astro gerendert, vollständig gestylt, pixelgenau. Die redaktionelle Arbeit in WordPress hat sich nicht verändert. Die Auslieferung ist eine andere.

Warum das Entfernen des CDN die Performance verbessert hat

Dieser Punkt widerspricht den meisten Infrastruktur-Instinkten.

CDNs verbessern die Performance, indem sie Inhalte näher an den Nutzer bringen. Das funktioniert, wenn der Origin-Server weit vom Publikum entfernt ist – zum Beispiel ein US-gehosteter Server für europäische Besucher. Das CDN cached die Inhalte an PoPs in Frankfurt, Amsterdam oder Paris und reduziert den Round-Trip.

Aber wenn der Origin-Server bereits in Europa steht und das Publikum europäisch ist, fügt das CDN einen Hop hinzu, anstatt einen zu entfernen. Die Anfrage trifft den CDN-Edge-Node. Ist die Antwort dort nicht gecacht – was häufiger vorkommt, als CDN-Anbieter zugeben – fällt sie zum Origin durch. Bei einer weitgehend statischen Website ohne Personalisierung zur Laufzeit rechtfertigt die Cache-Hit-Rate des CDN selten den Architekturaufwand.

Auf dem neuen Setup: europäischer VPS, europäisches Publikum, kein Intermediär. Die Anfrage geht direkt an den Server und erhält vorgerendertes statisches HTML zurück. 400–800 ms.

Für europäische Kunden kommt ein zweiter Aspekt hinzu. Kein CDN bedeutet keine Drittanbieter-Infrastruktur, die Besucher-Requests verarbeitet. Cloudflare und Fastly betreiben Rechenzentren in Europa – sind aber US-amerikanische Unternehmen unter US-amerikanischer Rechtsprechung. CLOUD Act, FISA und verwandte Regelungen gelten unabhängig davon, wo der PoP sich befindet. Für Kunden, bei denen DSGVO-Konformität eine echte Anforderung ist, ist das Entfernen dieses Intermediärs eine substanzielle architektonische Entscheidung.

Die Zahlen

Vorher:

  • Time to Interactive: ~1,2 s
  • Hosting: dedizierter WordPress-Server + CDN-Subscription
  • Serverressourcen: ausgelegt auf PHP- und MySQL-Betrieb unter Last

Nachher:

  • Time to Interactive: 400–800 ms
  • Hosting-Kosten: 75 % niedriger (viermal günstiger)
  • Serverressourcen: 150 % mehr CPU und RAM als beim Vorgänger – zum Viertel des Preises
  • CDN: keines

Der Ressourcenzuwachs erklärt die Geschwindigkeit besser als jede Optimierungsmaßnahme. Der alte Server war darauf ausgelegt, WordPress-PHP-Prozesse unter gleichzeitigen Anfragen zu bewältigen. Der neue VPS liefert vorgerenderte statische Dateien aus. Der Rechenaufwand sank auf nahezu null.

400 Prozent Kosteneinsparung. 150 Prozent mehr Ressourcen. Ladezeiten um zwei Drittel reduziert. Kein CDN.

Was die Migration wirklich freigesetzt hat

Die Performance-Zahlen waren der Auftrag. Was danach kam, war bedeutender.

Mit Astro als Rendering-Schicht hörte das Entwickeln neuer Funktionen auf, eine Verhandlung mit WordPress' Template-System zu sein. Keine Builder-Einschränkungen mehr. Kein mühsames Durchleiten von ACF-Feldern durch PHP-Template-Logik. Keine Blöcke, die im Editor korrekt aussehen und im Browser falsch.

Die WordPress-Inhaltsarchitektur wurde zu einer sauberen Daten-API. Astro bezieht sie und rendert sie ohne Einschränkung. Zum ersten Mal schloss sich die Lücke zwischen dem, was gebaut werden sollte, und dem, was das System erlaubte.

Neue Sektionen, Landing Pages, interaktive Komponenten, Performance-kritische Features – Dinge, die bisher benutzerdefinierte Plugins, Builder-Umgehungen oder aufwendige PHP-Anpassungen erfordert hätten – entstehen jetzt direkt in Astro. Sauber. So wie es sein sollte.

WordPress macht, was es wirklich kann: strukturiertes Content-Management mit einer ausgereiften, stabilen Redaktionsoberfläche, die das Team des Kunden bereits kennt. Astro macht, wofür WordPress' Template-System nie ausgelegt war: wartbaren, performanten Frontend-Output ohne Laufzeit-Overhead.

Die Builder-Frustration ist weg. Der ACF-Verkabelungsaufwand ist weg. Der Abstand zwischen Vorhaben und Ergebnis ist verschwunden.

Wann dieser Ansatz passt

Er funktioniert gut, wenn:

  • Die WordPress-Inhaltsstruktur erhaltenswert ist. Ein gewachsenes ACF-Setup mit etablierten Workflows ist ein Wert, kein Problem.
  • Das Publikum geografisch konzentriert ist und in der Nähe des Hostings. Der EU-Hosting-Vorteil funktioniert nicht bei global verteilten Nutzern.
  • Die Website inhaltsorientiert ist, ohne Laufzeit-Personalisierung. Statisches Rendering ist die passendere Wahl, wenn sich Seiten nicht abhängig vom Nutzerstatus ändern.
  • Das Team des Kunden WordPress kennt und kein neues CMS lernen soll. Redaktionelle Kontinuität hat realen Wert.

Er passt schlecht, wenn:

  • E-Commerce mit Echtzeitlagerbestand oder Warenkorb-Logik. Statisches Rendering kann keine benutzerspezifischen Laufzeitdaten ohne zusätzliche Architektur verarbeiten.
  • Inhalte müssen binnen Sekunden live sein. Astro erfordert einen Rebuild nach Veröffentlichung – typischerweise zwei bis fünf Minuten.
  • Das WordPress-Setup selbst ist das Problem. Die Rendering-Schicht zu migrieren löst keine kaputte Inhaltsarchitektur.

Der Rebuild-Trigger ist die eine echte Einschränkung dieser Architektur. Für den Veröffentlichungsrhythmus des Kunden ist die Verzögerung nicht spürbar.

Fazit

Dieses Projekt begann als Performance- und Kostenauftrag. Es endete als Architekturupgrade, das veränderte, was das Team bauen kann.

Viermal günstiger. 150 Prozent mehr Ressourcen. Ladezeiten von 1,2 Sekunden auf unter eine halbe Sekunde. Kein CDN. Keine datenschutzrechtlich problematischen Intermediäre. WordPress läuft exakt so, wie der Kunde es erwartet.

Und die eigentliche Arbeit – das Entwickeln und Ausliefern von Features – wurde zu dem, was sie schon immer hätte sein sollen.