WordPress to Astro : Comment nous avons obtenu Lighthouse 100 lors de notre refonte

Soyons honnêtes : notre ancien site WordPress était embarrassant. Non pas parce qu'il avait mauvaise allure — il était en fait assez décent. Mais sous le capot ? Un temps d'interaction de 3,2 secondes, un score de performance Lighthouse autour de 58, et une pile de plugins qui rendait chaque déploiement aussi stressant que de désamorcer une bombe. Nous sommes une agence de développement web. Nous construisons des sites rapides pour les clients. Et notre propre site était... pas rapide.

Nous avons donc tout reconstruit avec Astro. Le résultat : des 100 parfaits dans les quatre catégories Lighthouse — Performance, Accessibilité, Bonnes pratiques et SEO. Pas sur une seule page. Sur chaque page. Ceci est l'histoire de comment nous y sommes arrivés, ce qui s'est cassé en chemin, et ce que nous ferions différemment.

Table des matières

WordPress to Astro: How We Hit Lighthouse 100 on Our Rebuild

Pourquoi nous avons quitté WordPress

Voyons les choses en face, WordPress alimente environ 43 % du web. Ce n'est pas une mauvaise plateforme. Nous avons construit de nombreux sites WordPress pour des clients et continuerons à le faire quand c'est le bon choix. Mais pour notre propre site d'agence — un site marketing essentiellement statique avec un blog — WordPress était un overkill de la pire façon.

Voici à quoi ressemblait notre configuration WordPress :

  • Thème : Thème personnalisé construit sur Sage (Roots.io)
  • Plugins : 14 plugins actifs incluant Yoast SEO, WP Rocket, Advanced Custom Fields Pro, Gravity Forms, et quelques autres
  • Hébergement : Plan WP Engine Professional à 60 $/mois
  • CDN : Cloudflare Pro à 20 $/mois
  • Complexité de construction : Templating PHP, Webpack pour les assets, base de données MySQL

Même avec WP Rocket effectuant un cache agressif, nos Core Web Vitals étaient médiocres. Le Largest Contentful Paint (LCP) était de 2,4 secondes sur mobile. Le Cumulative Layout Shift (CLS) était de 0,12 — pas terrible, mais pas bon. Et chaque fois que nous mettions à jour un plugin, il y avait une chance non nulle que quelque chose casse.

Le vrai problème ? Nous payions 80 $/mois pour un site qui recevait peut-être 3 000 visites par mois. Ce n'est pas beaucoup de trafic, et c'est beaucoup d'argent pour ce qui était essentiellement un site de brochure avec un blog.

Le point de rupture

Le coup final est venu en janvier 2025. Une mise à jour du noyau WordPress a cassé nos blocs Gutenberg personnalisés. La correction a nécessité la mise à jour d'ACF Pro, ce qui a nécessité la mise à jour de la compatibilité de version PHP du thème, ce qui a nécessité la mise à jour de l'environnement d'hébergement. Ce qui aurait dû être une mise à jour de routine s'est transformé en une journée complète de travail.

J'ai regardé notre équipe et j'ai dit : « Nous disons aux clients d'aller sans tête. Pourquoi ne mangeons-nous pas notre propre nourriture ? »

Pourquoi nous avons choisi Astro

Nous avons évalué quatre options pour la refonte :

Framework Avantages Inconvénients Notre verdict
Next.js Nous le connaissons bien, excellent écosystème Overkill pour un site de contenu, nécessite un serveur ou un runtime edge Trop lourd
Astro Centré sur le contenu, zéro JS par défaut, architecture d'îles Écosystème plus petit, plus récent Parfait
Eleventy Simple, builds rapides, mature Modèle de composant limité, DX moins moderne Deuxième choix
Hugo Builds éclair, binaire unique Templating Go douloureux, flexibilité limitée Pas pour nous

