Von WordPress zu Astro: Warum wir unsere eigene Website komplett neu gebaut haben

Wer Kunden seit Jahren predigt, dass Performance kein Nice-to-Have ist, sondern Rankingfaktor, Conversion-Treiber und User-Experience-Faktor in einem — der sollte das auf seiner eigenen Seite auch leben. Im Mai 2026 haben wir genau das gemacht: copex.io komplett neu aufgesetzt. Weg von WordPress, hin zu Astro, Tailwind und Markdown — gerendert als statische Seite, deployed über GitLab CI, versioniert in Git wie jedes andere Projekt bei uns. Hier ist, warum.

Was vorher war: WordPress

Unsere alte Seite lief auf WordPress mit einem soliden, aber in die Jahre gekommenen Theme. Über die Zeit kamen Plugins dazu: für SEO, für Cookie-Consent, für Tracking-Integration, für Bildkomprimierung, für irgendetwas anderes. Die Datenbank wuchs. Inhalte und Templates verkamen zu einem Gemenge — was wo definiert war, hatte irgendwann nur noch das Backend selbst zuverlässig im Griff.

Was uns konkret gestört hat:

• Performance. Selbst mit Caching-Plugin und WebP-Conversion landeten wir bei Lighthouse-Werten, die wir bei Kundenprojekten nicht akzeptieren würden. LCP über vier Sekunden auf langsamem 4G — Tatort: zu viele render-blocking Scripts, zu viel CSS-Ballast aus dem Theme, ein Bild-Setup ohne width/height-Attribute.
• Design und Content vermischt. Texte lebten in der DB, Layout in PHP-Templates und Plugin-Configs. Ein Theme-Wechsel oder ein größerer Layout-Umbau hätte Migrations-Skripte und sehr viel Geduld gebraucht. Headless-CMS-Ansätze — Inhalt strikt vom Frontend trennen — kannten wir lange nur aus Kundenprojekten.
• Keine echte Versionierung. Content lebte in der Datenbank, Theme-Anpassungen in PHP-Dateien, Backups als Snapshots. Wer wollte wissen, “wann genau hat jemand den Job-Titel auf der Karriere-Seite geändert” — keine Antwort, außer durch Glück oder ein bemühtes Suchen in Plugin-History-Logs.

Wir sind Entwickler. Bei jedem Kundenprojekt setzen wir voraus, dass Änderungen in Git landen, Pull Requests durchlaufen, im CI gebaut und getestet werden. Für unsere eigene Website galt das jahrelang nicht. Etwas, das uns ehrlicherweise selbst gestört hat.

Was wir gebaut haben: Astro, Tailwind, Markdown

Die Architektur ist bewusst nüchtern:

• Astro als Static-Site-Generator. Build-Time-Rendering, keine Server-Logik im Auslieferungspfad, alle Seiten als reines HTML/CSS/JS. Component-Islands für die wenigen Stellen, an denen interaktives JavaScript wirklich Sinn macht — Suche, Cookie-Banner, Stimmen-Slider, sonst nichts.
• Tailwind CSS für das Styling. Keine globale CSS-Suppe, sondern utility-first Styles direkt im Component. Tree-Shaking komprimiert das Ergebnis auf einen Bruchteil dessen, was ein klassisches Theme an CSS schleppt.
• Markdown Content Collections für alle redaktionellen Inhalte: Blog-Posts, Service-Beschreibungen, Referenzen, Team, Stimmen, Jobs. Jeder einzelne Inhalt ist eine .md-Datei mit Frontmatter im Repository. Typsicher (mit zod-Schema, das beim Build validiert), versioniert, durchsuchbar mit grep.

Das Build-Resultat liegt als statisches HTML hinter einem nginx in Österreich. Kein PHP im kritischen Pfad, keine Datenbank-Connection beim Request, kein CMS-Backend, das man Donnerstag-Nachmittag sicherheits-patchen müsste.

Trennung Design ↔ Content: das Headless-Prinzip ohne Hosted CMS

Headless-CMS-Anbieter wie Storyblok, Sanity oder Contentful geben ein einfaches Versprechen: trenne Inhalt strikt vom Frontend, damit beide unabhängig voneinander weiterentwickelt werden können. Für viele Kunden eine gute Antwort.

Für uns nicht ganz. Wir wollten dasselbe Prinzip — ohne externes Hosted CMS. Inhalt lebt bei uns in Markdown im Repository. Design lebt in Astro-Komponenten daneben. Will ich morgen das Hero-Layout aller Service-Seiten überarbeiten, ändere ich genau eine Komponente — der Inhalt aller zwölf Service-Markdowns bleibt unangetastet. Umgekehrt: schreibe ich einen neuen Blogpost, fasse ich keine Layout-Datei an.

Das ist der Headless-Pattern, nur dass das “CMS” hier kein externer Service ist, sondern Git und ein Texteditor. Für ein Entwickler-Team eine natürliche Lösung. Für ein reines Redaktions-Team wäre Hosted CMS bequemer — den Trade-off wollten wir bewusst.

Tailwind: das Know-how aus Hyvä

Wer Hyvä-Themes für Magento entwickelt, arbeitet seit Jahren mit Tailwind. Wir auch. Die Entscheidung, copex.io ebenfalls auf Tailwind aufzubauen, war keine Hipster-Wahl — sondern reine Konsistenz mit dem Stack, in dem wir täglich Kundenprojekte umsetzen.

