Astro-Seiten bestehen die Core Web Vitals zu 67 Prozent. WordPress zu 49. Woher der Abstand kommt.

Neunundvierzig Prozent aller WordPress-Seiten bestehen die Core Web Vitals. Bei Astro sind es siebenundsechzig Prozent. Das sind Felddaten vom April 2026 aus dem Chrome UX Report und dem HTTP Archive, wie das Search Engine Journal berichtet, und es ist das Fairste, was wir an einem direkten Vergleich haben: Millionen echter Seiten, echte Besucher, echte Netzwerke.

Ich will hier vorsichtig sein, denn die meisten Beiträge zum Thema Astro vs WordPress Performance werden von Leuten geschrieben, die eines von beiden verkaufen. Dieser hier besteht deshalb aus Zahlen, auf die ich zeigen kann. Veröffentlichte Benchmarks, öffentliche Felddaten, echte Preisseiten und eine Messreihe, die ich selbst gemacht und schon dokumentiert habe. Wo ich schätze, sage ich es laut dazu.

Fangen wir mit dem Teil an, der mich am meisten überrascht hat. Denn es ist nicht der Teil, über den alle streiten.

Astro 7 hat die Build-Zeiten um 15 bis 61 Prozent gesenkt, und 40 Prozent davon habe ich selbst gemessen

Astro 7 kam am 22. Juni 2026 raus und hat den .astro-Compiler von Go nach Rust umgeschrieben, die Markdown- und MDX-Pipeline durch einen Rust-Prozessor namens Sätteri ersetzt und ist auf Vite 8 mit Rolldown gewechselt. Astros eigener Release-Post veröffentlicht die Benchmark-Tabelle auf einem M4 Pro: Die 308 Seiten von astro.build gingen von 62,70s auf 24,24s runter (61,3% schneller), die rund 6.313 Seiten von docs.astro.build von 114,54s auf 73,53s (35,8%) und die 8.431 Seiten von developers.cloudflare.com von 386,89s auf 261,94s (32,3%). Der Rolldown-Bundler wird mit 10- bis 30-mal schneller als Rollup angegeben, der neue Queued Renderer mit ungefähr dem 2,4-fachen des alten rekursiven.

Bei Hersteller-Benchmarks werde ich nervös, also habe ich meine eigenen gemacht, bevor ich hier ein Wort geschrieben habe. Auf einer Seite mit 129 Seiten ging der Production Build von 4,95s unter Astro 6 auf 2,95s unter Astro 7 runter, Median aus fünf Durchläufen, gleiche Maschine, gleiche Node-Version. Vierzig Prozent, für den Preis einer geänderten Versionsnummer. Die komplette Aufschlüsselung, inklusive der Zahlen, die sich partout nicht bewegen wollten, steht in Astro 6 to 7: the real numbers from upgrading a 129-page site.

Und jetzt der ehrliche Haken: WordPress hat überhaupt keinen Build-Schritt, diese ganze Spalte ist also ein Kategorieunterschied und kein Sieg. WordPress rendert stattdessen bei jedem Request. Genau dieser Tausch ist die ganze Geschichte, und daher kommen auch die Laufzeit-Zahlen.

Die Felddaten: 2,76 MB gegen 1,65 MB

Der CrUX- und HTTP-Archive-Snapshot vom April 2026 setzt das mediane Seitengewicht bei WordPress auf 2,76 MB und bei Astro auf 1,65 MB. Medianer Lighthouse-Score: WordPress 44, Astro 68. Core-Web-Vitals-Bestehensquote: WordPress 49%, Astro 67%. Zur Einordnung: Der Web Almanac 2025 hat den Median über das gesamte Web bei etwa 2,4 MB gesehen. WordPress ist also schwerer als der Durchschnitt, Astro deutlich leichter.

Zwei Einschränkungen, die ich nicht weglasse. Erstens ist das ein Populationsvergleich, kein kontrolliertes Experiment. Astro-Seiten sind tendenziell von Entwicklern gebaute Marketing-Seiten und Dokumentationen. WordPress trägt alles, vom handoptimierten Agentur-Build bis zum Theme von 2014 mit 43 Plugins, das seitdem niemand angefasst hat. Zweitens heißt Astro bei 67% immer noch, dass ein Drittel aller Astro-Seiten die Core Web Vitals nicht besteht. Das Framework ist kein automatischer Freifahrtschein.

Was die Daten hergeben, ist eine Richtungsaussage: Die mediane WordPress-Seite liefert pro Seitenaufruf rund ein Megabyte mehr aus als die mediane Astro-Seite, und der Unterschied taucht in Feldmessungen an echten Besuchern auf, nicht in Labortests.

