Astro vs WordPress : la différence de performance, mesurée sur un site réel

J’ai construit des sites WordPress pendant quinze ans. J’en construis encore, et certains de mes clients n’ont aucune raison d’en changer. Mais ce mois-ci, j’ai livré un site fait entièrement avec Astro, et les chiffres méritent qu’on s’y arrête — pas les chiffres d’un benchmark de laboratoire, ceux d’un site en production, mesurés par PageSpeed Insights sur une émulation de téléphone d’entrée de gamme en 4G lente.

Desktop : 100/100. Mobile : 98/100, avec un First Contentful Paint à 1,1 seconde et un Largest Contentful Paint à 1,2 seconde. Pour situer, un WordPress soigné — bon hébergement, cache serveur, images optimisées — tourne typiquement entre 60 et 85 sur mobile, et il faut un travail d’optimisation continu pour l’y maintenir. Ici, le score élevé est l’état par défaut, et c’est toute la différence.

Pourquoi WordPress est structurellement plus lent

Ce n’est pas une question de qualité de code ou de compétence. C’est architectural. À chaque visite, WordPress exécute du PHP, interroge une base de données, assemble la page à travers un thème et une pile de plugins qui injectent chacun leur CSS et leur JavaScript — puis un plugin de cache tente de neutraliser tout ce travail en servant une copie figée. On fabrique de la lenteur, puis on achète un outil pour la cacher.

Un builder visuel aggrave le bilan : Elementor, Divi ou Oxygen produisent un balisage profond et chargent une couche de scripts dont la page n’a souvent pas besoin. Ajoutez une police servie par un domaine tiers, un slider, un plugin de formulaire, et le téléphone de votre visiteur télécharge plusieurs centaines de kilooctets de JavaScript avant d’afficher un titre.

Astro prend le problème à l’envers. Le site est généré à l’avance, au moment du build : ce qui arrive chez le visiteur est du HTML et du CSS déjà prêts, servis depuis un CDN. Et surtout, Astro n’envoie aucun JavaScript par défaut. Quand une page a besoin d’interactivité — un formulaire intelligent, un widget — seul ce composant-là embarque son script, et on choisit même le moment où il se charge : immédiatement, quand le navigateur est disponible, ou quand le composant devient visible à l’écran. Le reste de la page reste inerte, donc instantané.

Ce que les chiffres disent vraiment

Je dois être honnête sur un point, parce que c’est là que l’histoire devient utile : le matin même, ce site Astro affichait 74 sur mobile. Pas 98. Astro ne dispense pas des fondamentaux du web — il rend juste leur correction rapide et définitive.

Les trois causes du 74 : des polices chargées depuis un domaine tiers via un @import CSS (une chaîne de requêtes critique de près de 800 millisecondes à elle seule), un logo de 1 614 pixels affiché en 180 pixels (116 Ko pour une vignette), et un composant interactif qui s’hydratait dès le chargement alors qu’il se trouve sous la ligne de flottaison. Trois corrections — polices auto-hébergées et préchargées, image redimensionnée, hydratation différée à la visibilité — et le score est passé de 74 à 98 dans l’après-midi.

Voilà la vraie différence avec WordPress, et elle est plus intéressante qu’un simple écart de score : sur un site statique, une optimisation est un acquis. Personne ne viendra la défaire. Sur WordPress, le score de performance est un équilibre instable — la prochaine mise à jour de plugin, le prochain script ajouté par une extension marketing, le prochain champ du builder peut le dégrader silencieusement. J’ai audité assez de Search Console pour savoir que ces régressions silencieuses sont la norme, pas l’exception.

Là où WordPress reste le bon choix

Si je m’arrêtais ici, cet article serait malhonnête. WordPress a une qualité qu’aucun générateur de site statique n’égale nativement : n’importe qui peut se connecter, écrire un article, remplacer une photo, publier — sans développeur, sans Git, sans build. Pour un restaurant qui change sa carte, un hôtel qui gère ses offres saisonnières, une équipe qui publie trois articles par semaine, cette autonomie éditoriale vaut plus que vingt points de PageSpeed. Une boutique WooCommerce avec ses moyens de paiement, ses transporteurs et sa comptabilité connectée ne se réécrit pas non plus en statique d’un claquement de doigts.

La question n’est donc pas « Astro ou WordPress ». C’est : qui écrit le contenu, à quelle fréquence, et qui a le droit de ralentir le site ?

Le meilleur des deux : WordPress en coulisses, Astro en façade

C’est la partie que peu de gens réalisent : les deux se combinent. WordPress peut fonctionner en « headless » — il reste l’interface d’administration où l’on rédige, mais il ne rend plus aucune page. Au moment du build, Astro interroge WordPress via son API (REST ou GraphQL), récupère articles et pages, et génère le site statique. Le rédacteur garde son éditeur familier ; le visiteur reçoit du HTML pur depuis un CDN. WordPress peut même vivre sur un sous-domaine fermé au public, invisible et inattaquable — ce qui règle au passage une bonne partie des problèmes de sécurité et de maintenance qui font le quotidien des sites WP exposés.

Et si l’on n’a pas besoin de WordPress du tout, il existe des interfaces d’édition conçues pour les sites statiques : des outils comme Keystatic, Tina ou Decap offrent un back-office visuel qui écrit directement dans les fichiers du projet. L’éditeur clique sur « Publier », le site se reconstruit, et il n’y a ni base de données, ni PHP, ni plugin à maintenir nulle part.

Ce site que vous lisez est lui-même un ancien WordPress migré vers Astro, sur le même domaine, sans perdre son historique de référencement. Cet article est le premier écrit directement dans la nouvelle architecture — les précédents viennent de l’import. La transition n’oblige à rien de brutal : on peut migrer la vitrine et garder l’éditorial, ou l’inverse.

Ce qu’il faut en retenir

Un site vitrine dont le contenu bouge quelques fois par an n’a plus de raison technique d’être un WordPress complet : le statique est plus rapide, plus sûr, moins cher à héberger et sans maintenance. Un site à forte vie éditoriale mérite une vraie interface de rédaction — WordPress headless ou CMS Git — branchée sur un rendu statique. Et un WordPress classique reste défendable quand l’écosystème de plugins fait le travail métier et que l’équipe en dépend au quotidien.

Les 98/100 ne sont pas l’exploit d’un développeur : c’est le comportement normal d’une architecture qui n’envoie au visiteur que ce dont il a besoin. Le reste est une question de choix d’outillage — et ce choix se fait projet par projet, pas par religion.