Nous construisons beaucoup de projets Next.js pour les clients, et c'est notre valeur par défaut pour tout ce qui a une fonctionnalité dynamique. Mais pour un site marketing riche en contenu ? Next.js envoie un runtime JavaScript au navigateur que vous en ayez besoin ou non. Même avec l'export statique, vous envoyez React au navigateur.

La philosophie d'Astro a résomné en nous : livrez du HTML, ajoutez du JavaScript uniquement là où vous en avez besoin. Leur architecture d'îles signifie que vous pouvez avoir un composant React entièrement interactif assis à côté du HTML complètement statique, et les parties statiques expédient zéro JavaScript. C'est exactement ce dont nous avions besoin.

Nous avions également fait plus de travail de développement Astro pour les clients tout au long de 2024, donc l'équipe était à l'aise avec le framework. Ce n'était pas un exercice d'apprentissage — c'était un outil auquel nous faisions déjà confiance.

La question de la couche contenu

Une décision que nous avons prise tôt : nous n'allions pas utiliser un CMS sans tête pour notre propre site. Pour les projets clients, nous recommandons souvent des configurations CMS sans tête avec Contentful, Sanity, ou Storyblok. Mais pour notre blog, où chaque auteur est un développeur à l'aise avec Markdown et Git ? Les Content Collections dans Astro avec les fichiers MDX validés dans le repo était plus simple et plus rapide.

Aucun appel API au moment de la construction. Aucun réseau de distribution de contenu pour le contenu. Aucun service supplémentaire à gérer ou payer. Juste des fichiers dans un dossier.

La stratégie de migration

Nous n'avons pas fait une migration en une seule fois. Voici notre approche progressive :

Phase 1 : Audit de contenu (1 semaine) Nous avons exporté tout le contenu WordPress en utilisant wp-cli et converti les messages en MDX en utilisant un script personnalisé construit avec turndown (convertisseur HTML-vers-Markdown) plus un peu de nettoyage regex. Nous avions 47 billets de blog à l'époque. Environ 12 d'entre eux étaient obsolètes ou peu performants, nous les avons donc redirigés vers le contenu nouveau pertinent et ne les avons pas migrés.

Phase 2 : Système de conception dans Astro (2 semaines) Nous avons reconstruit notre bibliothèque de composants en tant que composants Astro. Boutons, cartes, mises en page de sections, navigation — tout en fichiers .astro. Aucun framework nécessaire pour l'un d'eux. HTML et CSS purs avec des styles portée.

Phase 3 : Construction de pages (2 semaines) Page d'accueil, pages de capacités, à propos, contact, listing de blog, billets de blog individuels, 404. Nous les avons tous construits en tant que pages Astro avec notre bibliothèque de composants.

Phase 4 : Ajustement de la performance (1 semaine) C'est là que le travail Lighthouse 100 s'est vraiment produit. Plus à ce sujet ci-dessous.

Phase 5 : Lancement et redirection (2 jours) Nous avons configuré des redirections 301 appropriées pour chaque ancienne URL, vérifié avec Screaming Frog que rien n'était cassé, soumis la nouvelle carte du site à Google Search Console, et basculé DNS.

Chronologie totale : environ 6 semaines de travail à temps partiel aux côtés des projets clients.

WordPress to Astro: How We Hit Lighthouse 100 on Our Rebuild - architecture

Les décisions architecturales qui ont fait la différence

Zéro JavaScript par défaut

Notre site entier expédie environ 2 Ko de JavaScript au total. Ce n'est pas une coquille. Deux kilooctets. Et la plupart de cela est un petit script pour le basculement de navigation mobile et l'analyse.

Voici notre nav mobile — pas de framework, pas de dépendances :

---
// MobileNav.astro
---
<button id="menu-toggle" aria-expanded="false" aria-controls="mobile-menu">
  <span class="sr-only">Toggle menu</span>
  <svg><!-- hamburger icon --></svg>
</button>
<nav id="mobile-menu" hidden>
  <slot />
</nav>

