Migrer 15 ans de WordPress vers Astro — et ce que cache un 100/100 Lighthouse

Le site que vous lisez vient de changer de moteur. Pendant quinze ans, one-day.fr a tourné sous WordPress ; il est désormais généré avec Astro 5 et servi depuis Cloudflare Pages. Il y a une forme de cohérence à ce que ce soit ce site, plutôt qu’un site client, qui raconte l’opération de bout en bout — avec les vrais chiffres, la vraie méthode, et les endroits où le résultat mérite d’être lu avec méfiance.

Parce que oui, l’histoire finit sur un 100/100 mobile et desktop. Mais si je m’arrêtais au score, je vous vendrais la même chose que tous les articles « WordPress vs Astro » du web — ceux qui migrent un site jouet de trois pages pour prouver un point déjà connu. Ce qui suit est l’inverse : une migration de quinze ans de contenu réel, avec un tri éditorial assumé, et une lecture critique de ce qu’un score parfait mesure vraiment.

Un point à poser d’emblée, parce qu’il court sous tout le reste : la stack n’était pas le problème. Elle était le plafond.

Le point de départ — un WordPress qui n’avait pas à rougir

Commençons par les scores avant, pour désamorcer le procès facile. Le WordPress de one-day.fr affichait 87 en performance desktop, 81 en mobile, 86 en accessibilité et 100 en SEO. Ce n’était pas une épave négligée : hébergement correct, cache serveur, images optimisées, thème entretenu. Le genre de WordPress que je livre à mes clients et que je défends encore aujourd’hui.

Et pourtant, il plafonnait. Les rapports le disaient sans ambiguïté : TBT (Total Blocking Time) à 210 ms sur desktop, LCP mobile à 3,7 s, Speed Index mobile à 5,6 s, 178 Kio de JavaScript inutilisé, et un budget de requêtes bloquant le rendu estimé à 1 740 ms sur mobile. Aucune de ces valeurs n’est le signe d’un travail bâclé. C’est le coût structurel d’un thème et d’une pile de plugins : chacun injecte son CSS et son JavaScript, et même parfaitement réglé, l’ensemble reste lourd. On peut optimiser un WordPress pendant des jours ; on ne le fait pas descendre en dessous du plancher que son architecture impose.

Une curiosité au passage, que je signale sans la surinterpréter : le TBT était plus élevé sur desktop (210 ms) que sur mobile (60 ms). Contre-intuitif, puisqu’un téléphone d’entrée de gamme est censé souffrir davantage. L’explication la plus plausible tient au profil de test de Lighthouse : sur mobile, il simule une connexion 4G lente qui étale l’arrivée des scripts tiers dans le temps, si bien que les longues tâches se répartissent au lieu de se concentrer dans la fenêtre de mesure entre le premier affichage et l’interactivité. Sur desktop, réseau rapide, tout ce JavaScript arrive d’un coup et bloque le fil principal en bloc. Je le présente comme un constat mesuré, pas comme une vérité définitive — c’est le genre d’artefact de mesure qu’il faut savoir lire sans en tirer une théorie générale.

Ce qu’une migration de 15 ans implique vraiment

C’est la partie que les benchmarks jouets ne montrent jamais, parce qu’ils n’ont rien à trier. Migrer quinze ans de contenu n’est pas un lift-and-shift — copier le contenu tel quel d’un moteur à l’autre. C’est une décision éditoriale, prise sur des données.

Le pipeline, concrètement :

• Export WXR natif de WordPress, puis un script Node maison (turndown pour convertir le HTML en Markdown, génération du frontmatter, rapatriement des images, production d’un inventory.csv de tout le contenu).
• Croisement avec 16 mois de données Search Console (traitées sous pandas), page par page. Ce n’est pas le contenu qui décide de son sort, ce sont ses performances réelles en recherche.

Le tri qui en sort, sans fard : 15 pages « star » (3 818 clics cumulés), 44 pages conservées telles quelles, 16 à réécrire (bloquées en positions 50 à 77, du potentiel gâché par un contenu daté), une vingtaine élaguées en redirections 301, et une seule passée en 410 — supprimée pour de bon, assumée comme morte.

Le constat le plus intéressant est stratégique. 81 % du trafic venait d’articles techniques hors-marque — des tutoriels sur InDesign, sur le CSS, écrits au fil des années et qui n’ont rien à voir avec le cœur de métier actuel. La tentation « cohérence de marque » aurait été de les sacrifier. Décision inverse : les garder comme ancres d’autorité dans le hub /blog. On ne jette pas ce qui a construit l’autorité d’un domaine sur quinze ans au nom d’un branding propre. C’est une leçon qui dépasse ce site : le trafic qui ne « colle » pas à votre positionnement actuel est quand même le trafic qui fait exister votre domaine aux yeux de Google.

Le reste relève de l’hygiène de migration : conservation à l’identique des slugs (via une route catch-all qui sert chaque ancienne URL à sa place), une carte de redirections 301 pour ce qui bouge, et une bascule DNS vers Cloudflare — une ligne à changer, le détail de la sortie d’hébergement mériterait un article à lui seul.

