Astro-Entwickler in Wiesbaden

#Astro für Unternehmen in Wiesbaden

Ich bin Mariusz Szatkowski, arbeite seit 2006 mit WordPress und baue heute Websites mit Astro. Mein Arbeitsplatz ist Gdynia in Polen, ich arbeite vollständig remote und schriftlich. Diese Seite richtet sich an Unternehmen in Wiesbaden und Hessen, die eine Website haben oder planen, auf der einzelne Teile interaktiv sein müssen, der Rest aber vor allem schnell laden soll.

Mein Thema hier ist eine einzige Frage: Wie viel JavaScript braucht Ihre Seite wirklich, und wo? Astro baut diese Frage in die Architektur ein. Ich zeige, wie das funktioniert, wo die Grenzen liegen und wie ich das Ergebnis messe.

Foto: Matti Blume, CC BY-SA 4.0, Wikimedia Commons.

Wiesbaden hatte nach dem Hessischen Statistischen Landesamt 288.584 Einwohner (Stand 31. Dezember 2025) und ist Landeshauptstadt von Hessen. Laut Wikipedia sind dort traditionell Finanzdienstleister und Versicherer ansässig, darunter die Nassauische Sparkasse, die WIBank und die DBV Deutsche Beamtenversicherung. Das Statistische Bundesamt hat seine Anschrift im Gustav-Stresemann-Ring 11 in Wiesbaden (Destatis). Dazu kommen Kurbetrieb, Kongresse und Tourismus.

Was das für Websites bedeutet, leite ich ab, ich behaupte es nicht von einzelnen Firmen. In solchen Branchen stehen auf der Website typischerweise wenige interaktive Bausteine: ein Rechner, eine Terminanfrage, eine Veranstaltungsübersicht mit Filter, ein Kontaktformular. Der große Rest ist Text, Tabelle und Bild. Genau dieses Verhältnis spricht für ein Framework, das Interaktivität einzeln zuschaltet.

#Was Astro mit JavaScript macht

Ich stütze mich auf die Astro-Dokumentation zu Islands.

• Standard ist HTML. Astro rendert jede UI-Komponente zu HTML und CSS und entfernt das Client-JavaScript automatisch. Das schützt laut Dokumentation davor, versehentlich unnötiges JavaScript auszuliefern.
• Client Islands. Eine Komponente wird erst durch eine client:*-Direktive zur interaktiven Insel. Astro bündelt dann das JavaScript nur für sie.
• Parallel und getrennt. Inseln laden parallel und werden unabhängig voneinander aktiviert. Eine schwere Komponente weiter unten blockiert die Kopfzeile nicht.
• Server Islands. Mit server:defer rendert eine Komponente ihren dynamischen Inhalt getrennt vom Rest der Seite auf dem Server.

Die Dokumentation ordnet das Muster ein: Der Begriff der Komponenten-Insel stammt von Katie Sylor-Miller (2019), Jason Miller beschrieb die Idee am 11. August 2020. Einzelseiten-Anwendungen, die die ganze Seite als ein JavaScript-Programm laden, haben demnach ihren Platz, sogar eingebettet in eine Astro-Seite. Für eine Firmenwebsite mit vielen Textseiten sind sie selten die erste Wahl.

Stand 11. November 2026 ist laut npm-Registry Astro 7.4.11 die aktuelle Version. Ich nenne die Version, weil sich Direktiven und Optionen über Hauptversionen ändern. Ihr Projekt bekommt eine feste Version, die ich im Umfang festhalte.

#Welche Direktive für welchen Baustein

Die Direktiven-Referenz nennt zu jeder Direktive eine Priorität und einen typischen Einsatz. Meine Zuordnung für Unternehmenswebsites:

Drei Details aus der Dokumentation, die in der Praxis zählen:

• client:idle wartet auf requestIdleCallback. Mit der Option timeout legen Sie fest, wann spätestens hydriert wird, auch wenn die Seite noch lädt.
• client:visible nutzt einen IntersectionObserver. Mit rootMargin (etwa 200 Pixel) startet das Laden schon kurz vor dem Sichtbarwerden. Laut Dokumentation kann das Layout-Verschiebungen (CLS) verringern und Komponenten früher bedienbar machen.
• Eine Direktive funktioniert nur an einer Komponente, die direkt in eine .astro-Datei importiert wird. Dynamische Tags und über die components-Eigenschaft an MDX übergebene Komponenten unterstützen sie nicht.