<script>
  const toggle = document.getElementById('menu-toggle');
  const menu = document.getElementById('mobile-menu');
  
  toggle?.addEventListener('click', () => {
    const expanded = toggle.getAttribute('aria-expanded') === 'true';
    toggle.setAttribute('aria-expanded', String(!expanded));
    menu?.toggleAttribute('hidden');
  });
</script>

Cette balise <script> dans un composant Astro est automatiquement regroupée et dédupliquée. C'est minuscule, c'est du JavaScript vanilla, et ça fonctionne partout.

Stratégie CSS : Styles portée + une couche globale minimale

Nous avons utilisé le CSS portée intégré d'Astro pour les styles au niveau des composants et une seule feuille de style globale (environ 8 Ko minifiée) pour la typographie, la réinitialisation, les propriétés personnalisées et les classes utilitaires. Pas de Tailwind. C'est une prise controversée, je sais.

Nous aimons Tailwind pour les applications plus grandes et les projets clients. Mais pour un site si petit, il a ajouté une complexité de construction et une taille de fichier dont nous n'avions pas besoin. Notre CSS écrit à la main est plus petit que ce que la sortie de Tailwind aurait été, même avec purge.

/* Propriétés personnalisées globales */
:root {
  --color-text: #1a1a2e;
  --color-bg: #ffffff;
  --color-accent: #e94560;
  --color-accent-dark: #c81e45;
  --font-body: 'Inter', system-ui, sans-serif;
  --font-heading: 'Cal Sans', var(--font-body);
  --max-width: 72rem;
  --space-unit: 0.25rem;
}

Génération statique avec préchargement intelligent

Chaque page est générée statiquement au moment de la construction. Nous utilisons l'intégration prefetch intégrée d'Astro pour précharger les liens au survol, ce qui rend la navigation instantanée :

// astro.config.mjs
import { defineConfig } from 'astro/config';
import mdx from '@astrojs/mdx';
import sitemap from '@astrojs/sitemap';

export default defineConfig({
  site: 'https://socialanimal.dev',
  integrations: [mdx(), sitemap()],
  prefetch: {
    prefetchAll: false,
    defaultStrategy: 'hover',
  },
  build: {
    inlineStylesheets: 'auto',
  },
});

Plongée approfondie dans les optimisations de performance

Arriver à Lighthouse 100 ne consiste pas seulement à choisir le bon framework. Astro vous donne un coup de pouce, mais les 10-15 derniers points nécessitent des efforts délibérés. Voici ce que nous avons fait.

Optimisation des images

Le composant <Image /> intégré d'Astro gère les images réactives avec conversion de format automatique (WebP/AVIF), chargement différé et attributs width/height appropriés pour éviter CLS.

---
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.jpg';
---
<Image 
  src={heroImage} 
  alt="Social Animal development team working on headless architecture"
  widths={[400, 800, 1200]}
  sizes="(max-width: 600px) 400px, (max-width: 900px) 800px, 1200px"
  format="avif"
  fallbackFormat="webp"
  quality={80}
  loading="eager"
/>

Pour l'image héroïque en particulier, nous utilisons loading="eager" puisqu'elle est au-dessus du pli. Tout le reste obtient loading="lazy" par défaut.

Nous avons également parcouru chaque image sur le site et nous nous sommes demandé : « Cela doit-il être une image ? » Plusieurs éléments décoratifs sont devenus des dégradés CSS ou des SVG à la place. Le fond de notre section héroïque, par exemple, est un dégradé CSS avec une texture de bruit subtile appliquée via un tiny SVG en ligne.

Stratégie de chargement des polices