TTFB ist der Punkt, an dem die Architektur wirklich entscheidet

Seitengewicht ist ein Symptom. Der strukturelle Unterschied liegt darin, was in den ersten paar hundert Millisekunden passiert.

Ein ungecachter WordPress-Request weckt PHP, bootet den Core, lädt jedes aktive Plugin, stellt mehrere MySQL-Abfragen, rendert ein Theme-Template und fängt dann erst an, Bytes zu schicken. Eine statische Astro-Seite ist eine Datei, die auf einem CDN-Edge-Node schon existiert. Googles Schwellenwert setzt einen Time to First Byte von 800ms oder weniger in den "guten" Bereich, 800ms bis 1,8s in "verbesserungswürdig" und alles über 1,8s als schlecht. Der mediane mobile TTFB im HTTP Archive liegt bei rund 1,3s, was dir sagt, wie viel vom Web in diesem Mittelfeld feststeckt.

Das sage ich deutlich dazu: Ich habe keinen veröffentlichten, direkt vergleichbaren TTFB-Benchmark mit identischen Inhalten auf beiden Stacks. Wer dir einen hinlegt, hat ihn vermutlich gebaut, um zu gewinnen. Was ich dir aus der Kundenarbeit sagen kann, ist die grobe Form: Ungecachte PHP-Seitengenerierung landet typischerweise im hohen dreistelligen Millisekundenbereich, ein Full-Page-Cache-Treffer oder eine statisch vom Edge ausgelieferte Datei landet im niedrigen zweistelligen Bereich. Das ist eine grobe Beschreibung aus Seiten, an denen ich gearbeitet habe, keine kontrollierte Messung, und du solltest deine eigene messen, bevor du sie zitierst. Mein guide to testing website load time zeigt, wie das geht.

Der ganze Vergleich in einer Tabelle

Hier ist der komplette Vergleich Astro vs WordPress Performance an einem Ort. Jede Zelle sagt, woher sie kommt, und jede Schätzung ist als Schätzung markiert.

Kennzahl	WordPress	Astro 7	Quelle
Build-Zeit	Kein Build-Schritt	24,24s für 308 Seiten, 73,53s für 6.313	Astro-7-Release-Post, M4 Pro
Build-Beschleunigung, v6 auf v7	n/a	15% bis 61% veröffentlicht, 40% auf meiner eigenen 129-Seiten-Site	Astro-Release-Post; meine Upgrade-Zahlen
Medianes Seitengewicht	2,76 MB	1,65 MB	CrUX + HTTP Archive, April 2026
Medianer Lighthouse-Score	44	68	Gleicher Datensatz
Core-Web-Vitals-Bestehensquote	49%	67%	Gleicher Datensatz
TTFB, ungecacht	Hunderte ms (Schätzung)	Nicht anwendbar, Dateien sind vorgebaut	Meine Kundenarbeit, als Schätzung markiert
TTFB, gecacht oder vom Edge	Niedrige zweistellige ms (Schätzung)	Niedrige zweistellige ms (Schätzung)	Dieselbe
Standardmäßig ausgeliefertes JS	Theme- plus Plugin-Skripte, jQuery immer noch verbreitet	0 KB, außer du entscheidest dich aktiv für eine Island	Framework-Defaults
Hosting, Einstiegsstufe	25 $/Monat WP Engine, 35 $/Monat Kinsta	0 $ im Cloudflare-Pages-Free-Tier	Preisseiten der Anbieter, 2026

Auf die letzte Zeile reagieren Kunden am stärksten, und genau sie ist für sich allein am irreführendsten. Dazu gleich mehr.

Wo WordPress den Abstand schließt, und es schließt einen großen Teil davon

Eine gute Caching-Schicht ändert fast alles in der Laufzeit-Hälfte dieser Tabelle. Wenn ein Full-Page-Cache eine vorgebaute HTML-Datei ausliefert, hört WordPress für diesen Request auf, eine PHP-Anwendung zu sein, und wird faktisch zum Static File Server. PHP bootet nicht. MySQL wird nicht abgefragt. Der architektonische Vorteil, den ich zwei Abschnitte vorher beschrieben habe, löst sich weitgehend auf.

