Un site Astro statique pèse en moyenne 52 à 96 Ko par page HTML (CSS inclus), sans base de données ni exécution PHP à la requête, contre 1,5 à 3 Mo pour une page WordPress équivalente avec un thème comme Avada ou Elementor. Cet écart d’architecture se traduit directement en Core Web Vitals : moins de poids et moins de code exécuté côté serveur signifient mécaniquement un LCP plus rapide et un site plus stable.
Ce comparatif s’appuie sur des données mesurées, pas des estimations génériques : le poids de page Astro vient du build réel de ce site (digitalcorner.me), et le poids WordPress vient de l’ancien site sur lequel il a remplacé un thème Avada, avant sa refonte documentée dans Refonte WordPress vers Astro : la méthode complète en 6 étapes.
Le comparatif chiffré
| Critère | Astro (ce site) | WordPress/Avada (ancien site) |
|---|---|---|
| Poids d’une page HTML | 52 à 96 Ko, CSS inclus (moyenne ~63 Ko) | 1,5 à 3 Mo |
| Fichier CSS séparé à charger | Aucun (CSS inliné dans chaque page) | Généralement plusieurs (thème + page builder + plugins) |
| Bundle JS séparé | Aucun (les rares scripts sont inlinés, quelques lignes) | Plusieurs (thème, page builder, plugins actifs) |
| Base de données interrogée à chaque visite | Non : le site est pré-généré au build | Oui : requêtes MySQL à chaque chargement |
| Code exécuté côté serveur à chaque requête | Aucun (HTML statique servi tel quel) | PHP (WordPress core + thème + plugins) |
| Nombre de requêtes HTTP par page | Variable selon la page (quelques fichiers : polices, logos, images) | 20 et plus, généralement |
Pourquoi cet écart d’architecture change les Core Web Vitals
LCP (Largest Contentful Paint). Une page Astro est un fichier HTML déjà généré, envoyé tel quel par le serveur : pas de requête base de données, pas de rendu PHP à la volée avant de pouvoir répondre. Une page WordPress doit exécuter le thème, appeler les plugins actifs et interroger MySQL avant de produire le HTML final, ce qui ajoute du temps de réponse serveur (TTFB) avant même que le navigateur commence à afficher le contenu.
CLS (Cumulative Layout Shift). Moins de scripts tiers (page builders, plugins de tracking, widgets) signifie moins de décalages de mise en page pendant le chargement. Un site avec peu de dépendances JavaScript externes a structurellement moins d’occasions de provoquer un CLS élevé.
INP (Interaction to Next Paint). Un site avec peu ou pas de JavaScript exécuté au chargement laisse le thread principal du navigateur disponible pour répondre immédiatement aux interactions, plutôt que de le partager avec le code d’un page builder ou de plusieurs plugins actifs simultanément.
Ce que ce comparatif ne dit pas
Un poids de page plus faible et une architecture plus simple ne garantissent pas à eux seuls un score Lighthouse parfait : des images mal optimisées, une police mal chargée ou un excès d’animations peuvent dégrader les Core Web Vitals sur n’importe quelle architecture, Astro compris. La légèreté structurelle est un avantage de départ, pas un résultat automatique : elle facilite l’optimisation, elle ne la remplace pas.
Ce comparatif ne signifie pas non plus qu’Astro est la bonne réponse pour tous les sites. Un site avec un espace membre complexe, une boutique WooCommerce avec beaucoup de logique métier, ou une équipe qui publie elle-même au quotidien sans passer par Git garde tout intérêt à rester sur WordPress bien optimisé. Le détail de ce choix est développé dans l’article sur la méthode de refonte WordPress vers Astro.
Questions fréquentes
Astro est-il toujours plus rapide que WordPress ?
Structurellement, une page Astro statique part avec un avantage (pas de base de données ni de PHP à exécuter par requête). Mais un WordPress bien optimisé (cache serveur, images compressées, thème léger, peu de plugins) peut obtenir de bons Core Web Vitals, et à l’inverse un site Astro mal construit (images lourdes, scripts tiers mal chargés) peut sous-performer. L’architecture facilite la performance, elle ne la garantit pas.
Quel est le vrai gain en Core Web Vitals, en chiffres ?
Ce comparatif documente le poids de page et le nombre de requêtes, deux facteurs qui influencent directement le LCP et le TTFB. Les scores Lighthouse précis dépendent aussi de l’hébergement, du CDN et du contenu de chaque page : ils se mesurent site par site plutôt que de s’annoncer en général.
WordPress peut-il atteindre un poids de page comparable à Astro ?
Rarement au même niveau, car une page WordPress charge toujours au minimum le cœur WordPress, la base de données et le thème actif, même bien optimisés. Un WordPress minimaliste (thème léger, peu de plugins, cache agressif) peut néanmoins se rapprocher significativement des standards de performance actuels.
Faut-il migrer son site WordPress vers Astro pour améliorer ses Core Web Vitals ?
Pas systématiquement. Si le site a surtout besoin de vitesse et de fiabilité sans fonctionnalités dynamiques complexes, la migration a du sens. Si un audit montre que le problème vient de la configuration WordPress plutôt que de son architecture, l’optimiser sur place est souvent plus rapide et moins coûteux. Un audit gratuit permet de trancher selon votre situation.
Vous voulez évaluer votre propre situation ?
Je peux auditer gratuitement votre site actuel et vous dire si une refonte vers Astro a du sens, ou si WordPress bien optimisé reste le bon choix pour votre projet.
Un projet en tête ? Discutons-en.
Me contacter