Les polices sont un tueur de Lighthouse. Voici notre approche :

  1. Hébergez tout vous-même. Pas de Google Fonts CDN. Nous avons téléchargé Inter et Cal Sans et les servons depuis notre propre domaine. Cela élimine une recherche DNS, une connexion TCP et une poignée de main TLS vers fonts.googleapis.com.

  2. Sous-ensemble agressivement. Nous avons utilisé glyphhanger pour analyser les caractères que nous utilisons réellement, puis avons créé un sous-ensemble de nos polices avec pyftsubset. Notre Inter Regular WOFF2 est passé de 96 Ko à 18 Ko.

  3. Utilisez font-display: swap avec une police de remplacement système attentivement choisie qui correspond étroitement aux métriques, minimisant le changement de mise en page lors du swap.

  4. Préchargez les fichiers de police critiques :

<link rel="preload" href="/fonts/inter-latin-400.woff2" as="font" type="font/woff2" crossorigin />
<link rel="preload" href="/fonts/cal-sans-latin-600.woff2" as="font" type="font/woff2" crossorigin />

Hébergement : Cloudflare Pages

Nous avons déménagé de WP Engine (60 $/mois) vers Cloudflare Pages (plan gratuit). Oui, gratuit. Notre site se situe bien dans les limites du plan gratuit de Cloudflare — 500 constructions par mois, bande passante illimitée, requêtes illimitées.

Cloudflare Pages se déploie à partir d'une poussée Git, sert depuis leur réseau edge mondial, et gère automatiquement les en-têtes de cache. Les temps de construction font en moyenne 22 secondes pour notre site entier. Comparez cela à notre configuration WordPress où une simple purge de cache pouvait prendre plus de temps.

Le coût mensuel d'hébergement est passé de 80 $ à 0 $.

Inlining CSS critique

Astro intègre automatiquement les petites feuilles de style lorsque vous définissez build.inlineStylesheets: 'auto'. Pour nos pages, chaque style critique est intégré dans le <head>, ce qui signifie qu'il n'y a pas de requêtes CSS bloquant le rendu. Le navigateur peut commencer à peindre immédiatement.

Discipline des scripts tiers

C'est là que la plupart des sites perdent leurs scores parfaits. Chaque script tiers est un désastre potentiel de performance. Nous en avons impitoyablement limité :

  • Analytics : Passé de Google Analytics (70 Ko+ de JavaScript) à Plausible Analytics (< 1 Ko script, chargé en async). Nous payons 9 $/mois pour Plausible, et la qualité des données est honnêtement meilleure pour nos besoins.
  • Formulaires : Notre formulaire de contact à /contact utilise un simple formulaire HTML avec gestion côté serveur via Cloudflare Pages Functions. Aucune bibliothèque de formulaires JavaScript.
  • Pas de widgets de chat. Pas d'intégrations de réseaux sociaux. Pas de bannières de consentement aux cookies (nous n'utilisons pas de cookies nécessitant le consentement).

Le tableau de bord Lighthouse 100

Voici nos scores Lighthouse réels en mai 2025, mesurés à l'aide de Chrome DevTools sur une connexion limitée (simulation mobile par défaut de Lighthouse) :

Métrique Score
Performance 100
Accessibilité 100
Bonnes pratiques 100
SEO 100
First Contentful Paint 0,6 s
Largest Contentful Paint 0,8 s
Total Blocking Time 0 ms
Cumulative Layout Shift 0
Speed Index 0,8 s

Le Total Blocking Time de 0 ms est ma statistique préférée. Zéro. Il n'y a essentiellement pas de JavaScript bloquant le fil principal. Jamais.

Avant et après : les chiffres

Métrique WordPress (Avant) Astro (Après) Amélioration
Lighthouse Performance 58 100 +72 %
LCP (mobile) 2,4 s 0,8 s 3x plus rapide
CLS 0,12 0 Éliminé
TBT 380 ms 0 ms Éliminé
Poids de la page (accueil) 1,8 Mo 142 Ko 92 % plus petit
Requêtes HTTP 47 6 87 % moins
JavaScript expédié 340 Ko 2 Ko 99,4 % moins
Coût mensuel d'hébergement 80 $ 9 $ (Plausible seulement) 89 % moins cher
Temps de construction/déploiement 3-5 min 22 sec ~10x plus rapide
Time to First Byte 420 ms 18 ms 23x plus rapide

