Astro-Entwickler

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, Umfangsklärung, Festpreis- oder Time-and-Materials-Engagements. Preisgestaltung individuell.