- Nutzung von drei Datensätzen: CrUX, HTTP Archive und Core Web Vitals
- Vergleich von Astro, Gatsby, Next.js, Nuxt, Remix, SvelteKit und sogar Wordpress (weil der Web-Marktanteil bei 43 % liegt)
- Bestehensquote bei der Google-CWV-Bewertung
- Astro 67 % > SvelteKit 45 % > Gatsby 39 % > Remix 35 % > Wordpress 30 % > Next.js 27 % > Nuxt 20 %
- First Input Delay (FID), Cumulative Layout Shift (CLS), Largest Contentful Paint (LCP), Interaction to Next Paint (INP)
- Lighthouse-Performance-Score, Median
- Astro 65 % > SvelteKit 52 % > Remix 46 %
- Größe der JavaScript-Payload
- Astro 277KB > SvelteKit 323KB > Remix 568KB
4 Kommentare
Es gibt überraschend oft Gelegenheiten, statische Websites zu erstellen, daher gibt es keinen Grund, Astro so stark auszuschließen.
SvelteKit hat zwar eine knappe Syntax, unterstützt aber im Gegensatz zu SolidStart keine Islands, weshalb die Ergänzung durch Astro eine gute Ausgleichslösung ist.
Wie Solid-Entwickler Ryan jedoch anmerkte, sind Islands „nur eine von mehreren Methoden“. Es ist wichtig, den Blick zu weiten und je nach Situation die passende Methode zu nutzen.
(1) Starkes Overindexing auf den initialen Seitenaufbau, während sehr gemischte Use Cases verglichen werden. Allgemeine Frameworks wie Next und Nuxt werden sehr viel häufiger zum Bauen von „Apps“ verwendet als für inhaltszentrierte „Sites“, für die Frameworks wie Astro explizit entworfen wurden.
Diese unterschiedlichen Use Cases haben sehr unterschiedliche Optimierungsprioritäten in Bezug auf Seitenladezeit und Interaktionsgeschwindigkeit nach dem Laden, aber der Bericht mischt die Daten aus diesen unterschiedlichen Use Cases undifferenziert zusammen.
Um zu zeigen, dass Astro gut darin ist, inhaltszentrierte Sites zu bauen, sollten die Daten nicht Sites und Apps gemeinsam vergleichen, sondern nur inhaltszentrierte Sites, die mit unterschiedlichen fw gebaut wurden. Trotz der Erwähnung von INP (Interaction to Next Paint) weist der Vergleich weiterhin grundlegende Mängel auf.
(2) Altersbias bei Frameworks. Das wurde am Ende des Berichts erwähnt, braucht aber vermutlich eine deutlich sichtbarere Hervorhebung. Insbesondere das neuere Nuxt 3 bietet im Vergleich zu Nuxt 2 erhebliche Performance-Verbesserungen, aber der Datensatz besteht wahrscheinlich überwiegend aus älteren Nuxt-2-Sites.
Die allgemeine Webentwicklungs-Kompetenz rund um Performance entwickelt sich im Lauf der Zeit weiter, daher hängt das Alter eines FW mit mehr Faktoren zusammen als nur mit dem FW selbst. Next und Nuxt wurden 2016 veröffentlicht. Damals waren Entwickler im Allgemeinen mit aktuellen Performance-Best-Practices nicht so gut vertraut, und Leitmetriken wie CWV existierten noch nicht einmal.
(3) Auswahl-/Stichprobenbias. Dieser Bericht gibt nicht an, wie viele Sites für jedes Framework im Datensatz erfasst wurden, aber ich vermute, dass die Zahl der Astro-Sites nur einen Bruchteil der früheren Frameworks ausmacht.
Als junges Framework, das performanceorientiertes Marketing nutzt, besteht Astros heutige Nutzerbasis hauptsächlich aus performance-sensiblen Early Adopters, während stärker etablierte Mainstream-Frameworks aufgrund ihrer breiteren Verbreitung im Durchschnitt eine Nutzerbasis haben, die weniger auf Performance fokussiert ist.
Ich denke, Astro liefert für seinen beabsichtigten Use Case eine starke Performance, aber wie immer sollte man Performance-Vergleiche mit einer Prise Salz und mit Blick auf die Marketing-Motivation betrachten.
===
https://twitter.com/youyuxi/status/1633249827755814912
Behalte im Hinterkopf, dass der Artikel vom Astro-Team geschrieben wurde ;)