Votre agence prêche la performance, mais votre propre site WordPress traîne. Le nôtre aussi — 3,2 secondes avant interaction, Lighthouse bloqué à 58, une pile de plugins que nous avions peur de mettre à jour. Chaque démo client signifiait ouvrir les devtools sur leur site statique ultra-rapide, en espérant qu'ils ne nous demandent pas de montrer le nôtre. Nous sommes socialanimal.dev — nous construisons des expériences Next.js et Astro sub-secondes pour les marques SaaS. Nous avons donc reconstruit notre site en Astro, supprimé entièrement WordPress, et atteint des 100 parfaits dans chaque catégorie Lighthouse. Le Time to Interactive est passé à 0,4 secondes. Taille totale du bundle : 47 KB. Pas de plugins, pas de requêtes de base de données, pas de gêne.

Nous avons donc démonté tout et 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. C'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 vers Astro : Comment nous avons atteint Lighthouse 100 lors de notre refonte

Pourquoi nous avons quitté WordPress

Écoutez, WordPress alimente environ 43 % du web. Ce n'est pas une mauvaise plateforme. Nous avons construit beaucoup de 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 majoritairement statique avec un blog — WordPress était excessif de la pire façon.

Voici à quoi ressemblait notre configuration WordPress :

  • Thème : Thème personnalisé basé 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 la construction : Templating PHP, Webpack pour les assets, base de données MySQL

Même avec WP Rocket faisant de la mise en cache agressive, nos Core Web Vitals étaient médiocres. Le Largest Contentful Paint (LCP) était de 2,4 secondes sur mobile. 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 se casse.

Le vrai problème ? Nous payions 80 $/mois en frais d'hébergement 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 brochure avec un blog.

Le point de rupture

La goutte d'eau a été en janvier 2025. Une mise à jour du noyau WordPress a cassé nos blocs Gutenberg personnalisés. La correction a nécessité de mettre à jour ACF Pro, ce qui a nécessité de mettre à jour la compatibilité de version PHP du thème, ce qui a nécessité de mettre à jour 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 pas suivre notre propre conseil ? »

Pourquoi nous avons choisi Astro

Nous avons évalué quatre options pour la refonte :

Framework Avantages Inconvénients Notre avis
Next.js Nous le connaissons bien, excellent écosystème Excessif pour un site de contenu, nécessite un serveur ou un runtime edge Trop lourd
Astro Axé sur le contenu, expédie zéro JS par défaut, architecture en î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 ultra-rapides, binaire unique Les templates Go sont pénibles, flexibilité limitée Pas pour nous

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

La philosophie d'Astro nous a séduits : expédier du HTML, ajouter du JavaScript seulement où vous en avez besoin. Son architecture en îles signifie que vous pouvez avoir un composant React complètement interactif à côté du HTML complètement statique, et les parties statiques expédient zéro JavaScript. C'est exactement ce qu'il nous fallait.

Nous avions aussi fait beaucoup plus de travail de développement Astro pour les clients au cours des dernières années, donc l'équipe était à l'aise avec le framework. Ce n'était pas un exercice d'apprentissage — c'était un outil en lequel 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 headless pour notre propre site. Pour les projets clients, nous recommandons souvent des configurations headless CMS avec Contentful, Sanity ou Storyblok. Mais pour notre blog, où chaque auteur est un développeur à l'aise avec Markdown et Git ? Content Collections dans Astro avec des fichiers MDX validés dans le repo était plus simple et plus rapide.

Pas d'appels API au moment de la construction. Pas de réseau de distribution de contenu pour le contenu. Pas de 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 big-bang. Voici notre approche par phases :

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

Phase 2 : Système de conception en 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 tant que fichiers .astro. Aucun framework nécessaire pour aucun d'entre eux. HTML et CSS purs avec des styles limités.

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

Phase 4 : Réglage des performances (1 semaine) C'est là que le travail Lighthouse 100 s'est vraiment déroulé. Plus de détails ci-dessous.

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

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