La réduction du poids des pages est stupéfiante même pour nous. 1,8 Mo réduit à 142 Ko. C'est ce qui se passe quand vous arrêtez d'expédier jQuery, React, le chargeur de scripts de WP Rocket, l'injecteur de schéma de Yoast et les quatorze feuilles de style de plugins.

Ce que nous avons fait mal en chemin

Ce n'était pas tout en douceur. Heure de l'honnêteté.

Erreur 1 : Nous avons presque surengénieurisé la gestion du contenu

Notre premier instinct a été de configurer Sanity comme un CMS sans tête pour le blog. Nous avons passé deux jours à configurer des schémas et à configurer Sanity Studio avant de nous arrêter et de nous demander : « Qui va réellement l'utiliser ? » La réponse a été... nous. Les développeurs. Qui sont parfaitement heureux d'écrire MDX dans VS Code. Nous avons ripped out Sanity et avons opté pour Astro Content Collections. Avons économisé les coûts continus et la complexité.

Erreur 2 : Le sous-ensemble de police a cassé les caractères spéciaux

Notre sous-ensemble initial était trop agressif. Nous avons dépouillé les caractères que nous pensions ne jamais utiliser, puis avons publié un billet de blog avec un tiret cadratin et quelques guillemets risqués qui se rendaient comme des boîtes. Leçon : testez vos sous-ensembles avec du contenu réel, pas seulement « ABCDEFG ».

Erreur 3 : Nous avons oublié les images OpenGraph

Nous avons lancé sans images OG dynamiques. Quand quelqu'un partageait un article de blog sur Twitter/X ou LinkedIn, cela montrait un fallback générique. Nous avons dû revenir en arrière et construire un pipeline de génération d'images OG en utilisant @astrojs/og (qui utilise Satori sous le capot). Aurait dû être dans la portée originale.

Erreur 4 : La carte de redirection 301 avait des lacunes

Malgré l'utilisation de Screaming Frog pour mapper les anciennes URL, nous avons manqué une poignée d'URL d'images sur lesquelles des sites externes créaient des liens directs. Nous avons attrapé ceux-ci dans l'analyse de Cloudflare environ une semaine après le lancement et nous avons ajouté les redirections manquantes. Vérifiez toujours les journaux de votre serveur après une migration — Google Search Console ne attrape pas tout.

Leçons pour votre propre migration

Si vous envisagez de passer de WordPress à un framework statique en premier, voici ce que je vous dirais :

  1. Auditez avant de migrer. Tuez le contenu qui ne fonctionne pas. Une migration est une excellente occasion de tailler.

  2. Faites correspondre l'outil au travail. Astro était parfait pour nous parce que nous sommes principalement du contenu. Si vous avez besoin d'une forte interactivité, Next.js ou un framework similaire pourrait être le meilleur choix.

  3. Ne faites pas de cargo-cult de votre ancienne architecture. Nous n'avons pas tenté de reproduire notre configuration WordPress dans Astro. Nous avons tout repensé à partir de zéro. Avons-nous vraiment besoin d'un plugin de formulaire ? Non, un élément <form> avec une fonction sans serveur fonctionne bien.

  4. Mesurez avant, mesurez après, mesurez continuellement. Nous avons mis en place une tâche Lighthouse CI dans GitHub Actions qui s'exécute à chaque demande de tirage. Si un PR baisse un score en dessous de 95, il échoue le contrôle.

  5. Budget pour le « dernier 5 % ». Passer de Lighthouse 85 à 95 est simple. Passer de 95 à 100 nécessite le sous-ensemble de police, l'analyse CSS critique, l'optimisation du format d'image et l'audit des scripts tiers. Planifiez le temps pour cela.

  6. Vos coûts d'hébergement devraient mettre à nu votre ancienne configuration. Si vous servez des fichiers statiques et payez toujours des frais d'hébergement importants, quelque chose ne va pas. L'hébergement statique est maintenant une commodité.