#React, Vue oder Svelte nur dort, wo sie gebraucht werden

Nach der Dokumentation zu Framework-Komponenten bindet Astro React, Preact, Svelte, Vue, SolidJS und AlpineJS über offizielle Integrationen ein. Eine Komponente ohne client:*-Direktive wird nur auf dem Server zu statischem HTML gerendert. Das ist der Hebel für bestehende Projekte: Ihr Team kann Komponenten behalten, und nur die wirklich interaktiven bekommen JavaScript.

Was daraus folgt, wenn Sie schon Komponenten haben:

• Framework nur einmal. Nutzen zwei oder mehr Komponenten einer Seite dasselbe Framework, wird es laut Dokumentation nur einmal ausgeliefert. Wer React und Vue mischt, zahlt beide Laufzeiten. Ich rate deshalb zu einem Framework pro Seite.
• Props müssen serialisierbar sein. An hydrierte Komponenten gehen laut Dokumentation Objekte, Zahlen, Strings, Arrays, Maps, Sets, RegExp, Date, BigInt, URL und typisierte Arrays. Funktionen nicht. Das prüfe ich bei jeder übernommenen Komponente.
• Kein gemeinsamer Context. React-Provider reichen nicht über Inselgrenzen. Astro empfiehlt laut Rezept zum Teilen von Zustand zwischen Inseln Nano Stores, die nach Angabe der Dokumentation weniger als 1 KB groß sind und ohne Abhängigkeiten auskommen.
• Mischen nur in .astro-Dateien. Nur dort dürfen Komponenten mehrerer Frameworks nebeneinander stehen.

Nicht jede Komponente gehört auf die Insel. Ein Akkordeon für Fragen lässt sich oft mit HTML und CSS lösen. Dann braucht es kein Framework und keine Direktive. Ich entscheide das pro Baustein und halte es in einer Tabelle fest, die Sie vor dem Start lesen können.

#Server Islands: dynamisch, ohne die Seite zu bremsen

Eine Server Island ist laut Dokumentation eine normale, auf Anfrage gerenderte Astro-Komponente, deren Rendering verzögert wird. Die Seite erscheint sofort mit Platzhalterinhalt, den Sie über den benannten Slot fallback festlegen. Der eigentliche Inhalt wird danach vom Browser nachgeladen. Voraussetzung ist ein installierter Adapter.

Das passt zu Seiten, die überwiegend statisch sind und einen dynamischen Teil haben, zum Beispiel einen Bereich mit aktuellen Verfügbarkeiten oder Anmeldestatus. Vier Punkte aus der Dokumentation, die ich vor dem Einsatz klären würde:

1. Caching. Die Daten kommen per GET-Anfrage, die Props stehen verschlüsselt in der URL. Dann greift normales Cache-Control. Wird die URL länger als 2048 Bytes, sendet Astro per POST, und das Caching entfällt. Ich übergebe deshalb nur das Nötige.
2. Eigene Anfrage. In einer Server Island liefert Astro.url eine Adresse wie /_server-islands/Avatar, nicht die der Seite. Brauchen Sie die Seiten-URL, liest die Komponente den Referer-Header oder bekommt sie als Prop.
3. Fallback gegen Layout-Verschiebung. Der Platzhalter sollte so groß sein wie der spätere Inhalt, sonst springt die Seite. Die Dokumentation nennt diesen Zweck ausdrücklich.
4. Schlüssel bei Rolling Deployments. Astro verschlüsselt die Props mit einem Schlüssel, der bei jedem Build neu entsteht. Bei Rolling Deployments, Multi-Region-Hosting oder einem CDN, das ältere Seiten ausliefert, setzen Sie mit astro create-key einen festen Schlüssel in der Umgebungsvariable ASTRO_KEY.

Ob ein Adapter für Ihr Projekt nötig ist, entscheide ich nicht vorab. Eine rein statische Seite mit client:*-Inseln kommt ohne ihn aus. Erst wenn ein Teil wirklich bei Anfrage entstehen muss, kommt server:defer ins Spiel, und der Hosting-Weg wird Teil des schriftlichen Umfangs.

