Service-Säule

Astro-Entwickler

Senior B2B, EU-Jurisdiktion, Scope pro Projekt.

Preisgestaltung individuell. Ich antworte innerhalb eines Werktags.

Projekt starten Ausführliche Astro-Landingpage →

Was ich liefere

Astro 5+ im Frontend. WordPress 6.7+ als redaktionelles Back-End, das über REST oder GraphQL kommuniziert. Cloudflare Pages für Statik und SSR. TypeScript über den ganzen Stack. Tailwind CSS als Design-System. MDX für redaktionelle Flexibilität, wo Autoren sie brauchen. Anthropic Claude und Model Context Protocol, sobald sich KI-Funktionen tatsächlich rechnen.

Warum Astro für Headless-WordPress

Astros Grundsatz „standardmäßig kein JS" ist die richtige Ausgangsbasis für Inhaltsseiten. Die meisten Seiten einer inhaltsgeführten WordPress-Site haben ein oder zwei interaktive Elemente (eine Suchbox, eine Navigation, ein Kontaktformular) und sind ansonsten reines HTML. Astro liefert nur das JavaScript aus, das diese Interaktionen brauchen; alles andere ist statisches HTML, das zur Buildzeit oder pro Route per SSR gerendert wird.

Bei traffic-starken Inhaltsseiten zählt die Kostenform. Statische Astro-Seiten werden vom Edge-Cache mit nahezu null CPU-Kosten pro Anfrage ausgeliefert. Der CO₂- und Bandbreiten-Footprint ist deutlich niedriger als bei einer vergleichbaren Next.js-SSR-Lösung. Für Seiten, bei denen Interaktivität das Produkt ist (Dashboards, transaktionaler Commerce, Echtzeit-Feeds), empfehle ich stattdessen die Next.js-Säule.

Für wen das gedacht ist

  • Verlage und Inhaltsseiten mit redaktionellem Workflow auf WordPress
  • Inhaltsgeführte WooCommerce-Kataloge, in denen Commerce nur eine kleine Fläche innerhalb einer größeren Inhaltsseite ist
  • Dokumentationsportale und entwicklerorientierte technische Sites
  • Marketing-Sites, die schnelles LCP und minimales JavaScript auf Mobilgeräten brauchen

Zusammenarbeitsmodell

Senior-B2B-Verträge in EU-Jurisdiktion. Discovery, Scoping, Festpreis- oder Time-and-Materials-Engagements. Preisgestaltung individuell.

Read-Path am Edge, Write-Path am Origin. Cache wird per Webhook nach Tags invalidiert. Leser / Agent sends a request to Cloudflare Workers (Edge). On cache hit the Edge-Cache (pro Tag) returns HTML with almost no CPU. On cache miss Workers calls REST API /wp-json/ on the WordPress-Origin and renders. Editorial work happens in Block Editor + WP Admin on the origin and triggers a Webhook bei Veröffentlichung that invalidates relevant cache tags. Leser / Agent Cloudflare Workers (Edge) Edge-Cache (pro Tag) Cache-Treffer (fast keine CPU) Cache-Miss → Render am Edge WordPress-Origin Block Editor + WP Admin REST API /wp-json/ Veröffentlichung / Slug-Änderung / Bestand Read Read Webhook bei Veröffentlichung Write
Read-Path am Edge, Write-Path am Origin. Cache wird per Webhook nach Tags invalidiert.
Standardmäßig kein JavaScript pro Seite ist kein Feature; es ist die architektonische Festlegung, die alles andere günstiger macht.
Fred K. Schott , Astro-Schöpfer , Astro Together 2025 , 2025-09-22 , source

Häufig gestellte Fragen

Wann gewinnt Astro gegen Next.js für Headless-WordPress?

Bei inhaltsschweren Seiten mit vorhersehbarer Aktualisierungskadenz und minimaler Interaktivität pro Seite. Marketing-Sites, Blogs, Dokumentationsportale, inhaltsgeführte WooCommerce-Kataloge. Astro liefert standardmäßig kein JavaScript aus; interaktive Teile sind opt-in Inseln. Next.js gewinnt bei personalisierten, sitzungsgetriebenen oder transaktionalen Flows.

Was bedeutet die Inseln-Architektur in der Praxis?

Jede interaktive Komponente ist eine separate Insel, die unabhängig hydriert wird, mit eigenem JavaScript-Bundle. Der Rest der Seite ist statisches HTML. Das Ergebnis ist schnellere TTI in langsamen Netzen, weil der Browser nur den JS-Code für die Inseln parst, die der Nutzer tatsächlich sieht, und nicht für die ganze Seite.

Unterstützt Astro React-, Vue- und Svelte-Komponenten im selben Projekt?

Ja. Astro ist framework-agnostisch. In der Regel verwende ich Astro-Komponenten für die HTML-Struktur und React für interaktive Inseln; die Wahl ist pro Komponente. Mischen wird unterstützt, ist in Produktionsprojekten aber selten nötig.

Wie performt Astro auf Cloudflare Pages?

Hervorragend für statische und ISR-artige Inhalte. Astros vorgebautes HTML wird vom Edge-Cache nahezu ohne CPU-Last ausgeliefert. SSR-Routen nutzen den Cloudflare-Adapter und laufen als Worker-Funktionen. Ich benchmarke pro Projekt; statisch ist der günstigste Modus.

Können Sie einen WordPress-Monolithen nach Astro migrieren?

Ja. WordPress bleibt als redaktioneller Back-End, Astro wird zum Frontend über REST oder GraphQL. Inhaltserhalt, URL-Mapping, hreflang, Sitemaps und strukturierte Daten werden alle übernommen. Die Migrationsdauer liegt typischerweise zwischen 6 und 16 Wochen, abhängig von Katalogumfang und Anzahl der Integrationen.

Proof durch Content-Migration

Astro ist am stärksten, wenn Content, URL-Stabilität und Publishing- Workflow wichtiger sind als Client-State. Die anonymisierte Proof- Schicht zeigt die Migrationsmechanik ohne Kundennamen offenzulegen.

Weiterführende Artikel

Architektur und Entscheidung

Migration und Zeitpläne

Ausführliche Landingpage

Referenz

Astro-Projekt starten

Schildern Sie Scope und Zeitplan. Ich antworte innerhalb eines Werktags.

Kontakt aufnehmen