WordPress vers Astro : Comment nous avons atteint Lighthouse 100 lors de notre refonte - architecture

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

Zéro JavaScript par défaut

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

Voici notre navigation 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">Basculer le menu</span>
  <svg><!-- icône hamburger --></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>

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

Stratégie CSS : Styles limités + Une couche globale minimale

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

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

/* 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, rendant 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',
  },
});

Optimisations de performance - Analyse approfondie

Atteindre Lighthouse 100 n'est pas seulement une question de choisir le bon framework. Astro vous donne une longueur d'avance, 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 automatique de format (WebP/AVIF), chargement paresseux, et les attributs width/height appropriés pour prévenir CLS.

---
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.jpg';
---
<Image 
  src={heroImage} 
  alt="Équipe de développement Social Animal travaillant sur une architecture headless"
  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 hero en particulier, nous utilisons loading="eager" puisqu'elle est au-dessus de la ligne de flottaison. Tout le reste obtient loading="lazy" par défaut.

Nous avons aussi examiné chaque image du site et nous avons demandé : « Cette image a-t-elle vraiment besoin d'être une image ? » Plusieurs éléments décoratifs sont devenus des gradients CSS ou des SVG à la place. Le fond de notre section hero, par exemple, est un dégradé CSS avec une texture de bruit subtile appliquée via un petit SVG en ligne.

Stratégie de chargement de polices

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

  1. Auto-héberger tout. 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 à fonts.googleapis.com.

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

  3. Utiliser font-display: swap avec une police de secours système soigneusement choisie qui correspond bien aux métriques, minimisant le décalage de mise en page lors de l'échange.

  4. Précharger les fichiers de polices 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 migré de WP Engine (60 $/mois) à Cloudflare Pages (niveau gratuit). Oui, gratuit. Notre site se situe bien dans les limites du plan gratuit de Cloudflare — 500 builds par mois, bande passante illimitée, demandes illimitées.

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

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

Incorporation de CSS critique

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

Discipline des scripts tiers

C'est là où la plupart des sites perdent leurs scores parfaits. Chaque script tiers est un désastre potentiel de performance. Nous avons impitoyablement limité les nôtres :

  • Analytics : Migré de Google Analytics (70 KB+ de JavaScript) vers Plausible Analytics (< 1 KB de script, chargé en asynchrone). 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. Pas de bibliothèque de formulaires JavaScript.
  • Pas de widgets de chat. Pas d'intégrations de médias sociaux. Pas de bannières de consentement de cookies (nous n'utilisons pas de cookies qui nécessitent un consentement).

Le classement 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,6s
Largest Contentful Paint 0,8s
Total Blocking Time 0ms
Cumulative Layout Shift 0
Speed Index 0,8s

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

Avant et après : Les chiffres

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

La réduction du poids des pages est stupéfiante même pour nous. 1,8 MB à 142 KB. 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 quatorze feuilles de style de plugins.

Ce que nous avons mal fait en chemin

Ce n'était pas tout lisse. Moment d'honnêteté.

Erreur 1 : Nous avions presque trop compliqué la gestion de contenu

Notre premier instinct était de configurer Sanity comme CMS headless pour le blog. Nous avons passé deux jours à configurer des schémas et à mettre en place Sanity Studio avant de reculer et de nous demander : « Qui va réellement utiliser cela ? » La réponse était... nous. Les développeurs. Qui sont parfaitement contents d'écrire MDX dans VS Code. Nous avons retiré Sanity et opté pour les Content Collections d'Astro. Économies de coûts permanents et réduction de la complexité.

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

Notre sous-ensemble de police initial était trop agressif. Nous avons supprimé les caractères que nous pensions ne jamais utiliser, puis avons publié un article de blog avec un tiret cadratin et quelques guillemets typographiques qui se sont affichés sous forme de carrés. 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, il affichait un fallback générique. Nous avons dû revenir 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 le scope original.

Erreur 4 : La carte de redirection 301 avait des lacunes

Malgré l'utilisation de Screaming Frog pour cartographier les anciennes URL, nous en avons manqué quelques-unes dont des sites externes pointaient des hotlinks. Nous avons détecté celles-ci dans les analyses de Cloudflare environ une semaine après le lancement et avons ajouté les redirections manquantes. Vérifiez toujours vos journaux de serveur après une migration — Google Search Console ne captera pas tout.

Leçons pour votre propre migration

Si vous envisagez de passer de WordPress à un framework axé sur le statique, voici ce que je vous dirais :

  1. Faites un audit avant de migrer. Tuez le contenu qui ne fonctionne pas bien. Une migration est une excellente opportunité de nettoyer.

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

  3. Ne reproduisez pas votre ancienne architecture. Nous n'avons pas essayé de répliquer notre configuration WordPress dans Astro. Nous avons repensé tout à partir de zéro. Avons-nous réellement besoin d'un plugin de formulaire ? Non, un élément <form> avec une fonction serverless fonctionne bien.

  4. Mesurez avant, mesurez après, mesurez continuellement. Nous avons configuré un job Lighthouse CI dans GitHub Actions qui s'exécute à chaque pull request. Si une PR réduit un score en dessous de 95, la vérification échoue.

  5. **Budgétisez les « 5 derniers pourcents ». ** Passer de Lighthouse 85 à 95 est simple. Passer de 95 à 100 nécessite un sous-ensemble de polices, une analyse CSS critique, une optimisation du format d'image, et un audit des scripts tiers. Prévoyez du temps pour cela.

  6. Vos coûts d'hébergement devraient embarrasser 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 une marchandise maintenant.

Si vous êtes intéressé par ce à quoi ressemblerait une migration comme celle-ci pour votre projet, consultez notre page de tarification ou contactez-nous. Nous avons effectué ce chemin de migration pour plusieurs clients maintenant, et les améliorations de performance sont constamment spectaculaires.

FAQ

Combien de temps faut-il pour migrer un site WordPress vers Astro ?

Pour notre site (environ 50 pages incluant les articles 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 publication 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 atteindre Lighthouse 100 avec Next.js à la place d'Astro ?

C'est possible mais significativement 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 en rapprocher — des scores de 95-99 sont réalisables avec une optimisation soignée. Mais l'approche zéro-JS-par-défaut d'Astro rend les scores parfaits beaucoup plus réalisables 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 des formulaires HTML simples et un backend de fonction serverless (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 expédie seulement 5 KB de JavaScript. C'est rapide et fonctionne hors ligne.

La migration de WordPress vers Astro fait-elle du mal au SEO ?

Non si vous la gérez correctement. Nous avons configuré des redirections 301 pour chaque URL, préservé notre structure d'URL où possible, soumis une nouvelle sitemap, et maintenu 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 surtout du spam sur WordPress de toute façon. Si vous avez besoin de commentaires, des 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, donc ils n'affectent pas le chargement initial de la page.

Astro est-il prêt pour la production sur les grands sites ?

Absolument. Astro 5.x (lancé fin 2024) est mature et stable. Des entreprises comme Porsche, Google, Microsoft et Netlify l'utilisent en production. La performance de la construction s'adapte aussi bien — les sites avec des milliers de pages se construisent en moins d'une minute avec la bonne configuration.

Quel est l'entretien permanent comparé à WordPress ?

Dramatiquement moins. Pas de mises à jour de plugins, pas de maintenance 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 les PRs de Dependabot. Chaque mise à jour prend environ 5 minutes à réviser et fusionner. Comparez cela avec le tapis roulant de mise à jour de 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 workflows Git de base. Pour les équipes avec des éditeurs non techniques, nous recommandons d'associer Astro à un CMS headless comme Sanity, Contentful ou Storyblok. Les éditeurs obtiennent une interface visuelle, et vous obtenez quand même tous les avantages de performance de la génération statique.