Si vous êtes intéressé par ce qu'une migration comme celle-ci ressemblerait pour votre projet, consultez notre page de tarification ou contactez-nous. Nous avons fait ce chemin de migration pour plusieurs clients maintenant, et les gains de performance sont régulièrement dramatiques.

FAQ

Combien de temps faut-il pour migrer un site WordPress vers Astro ? Pour notre site (environ 50 pages incluant des billets de blog), cela a pris environ 6 semaines de travail à temps partiel. Un site plus grand avec des centaines d'articles et des types de messages personnalisés complexes pourrait prendre 8-12 semaines. Le développement réel est généralement plus rapide que l'audit de contenu et la cartographie des redirections.

Pouvez-vous obtenir Lighthouse 100 avec Next.js au lieu d'Astro ? C'est possible mais considérablement plus difficile. Next.js expédie un runtime JavaScript au navigateur même pour les pages statiques (la couche d'hydratation React). Vous pouvez vous rapprocher — des scores de 95-99 sont réalisables avec une optimisation attentive. Mais l'approche zéro-JS-par-défaut d'Astro rend les scores parfaits beaucoup plus atteignables pour les sites de contenu.

Qu'en est-il des fonctionnalités WordPress comme les formulaires de contact et la recherche ? Les formulaires de contact fonctionnent bien avec les formulaires HTML simples et un backend de fonction sans serveur (Cloudflare Pages Functions, Netlify Functions, etc.). Pour la recherche, nous utilisons une recherche côté client avec Pagefind, qui construit un index de recherche au moment de la construction et ne libère que 5 Ko de JavaScript. C'est rapide et fonctionne hors ligne.

La migration de WordPress à Astro nuit-elle au SEO ? Non, si vous le gérez correctement. Nous avons configuré des redirections 301 pour chaque URL, conservé notre structure d'URL où possible, soumis une nouvelle carte du site et conservé toutes nos données structurées. Notre trafic organique a en fait augmenté de 23 % dans les trois mois suivant la migration, probablement en raison de l'amélioration des Core Web Vitals.

Comment gérez-vous le contenu dynamique comme les commentaires sur un site Astro ? Nous n'avons pas de commentaires sur notre blog — c'était principalement du spam sur WordPress de toute façon. Si vous avez besoin de commentaires, les services comme Giscus (basé sur GitHub Discussions) ou Hyvor Talk fonctionnent bien en tant que composants intégrés. Ils se chargent en tant qu'îles Astro, ils n'affectent donc pas le chargement initial de la page.

Astro est-il prêt pour la production pour les grands sites ? Absolument. Astro 5.x (sortie fin 2024) est mature et stable. Des entreprises comme Porsche, Google, Microsoft et Netlify l'utilisent en production. La performance de construction se met à l'échelle aussi bien — les sites avec des milliers de pages se construisent en moins d'une minute avec la bonne configuration.

Quel est l'entretien continu par rapport à WordPress ? Considérablement moins. Pas de mises à jour de plugins, pas d'entretien de base de données, pas de correctifs de sécurité pour PHP. Nous mettons à jour Astro et ses dépendances peut-être une fois par mois via des PR Dependabot. Chaque mise à jour prend environ 5 minutes pour vérifier et fusionner. Comparez cela au tapis roulant de mise à jour WordPress.

Les membres de l'équipe non techniques peuvent-ils toujours modifier le contenu sur un site Astro ? Avec notre configuration (fichiers MDX dans Git), vous devez être à l'aise avec Markdown et les flux de travail Git de base. Pour les équipes avec des éditeurs non techniques, nous recommandons d'associer Astro à un CMS sans tête comme Sanity, Contentful ou Storyblok. Les éditeurs obtiennent une interface visuelle, et vous obtenez toujours tous les avantages de performance de la génération statique.