#Wirkung messen: die offiziellen Schwellen

Ich nenne keine Wunschwerte. Maßstab sind die Core Web Vitals: Der Largest Contentful Paint (LCP) bis 2,5 Sekunden, die Interaction to Next Paint (INP) bis 200 Millisekunden, der Cumulative Layout Shift (CLS) bis 0,1, jeweils im 75. Perzentil aller Seitenaufrufe und getrennt für Mobilgeräte und Desktop.

So messe ich, in dieser Reihenfolge:

1. Ausgangswert vor dem Umbau. Ich messe die bestehende Seite, damit der Vergleich nicht auf einer Erinnerung beruht.
2. Feld- und Laborwerte trennen. web.dev beschreibt, dass Core Web Vitals am besten im Feld gemessen werden, also bei echten Besuchern. Laborwerkzeuge wie Lighthouse dienen laut demselben Artikel der Diagnose, weil sie unter vorgegebenen Bedingungen laufen und oft einen Kaltstart simulieren. Öffentliche Felddaten liefert der Chrome User Experience Report (CrUX), eigene Felddaten lassen sich mit Googles web-vitals-Bibliothek erheben.
3. Bundle prüfen. Die Astro-Dokumentation beschreibt ein Rezept zur Bundle-Analyse mit rollup-plugin-visualizer. Dazu der Hinweis der Dokumentation: Der Build bildet wegen Astros Hydrierung nicht unbedingt ab, was der Client erhält, und zeigt keine Größen pro Seite. Ich sehe deshalb zusätzlich im Browser nach, welche Skripte eine Seite wirklich lädt.
4. Nach dem Start erneut messen. Felddaten brauchen Besucher. Ich nenne Ihnen schriftlich, wann die ersten belastbaren Werte zu erwarten sind, und zeige, was sich verändert hat.

Eine Seite besteht, wenn alle drei Werte im 75. Perzentil erreicht sind. Ob Ihre das schafft, hängt auch an Bildern, Schriften und eingebetteten Fremdinhalten, nicht allein am JavaScript. Das Messprotokoll zeigt, welche Ursache bei Ihnen überwiegt.

#Datenschutz in Hessen: was die Inselliste klärt

Zuständig für den Datenschutz hessischer Unternehmen ist der Hessische Beauftragte für Datenschutz und Informationsfreiheit (HBDI). Auf seiner Seite zu Internet und Medien steht, dass er die Einhaltung der Datenschutzbestimmungen durch Internet-Anbieter überwacht. Dort verweist er unter anderem auf Hinweise zu Cookies und zu Abmahnungen wegen Google Fonts. Ich bin Entwickler und kein Anwalt, die Rechtsbewertung bleibt bei Ihrer Beratung.

Was ich beitrage, ist eine technische Liste, und die fällt bei Astro kurz aus:

• Jede Insel steht im Code, mit Direktive. Es gibt kein Skript, das unbemerkt mitkommt.
• Jeder Fremddienst (Karte, Video, Analyse, Formularanbieter) steht auf einer Liste mit Zweck und Ladezeitpunkt.
• Schriften: Astros Schriften-API lädt Schriften herunter und liefert sie nach Angabe der Dokumentation von Ihrer eigenen Seite aus. Das kann den Versand von Nutzerdaten an Drittseiten vermeiden.

Aus dieser Liste schreibt Ihre Rechtsberatung die Datenschutzerklärung. Zur Einwilligung vor dem Laden einzelner Dienste und zur Barrierefreiheit finden Sie die Details auf meinen Seiten zu WordPress in Wiesbaden und Wartung und Support in Wiesbaden.

#So läuft ein Astro-Projekt mit mir

Alles ist schriftlich. Termine und Anrufe biete ich nicht an.