Über das Werkzeug dafür habe ich schon geschrieben. FlyingPress macht Page Caching, Critical CSS, Lazy Loading und das Entfernen ungenutzten CSS gut genug, dass ich damit ehrlich langsame Kundenseiten in solche verwandelt habe, die die Core Web Vitals bestehen. Kombiniere das mit einem Hoster, der Caching auf Serverebene und ein echtes CDN hat, statt mit 4-Dollar-Shared-Hosting, und du führst eine komplett andere Diskussion. Genau deswegen habe ich Cloudways getestet.

Die faire Version der Aussage ist also enger als die Schlagzeile: Eine gut gehostete, gut gecachte WordPress-Seite schlägt eine schlecht gebaute Astro-Seite ohne Probleme. Die 49% sind kein Urteil über WordPress als Software. Sie sind ein Urteil über die mediane WordPress-Installation, und das ist etwas ganz anderes. Der Abstand in den Felddaten ist vor allem ein Abstand bei Defaults, Plugin-Disziplin und Hosting-Budget.

Wo WordPress strukturell weiter verliert: in der JavaScript-Zeile. Astro liefert null JS aus, solange du keine Komponente ausdrücklich hydrierst. WordPress liefert alles aus, was dein Theme und jedes aktive Plugin einreihen, und Cache-Plugins können das verzögern, aber keine Features löschen, die du tatsächlich benutzt. Wenn deine Seite fünf Plugins lädt, die jeweils ihr eigenes Skript einbinden, lässt keine Caching-Schicht diese Bytes verschwinden.

Die Kostenspalte hat eine zweite Hälfte, die dir niemand zeigt

Kostenloses Hosting ist real. Cloudflare Pages liefert statische Seiten im Free Tier mit unbegrenzter Bandbreite und unbegrenzten Requests aus, und ich betreibe Kundenseiten darauf. Gegen 25 bis 35 Dollar im Monat für Einsteiger-Managed-WordPress sind das auf dem Papier 300 bis 420 Dollar Ersparnis im Jahr.

Nur ist das Papier unvollständig. Wenn der Kunde Inhalte selbst bearbeiten will, braucht eine Astro-Seite ein CMS dahinter, und das ist entweder ein gehosteter Dienst mit eigener Rechnung oder ein selbst gehosteter mit eigenem Server. Dazu die Entwicklerstunden für eine Build-Pipeline, die eine WordPress-Seite mit einem Admin-Login geschenkt bekommt. Für eine fünfseitige Broschürenseite, die sich zweimal im Jahr ändert, ist der Free Tier die ehrliche Antwort. Für eine Seite, auf der drei nicht-technische Leute wöchentlich publizieren, kann die Hosting-Ersparnis schon mit der ersten Rechnung für "kannst du im Blog-Template noch ein Feld ergänzen" verpuffen.

Diese ganze Rechnung, und wie sie über den Stack entscheidet, gehe ich in WordPress, Next.js, or Astro? Here's how I actually decide for client projects durch. Und falls du dich fragst, ob der Wechsel selbst überlebbar ist: Ich habe drei Kundenseiten von WordPress nach Astro geholt, und nichts ist kaputtgegangen.

Was ich daraus tatsächlich schließe

Der messbare Unterschied bei Astro vs WordPress Performance ist echt, er beträgt im Median grob ein Megabyte Seitengewicht und 18 Prozentpunkte bei der Core-Web-Vitals-Bestehensquote, und er kommt aus der Architektur: Ein Stack liefert eine Datei aus, der andere baut eine zusammen.

Aber der Abstand ist nicht in Stein gemeißelt. Der größte Teil der Laufzeit-Hälfte schließt sich mit einem Caching-Plugin und einem kompetenten Hoster, und das kostet weniger und geht seltener schief als eine Migration. Die Build-Hälfte trifft auf WordPress überhaupt nicht zu. Und die Kosten-Hälfte hängt komplett davon ab, wer die Seite bearbeitet und wie oft.

Was ich dir raten würde, bevor du mir oder sonst jemandem glaubst: Miss deine eigene Seite. Felddaten aus CrUX, nicht ein Lighthouse-Lauf über deine Gigabit-Leitung im Büro. Wenn deine WordPress-Seite die Core Web Vitals schon besteht, ist das Performance-Argument für einen Wechsel erledigt, und ihr solltet stattdessen über Wartung und Sicherheit streiten. Wenn sie es nicht tut, probier zuerst die Caching-Schicht. Das ist ein Dienstagnachmittag, kein Quartal.

Diese Messarbeit mache ich für Kunden bei Wunderlandmedia: erst benchmarken, dann entscheiden, was sich wirklich lohnt neu zu bauen. Meistens weniger, als das Pitch-Deck behauptet.