Combien de temps, honnêtement ? De l’ordre d’une semaine de travail. Pas une après-midi — quiconque vous vend une migration de cette ampleur en une après-midi n’a pas fait le tri. Mais pas un trimestre non plus : l’essentiel du coût est dans l’analyse et les arbitrages, pas dans la technique.

Le résultat brut

Même URL, même outil, mêmes conditions. Le avant est mesuré le 17/07 à 16 h 04 sur le WordPress encore en ligne, le après le 18/07 à 07 h 47 sur le build Astro. Les valeurs sont reprises telles quelles des rapports, sans arrondi :

Deux choses à en retenir. D’abord, l’histoire est mobile. Le desktop était déjà correct — passer de 87 à 100 est agréable mais anecdotique. C’est sur mobile que tout se joue : LCP divisé par près de 2,5 (3,7 s → 1,5 s), Speed Index divisé par 5 (5,6 s → 1,1 s). C’est là que vivent vos vrais visiteurs, sur un téléphone milieu de gamme en réseau imparfait.

Ensuite, le TBT à 0 ms est la signature du modèle Astro, et il mérite qu’on le comprenne. Ce n’est pas du JavaScript brillamment optimisé : c’est du JavaScript qui n’existe pas. Astro génère la page à l’avance et n’envoie aucun script par défaut. On n’optimise pas ce qu’on n’expédie jamais.

Ce que le 100/100 cache

Voici la section que j’aurais aimé lire ailleurs, et que je ne trouve jamais. Un score parfait déclenche l’auto-satisfaction ; il devrait déclencher trois lucidités.

1. Le score plafonne avant la fin du travail. Le rapport Astro affiche 100, et pointe pourtant encore des économies possibles : des requêtes bloquant le rendu (environ 220 ms sur desktop, 570 ms sur mobile d’économies estimées) et un ajustement forcé de mise en page. Autrement dit, il reste du travail que Lighthouse ne pénalise plus. 100 ne veut pas dire « terminé ». 100 veut dire « au-delà du seuil où l’outil arrête de compter les points ». Ce sont deux choses très différentes, et confondre les deux, c’est arrêter d’optimiser au moment précis où l’outil cesse de vous applaudir.

2. Ce sont des données de laboratoire, pas de terrain. Les deux rapports affichent « aucune donnée » côté CrUX (le Chrome User Experience Report) : le site n’a pas assez de trafic pour alimenter les field data, les mesures issues des vrais navigateurs. Tout ce que vous lisez dans le tableau ci-dessus est une simulation — un device émulé, une connexion émulée. Les vrais utilisateurs, leurs vrais téléphones, leurs vraies connexions bancales ne sont pas dans ces chiffres. Le lab est un excellent indicateur ; ce n’est pas une preuve d’expérience réelle.

3. Ce n’est pas un comparatif à périmètre identique — et je l’assume. Entre le avant et le après, il n’y a pas eu qu’un changement de moteur. Il y a eu un triage, des réécritures, un élagage. Une partie du gain vient du régime, pas seulement de la nouvelle mécanique. Un lift-and-shift pur — le même contenu, bloc pour bloc, versé de WordPress vers Astro — aurait gagné moins que ça. Le dire ne fragilise pas la démonstration : ça la rend crédible. Astro apporte un plancher de performance très bas ; le tri éditorial apporte le reste. Les deux comptent, et prétendre que tout le mérite revient à la stack serait malhonnête.

Ce que Lighthouse ne mesurera jamais — et la suite

Le vrai verdict d’une migration ne s’affiche pas dans un rapport de performance. Il s’affiche dans Search Console, des mois plus tard : les positions ont-elles tenu ? Le trafic a-t-il suivi ? Les clics sont-ils au rendez-vous après la bascule des URL ? La latence de réindexation se compte en semaines et en mois, pas en secondes de chargement. À ce jour, rien de mesurable — et quiconque prétend le contraire moins d’une semaine après une migration invente.

C’est pourquoi ce récit est volontairement à moitié écrit. Un avant complet est gelé : rapports Lighthouse datés, 16 mois de données GSC archivées, positions figées. L’après SEO — celui qui juge vraiment l’opération — sera publié à l’automne, quand les index auront parlé. C’est le seul juge qui compte, et il prend son temps.

Reste une dimension nouvelle, glissée dans le tableau : la navigation agentique est passée de 1/3 à 3/3. Un site Astro, servi en HTML propre, se laisse lire par les agents IA bien mieux qu’un WordPress alourdi de scripts. Cet angle — comment cette migration a été pensée pour être lisible par les agents IA — est traité en détail dans un dossier dédié. Je m’arrête là ici : c’est un sujet à part entière, et le développer davantage sur cette page ferait doublon avec ce dossier.

Si vous envisagez une refonte, la question n’est pas « faut-il quitter WordPress ». C’est : qu’est-ce qui vous plafonne, et est-ce réparable sans changer de moteur ? Parfois oui — et je continue de livrer et d’entretenir des WordPress pour de bonnes raisons. Parfois le plafond est structurel, et aucun plugin d’optimisation ne le percera. Ce site était dans le second cas. Le savoir avant de commencer, ça vaut plus que vingt points de Lighthouse.