Astro ou WordPress : lequel choisir pour votre site ?

Deux devis sont sur la table. Une agence propose de refaire le site avec Astro, le prestataire habituel ne jure que par WordPress, et chacun vend ce qu’il connaît. Nous non plus ne sommes pas neutres : ce site est construit avec Astro, comme Palmora Property, un portail immobilier que nous opérons pour un client, en six langues et sur plus de 3 000 adresses. Ce comparatif s’appuie donc sur ce que les deux projets écrivent eux-mêmes et sur des mesures de terrain, pas sur nos préférences. La réponse dépend moins de la technologie que de la façon dont votre équipe publie. Si la décision de quitter WordPress est déjà prise, passez directement à pourquoi migrer vers un site statique avec Astro.

Deux façons de fabriquer une page

WordPress est écrit en PHP et s’appuie sur une base de données MySQL. À chaque visite, le serveur assemble la page : il lit les contenus dans la base, applique le thème et les extensions, puis renvoie le résultat. Un cache réduit l’écart en gardant des pages déjà assemblées, mais le serveur d’application reste là, avec sa base, à faire tourner et à mettre à jour.

Astro fabrique les pages au moment de la publication. Le résultat est un dossier de fichiers HTML, CSS et images qu’un hébergeur sert tels quels : aucune base de données ni aucun code n’est sollicité quand un visiteur arrive. Astro sait aussi rendre des pages à la demande, sur un serveur, quand elles doivent l’être : c’est le cas des pages de Palmora Property, rendues côté serveur.

La documentation d’Astro consacre un guide à la migration depuis WordPress. Elle n’est pas neutre, mais elle reste honnête sur ce qu’on perd en changeant :

Le même guide relève ce qu’ils partagent : tous deux conviennent aux sites de contenu comme les blogs, tous deux pensent la page en blocs, et tous deux acceptent le Markdown, avec une extension côté WordPress.

Ce que mesurent les données de terrain

Le rapport par technologie de HTTP Archive compare les sites selon la technologie qui les fait tourner. Il compte la part des sites, au sens d’un domaine, dont les visites réelles passent les trois seuils que Google fixe pour l’affichage, la stabilité et la réactivité, au 75e centile, c’est-à-dire pour au moins trois chargements de page sur quatre. Ce sont des mesures de terrain, prises chez les visiteurs, pas des tests en laboratoire.

Sur ordinateur, l’écart est du même ordre : 84,6 % des sites Astro passent les trois seuils, contre 53,7 % des sites WordPress. La différence la plus nette porte sur le temps de réponse du serveur, qui ne fait pas partie des trois seuils : il est jugé bon pour 63,1 % des sites Astro sur mobile, contre 22,9 % des sites WordPress. C’est cohérent avec les deux façons de fabriquer une page : un fichier déjà prêt part plus vite qu’une page assemblée à la demande.

Trois précautions avant d’en tirer une conclusion :

1. WordPress fait mieux sur un point : la réactivité aux interactions, jugée bonne pour 90,3 % de ses sites contre 85,0 % des sites Astro. Le rapport ne dit pas pourquoi.
2. Ce sont deux populations, pas une expérience. Le rapport mesure 2 658 175 sites WordPress sur mobile, contre 47 277 sites Astro, et un site Astro s’entretient depuis un éditeur de code, ce qui dit déjà quelque chose de qui le fabrique. Rien ne garantit que votre site, refait avec Astro, gagnerait autant.
3. Près de la moitié des sites WordPress passent les trois seuils. Un WordPress bien tenu peut être rapide : mesurez le vôtre avant de conclure qu’il faut en changer.

Ce que WordPress fait mieux

• Le tableau de bord, dès l’installation. Une personne sans profil technique écrit, met en forme et publie sans toucher à un fichier. Avec Astro, il faut brancher un CMS pour retrouver ce confort.
• Le marché des extensions. Formulaires, réservations, adhésions, référencement : la plupart des besoins courants ont déjà leur extension. Le guide d’Astro prévient qu’une partie des fonctions est à reconstruire.
• L’écosystème. Le rapport de HTTP Archive mesure plus de 2,6 millions de sites WordPress sur mobile, contre environ 47 000 sites Astro : trouver un prestataire, un thème ou une réponse à une question y est plus simple.
• Les équipes éditoriales. WordPress prévoit d’origine des rôles : un contributeur écrit sans pouvoir publier, un éditeur publie les articles des autres. Ses statuts couvrent la relecture en attente et la publication programmée. Un site Astro obtient ces fonctions par le CMS qu’on lui branche.
• La vente en ligne. WordPress dispose d’extensions de commerce ; un site Astro confie la transaction à une plateforme de commerce.

Ce qu’Astro fait mieux