Konkret heißt das: dieselben Entwickler:innen können am Vormittag an einem Hyvä-Shop arbeiten und am Nachmittag an der eigenen Website. Dieselben Patterns. Dieselben Utility-Klassen. Keine doppelte mentale Buchhaltung. Und wenn ein neues Pattern entsteht — ein Card-Layout, ein Pricing-Block, ein Hero — fließt es in beide Welten zurück.

Git als CMS: Markdown-Editor, Commits, History

Wer ein WordPress-Backend aufgemacht und festgestellt hat, dass auf einmal Inhalte verschwunden sind, kennt das Gefühl: ohne Versionierung ist Content-Verwaltung ein Vertrauensvorschuss an dich selbst, an die DB, an das letzte Backup. Mit Git ist es eine nachvollziehbare Historie.

Konkret läuft unser Redaktions-Workflow so:

1. Lokal git pull auf den master-Branch
2. Neuen Markdown-File für den Beitrag anlegen, Bilder ins src/assets/images/blog/-Verzeichnis legen
3. Text schreiben — im Markdown-Editor der Wahl. Wir nutzen wahlweise Obsidian (Live-Preview, schöne Outline, gute Bilder-Handhabung) oder VS Code (näher am Repo-Workflow). Wer beides nicht mag: nahezu jeder Editor mit Markdown-Vorschau funktioniert.
4. git commit -m "neuer Post: ...", git push
5. GitLab CI baut die Seite, deployed sie automatisch nach nginx

Wer möchte, kann Schritt 4–5 auch über einen Pull Request laufen lassen — Vier-Augen-Prinzip für Redaktion, Review der Texte vor Veröffentlichung. Tun wir bei größeren Blogposts. Bei kleinen Korrekturen reicht Direkt-Commit.

Was man dabei nebenbei bekommt: eine vollständige History pro Inhalt. Wer wann was an einer Service-Beschreibung geändert hat — git log zeigt es. Welche Version war im Februar live — git checkout 51632f4. Probleme nach einem Deploy? Rollback auf den letzten guten Commit.

Wir sind Entwickler. Es wäre absurd gewesen, das nicht zu nutzen.

Performance: das Ergebnis

Genug Vorrede. Hier ist der Lighthouse-Score der neuen Startseite auf einem emulierten Moto G Power mit gedrosselter 4G-Verbindung:

Was wir konkret gemacht haben, um dahin zu kommen:

• Font-Subsetting auf Latin-only. Von 39 @font-face-Deklarationen auf 8 reduziert, CSS-Bundle von 29 KiB auf 14 KiB gzipped halbiert. de-AT braucht keine cyrillischen oder vietnamesischen Subsets.
• Above-the-Fold Font-Preload. Blinker 700 + 800, Inter 400 + 600 starten parallel zum HTML-Parse statt erst nach dem CSSOM-Resolve. Spart auf 4G mehrere hundert Millisekunden.
• LCP-Image fetchpriority="high". Das Logo wird mit höchster Priorität geladen, kein Warten auf nachrangige Render-Schritte.
• Explizite width/height-Attribute auf allen Bildern. Layout-Shifts beim Laden vermeiden, CLS sauber bei null.
• Content-gehashte Asset-URLs. Astro hashed CSS, JS, Bilder und Fonts automatisch — nginx liefert mit Cache-Control: immutable, max-age=1y aus. Repeat-Visits sind ohne Round-Trip im Cache.
• Render-blocking CSS Preload als erstes Element im <head>. Browser kennt die CSS-URL noch bevor er die Meta-Tags parst. Eingebaut über eine kleine Astro-Build-Integration, die den Content-Hash automatisch in alle HTML-Files patcht.
• WCAG-2.5.8-konforme Touch-Targets auf allen interaktiven Elementen. 24×24 px Mindestgröße, auch für dekorative Pagination-Dots.

Das ist exakt das technische Repertoire, mit dem wir auch bei Kunden-Shops arbeiten — siehe unsere Services rund um Magento-Entwicklung, Hyvä-Migrationen und das Cloud-Exit-Vorgehen für hosting-bedingte Performance-Probleme.

Ein Moment, der hängengeblieben ist

Als der erste Deploy auf der neuen Architektur live ging, haben wir die alte WordPress-Seite zum Vergleich daneben aufgemacht. Beide auf demselben Notebook, beide im selben Browser, beide auf derselben Internetverbindung. Die neue Seite war fertig geladen, bevor die alte überhaupt das Hintergrundbild des Headers gerendert hatte.

Es war ein bisschen der Moment, in dem wir uns gefragt haben, warum wir das nicht schon vor zwei Jahren gemacht haben.

Was du als nächstes tun kannst

Wenn deine Website oder dein Magento-Shop performance-mäßig hinterherhinkt, gibt es zwei pragmatische erste Schritte:

1. Selbst einen Lighthouse-Test fahren auf pagespeed.web.dev. Was steht oben in roter Schrift? LCP über 2,5 Sekunden? CLS über 0,1? Das sind die größten Hebel.
2. Performance-Audit anfragen. Wir machen für Magento-Shops und Websites in 1–2 Wochen Bestandsaufnahme, Optimierungs-Roadmap und konkrete Maßnahmenliste. Kontakt: office@copex.io oder Audit anfragen.

Verwandte Themen aus unserem Blog: Performance bei Luma vs. Hyvä, Bildoptimierung für Hyvä, Largest Contentful Paint optimieren, Raus aus der Cloud — eine AWS-zu-Linz-Migration.

Und der Code dieser Website? Liegt selbstverständlich in Git. Als Entwickler-Agentur fanden wir das nur konsequent.