- Utilise trois jeux de données : CrUX, HTTP Archive et Core Web Vitals
- Comparaison d'Astro, Gatsby, Next.js, Nuxt, Remix, SvelteKit et même WordPress (puisqu'il représente 43 % de part de marché du web)
- Taux de réussite à l'évaluation Google CWV
- 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)
- Score de performance Lighthouse, valeur médiane
- Astro 65 % > SvelteKit 52 % > Remix 46 %
- Taille du payload JavaScript
- Astro 277KB > SvelteKit 323KB > Remix 568KB
4 commentaires
Il faut créer des sites statiques plus souvent qu’on ne le pense, et il n’y a pas de raison de rejeter Astro à ce point.
SvelteKit a une syntaxe concise, mais contrairement à SolidStart, il ne prend pas en charge les islands, donc ajouter Astro est une bonne façon de compenser.
Cependant, comme l’a mentionné Ryan, le créateur de Solid, les islands ne sont « qu’une des nombreuses approches possibles ». Il est important d’élargir sa perspective et d’utiliser la méthode adaptée à chaque situation.
(1) Surpondération du chargement initial de la page alors qu’on compare des cas d’usage très hétérogènes. Les frameworks généralistes comme Next et Nuxt sont bien plus souvent utilisés pour créer des « apps » que des « sites » centrés sur le contenu, pour lesquels des frameworks comme Astro ont été explicitement conçus.
Ces cas d’usage très différents impliquent des priorités d’optimisation très différentes en matière de chargement de page et de rapidité des interactions après chargement, mais le rapport mélange sans discernement les données de ces usages variés.
Pour montrer qu’Astro excelle dans la création de sites centrés sur le contenu, les données devraient comparer uniquement des sites centrés sur le contenu construits avec différents fw, et non mélanger sites et apps. Malgré la mention de l’INP (Interaction to Next Paint), la comparaison reste fondamentalement biaisée.
(2) Biais lié à l’ancienneté des frameworks. C’est mentionné à la fin du rapport, mais cela mériterait probablement d’être signalé plus visiblement. En particulier, Nuxt 3 récent offre des gains de performance substantiels par rapport à Nuxt 2, mais l’ensemble de données est probablement composé en grande majorité de sites Nuxt 2 existants.
Les compétences générales du développement web en matière de performance évoluent avec le temps, donc l’époque d’un FW recouvre bien plus que le FW lui-même. Next et Nuxt sont sortis en 2016. À l’époque, les développeurs connaissaient généralement moins bien les meilleures pratiques de performance modernes, et des métriques de référence comme les CWV n’existaient même pas.
(3) Biais de sélection / d’échantillonnage. Ce rapport ne précise pas combien de sites ont été identifiés pour chaque framework dans l’ensemble de données, mais j’imagine que le volume de sites Astro ne représente qu’une fraction de celui des frameworks plus anciens.
En tant que jeune framework mis en avant avec un marketing orienté performance, la base d’utilisateurs actuelle d’Astro est probablement principalement composée d’early adopters sensibles aux performances, tandis que des frameworks plus grand public ont, en moyenne, une base d’utilisateurs moins focalisée sur la performance en raison d’une adoption plus large.
Je pense qu’Astro est performant pour les cas d’usage auxquels il est destiné, mais comme toujours, il faut prendre les comparaisons de performance avec une pincée de sel, surtout quand elles sont motivées par le marketing.
===
https://twitter.com/youyuxi/status/1633249827755814912
Gardez à l’esprit qu’il s’agit d’un article rédigé par l’équipe d’Astro ;)