1. Briefing. Sie senden mir die URL, Ihr Ziel, den Termin und den aktuellen Stack. Ich lese alles und frage schriftlich nach, was fehlt.
2. Umfang und Annahmen. Ich schreibe auf, was dazugehört, welche Bausteine Inseln werden (mit Direktive und Begründung) und was ich von Ihnen voraussetze. Layout, Grafik und Wireframes liefern Sie, ich setze sie um. Ich beginne erst, wenn Sie diesen Umfang schriftlich bestätigt haben.
3. Aufbau auf einer Testumgebung. Der Stand liegt auf einer Vorschau-Adresse, die Sie jederzeit öffnen können.
4. Messung und Abnahme. Sie prüfen gegen den schriftlichen Umfang, ich liefere dazu die Messwerte gegen die Schwellen. Änderungswünsche außerhalb davon erfasse ich als neues Angebot.
5. Start. Ich schalte um, richte die Weiterleitungen ein und prüfe danach die Crawl-Fehler.
6. Wartung (optional). Auf Wunsch übernehme ich danach Updates, Abhängigkeiten und kleine Änderungen.

Kommen Sie von WordPress oder WooCommerce, beginnt jedes Projekt mit einer Inventur der URLs mit Suchverkehr. Wie das bei Next.js aussieht, steht auf der Seite Migration von Next.js zu Astro in Wiesbaden. Wenn Ihre Seite eher eine Anwendung ist, lohnt der Blick auf Next.js-Entwicklung in Wiesbaden. Für einen Shop mit WordPress im Hintergrund gibt es WooCommerce in Wiesbaden.

#Checkliste: Brauchen Sie wirklich eine Insel?

#Häufige Fragen

#Welche client-Direktive nehme ich für ein Formular oder einen Rechner?

Liegt die Komponente sichtbar im oberen Seitenbereich und soll sofort bedienbar sein, passt client:load. Liegt sie weiter unten, ist client:visible meist besser, weil das JavaScript erst lädt, wenn die Komponente ins Bild kommt. Ich lege das pro Komponente fest und schreibe die Begründung in den Umfang.

#Kann ich React-Komponenten aus meinem bestehenden Projekt weiterverwenden?

Ja. Astro bindet React, Preact, Svelte, Vue, SolidJS und AlpineJS über offizielle Integrationen ein. Eine Komponente ohne client:*-Direktive wird nur zu HTML gerendert. Ob sich eine Komponente zum Übernehmen lohnt, prüfe ich vorher an ihrer Größe und ihren Abhängigkeiten.

#Brauche ich für Server Islands einen eigenen Server?

Sie brauchen einen Adapter, also Hosting, das Seiten bei Anfrage rendern kann. Die Seite selbst kann gecacht bleiben, nur die markierte Komponente kommt dynamisch. Laut Dokumentation läuft das Muster auf einem Node.js-Server im Container genauso wie bei Serverless-Anbietern.

#Woran sehe ich, dass die Astro-Seite besser abschneidet?

Ich messe vor dem Umbau und danach, an derselben Seite, gegen die Schwellen von web.dev: LCP bis 2,5 Sekunden, INP bis 200 Millisekunden, CLS bis 0,1. Laborwerte zeigen mir, wo es hakt. Ob echte Besucher die Schwellen erreichen, zeigen Felddaten. Beides bekommen Sie schriftlich.

#Wer ist in Hessen für den Datenschutz meiner Website zuständig?

Der Hessische Beauftragte für Datenschutz und Informationsfreiheit (HBDI) mit Sitz in Wiesbaden. Er überwacht laut eigener Seite die Einhaltung der Datenschutzbestimmungen durch Internet-Anbieter. Ich liefere die technische Inventur, die Rechtsbewertung übernimmt Ihre Beratung.

#Wie läuft ein Projekt ab, wenn Sie in Wiesbaden sitzen und ich in Gdynia?

Ich arbeite von Gdynia aus ausschließlich schriftlich: Briefing, Rückfragen, Umfang mit Annahmen, Testumgebung zur Abnahme. Termine und Anrufe biete ich nicht an. Die erste Einschätzung bekommen Sie schriftlich und ohne Berechnung.

#Schreiben Sie mir

Schicken Sie mir über das Kontaktformular die URL Ihrer Website, Ihr Ziel, Ihren Termin und den aktuellen Stack, am besten mit den Seiten, auf denen etwas interaktiv sein muss. Ich lese alles, frage schriftlich nach und schicke Ihnen eine erste Einschätzung zu Umfang und Annahmen. Dafür berechne ich nichts. Passt Astro nicht zu Ihrem Vorhaben, schreibe ich das offen und nenne eine bessere Lösung.