La vitesse, d’abord, pour les raisons vues plus haut : une page déjà fabriquée n’attend ni base de données ni serveur d’application.

La sécurité et l’entretien. Le guide de sécurisation de WordPress rappelle que les anciennes versions ne reçoivent plus de correctifs de sécurité et demande, avant toute chose, de tenir les extensions à jour ; les mises à jour automatiques existent depuis la version 3.7. Un site Astro statique n’a ni base de données ni code exécuté à la visite : il reste peu de chose à attaquer. Le risque se déplace vers les dépendances qui servent à construire le site : elles se tiennent à jour elles aussi, mais elles tournent pour l’essentiel au moment de la publication, pas devant chaque visiteur.

Le multilingue. La documentation de WordPress le dit sans détour : WordPress ne gère pas d’origine un site bilingue ou multilingue, et ce sont des extensions de la communauté qui s’en chargent. Astro intègre un routage par langue qui fabrique, utilise et vérifie les adresses de chaque langue.

Ce coût tient au modèle et au cache, pas à Astro. Ce qu’Astro apporte, c’est une adresse par langue, fabriquée et vérifiée par le framework ; le reste se joue dans les balises hreflang, où se cachent les erreurs qui coûtent cher au SEO multilingue.

Des contenus dans des fichiers. Sur ce site, chaque article est un fichier : il arrive en brouillon, se relit sur une adresse d’aperçu et part en ligne une fois accepté. Ce format se prête au travail avec un assistant de code fondé sur un modèle d’IA : on demande une correction, l’assistant trouve le fichier, le modifie et montre le résultat sur un aperçu avant que rien ne parte en ligne. Et ces fichiers se servent presque de n’importe où : héberger un site statique coûte peu, tant que le site n’exécute pas de code à chaque visite.

La troisième voie : WordPress pour écrire, Astro pour servir

Le choix n’est pas forcément exclusif. La documentation d’Astro décrit l’usage de WordPress comme CMS sans tête : l’équipe garde son tableau de bord, et l’API REST de WordPress, disponible par défaut sur tout site, fournit les contenus qu’Astro transforme en pages. Une extension GraphQL est possible, pas indispensable.

Le prix de ce montage : deux systèmes au lieu d’un, un WordPress qui reste à mettre à jour même s’il ne sert plus les visiteurs, et un mécanisme qui reconstruit le site à chaque publication, ou des pages rendues à la demande. Le même raisonnement vaut pour un CMS conçu pour cet usage : nous l’avons détaillé dans un site headless avec Astro et Sanity.

Comment choisir, en cinq questions

1. Qui publie, et à quelle fréquence ? Une équipe éditoriale qui publie chaque jour depuis un tableau de bord penche vers WordPress, seul ou branché sur Astro. Un site mis à jour quelques fois par mois s’accommode très bien de fichiers.
2. Le site vend-il, ou gère-t-il des comptes de visiteurs ? Si oui, la transaction ou l’espace client décident du reste : WordPress et ses extensions, ou Astro relié à une plateforme qui s’en charge.
3. Combien de langues ? Au-delà d’une, comparez le routage par langue intégré à Astro et l’extension qu’il faudra choisir et tenir à jour côté WordPress.
4. Qui entretiendra le site dans un an ? Un WordPress se met à jour, extensions comprises ; un site Astro demande quelqu’un à l’aise avec un éditeur de code, ou un assistant de code qui fait ce travail pour l’équipe.
5. Quelles extensions servent vraiment ? Faites la liste. Celles qui comptent existent-elles côté Astro, ou faudra-t-il les reconstruire ?

Si vos réponses penchent vers Astro, notre migration vers un site statique reprend chaque adresse pour qu’elle mène à sa page en un seul saut, installe un workflow d’IA qui permet à votre équipe de modifier le site en le demandant, et surveille la mise en ligne pendant quatorze jours, l’ancien site prêt à revenir. Avant de démarrer, nous vérifions avec vous, en 20 minutes, que c’est le bon chantier. Si elles penchent vers WordPress, gardez-le et soignez-le : près de la moitié des sites WordPress passent déjà les trois seuils de Google.

Questions fréquentes

Sources

1. Migrating from WordPress (nouvel onglet)docs.astro.build
2. HTTP Archive: Tech Report (nouvel onglet)httparchive.org
3. Roles and Capabilities (nouvel onglet)wordpress.org
4. Post Status (nouvel onglet)wordpress.org
5. Hardening WordPress (nouvel onglet)developer.wordpress.org
6. Multilingual WordPress (nouvel onglet)developer.wordpress.org
7. Internationalization (i18n) Routing (nouvel onglet)docs.astro.build
8. Headless WordPress & Astro (nouvel onglet)docs.astro.build
9. Cloudflare Acquires Astro to Accelerate the Future of High-Performance Web Development (nouvel onglet)cloudflare.com