Migrer un site sans perdre en performance : une checklist pour changer d’hébergement, de thème ou de CMS

Changer d’hébergement, passer à un nouveau thème, refaire le site, le faire passer d’un CMS à un autre : dans des projets comme ceux-ci, l’attention va à ce que l’on voit, c’est-à-dire le design, le contenu et les fonctionnalités, et à ce qui fait peur, comme perdre des positions dans les résultats de recherche. La performance reste souvent à l’arrière-plan, tenue pour acquise. Et ce sont précisément les moments où de nombreux sites la perdent : un cache qui n’est pas reconfiguré, une compression qui disparaît, un nouveau thème plus lourd que l’ancien, un serveur dans une autre région.

Le problème est que ces pertes se voient tard. Les données de terrain que Google utilise sont calculées sur 28 jours, et une régression introduite le jour de la migration apparaît dans les rapports des semaines plus tard, quand il est difficile de la relier à sa cause. Dans cet article, nous proposons une méthode en trois phases, avant, pendant et après, pour migrer un site sans perdre en performance, ou pour s’en apercevoir tout de suite si cela arrive.

Avant : prendre un instantané du point de départ

L’étape la plus importante, et la plus négligée, est de mesurer l’état actuel avant de toucher à quoi que ce soit. Après la migration, l’ancien site n’existera plus, et sans un instantané précis il sera impossible de dire si le nouveau est meilleur ou pire, et où.

• Données de terrain. Les valeurs des Core Web Vitals du Chrome UX Report pour toute l’origine et pour les pages les plus importantes, idéalement avec la série historique de la CrUX History API, et l’état des groupes d’URL dans le rapport de Search Console. Si vous avez un système de Real User Monitoring, les valeurs quotidiennes par modèle de page.
• Tests de laboratoire reproductibles. Pour chaque modèle de page principal, un test avec un outil qui permet de répéter les mêmes conditions, comme WebPageTest avec un lieu, un appareil et une connexion fixes, en enregistrant les résultats et les waterfalls. Trois exécutions par page, pour réduire la variabilité.
• Configuration technique. Les en-têtes de réponse du HTML, des feuilles de style, des scripts et des images : cache, compression, protocole. Version de PHP et de la base de données, type de cache de page et de cache d’objets, CDN, réglages DNS.
• Pages dynamiques. Le TTFB du panier, du tunnel de commande, de la recherche, de l’espace client et de l’administration, qui dépendent entièrement du serveur et sont les premiers à se dégrader sur un hébergement inadapté.
• Redirections et URL. La liste des URL existantes et des redirections actives, nécessaire à la fois pour le SEO et pour éviter les chaînes de redirections qui ajoutent du temps avant le premier octet.

Un simple script peut rassembler dans un fichier les principaux en-têtes des pages clés, pour les comparer plus tard à ceux du nouvel environnement :

#!/usr/bin/env bash
# Enregistre dans un fichier les en-têtes et les temps des pages clés pour la comparaison
for url in / /categoria/scarpe/ /prodotto/scarpa-trail/ /carrello/ /blog/; do
	echo "== $url"
	curl -so /dev/null -H 'Accept-Encoding: br, gzip' \
		-w 'ttfb=%{time_starttransfer}s http=%{http_version}\n' "https://esempio.it$url"
	curl -sI -H 'Accept-Encoding: br, gzip' "https://esempio.it$url" \
		| grep -iE '^(cache-control|content-encoding|x-cache|server|alt-svc):'
done > prima-della-migrazione.txt

Pendant : vérifier la parité

Le nouvel environnement doit être vérifié avant de recevoir du trafic réel, sur une adresse de test. L’objectif minimal est la parité : tout ce que l’ancien site faisait bien, le nouveau doit continuer à le faire. Les pertes les plus fréquentes se situent toujours aux mêmes endroits.

• Cache. Le cache de page de l’ancien hébergement, souvent au niveau du serveur et invisible dans le tableau de bord de WordPress, n’est pas transféré avec le site. Sur le nouvel environnement, il doit être configuré de zéro, avec les mêmes exclusions. Il en va de même pour le cache d’objets.
• Compression et protocoles. Brotli ou Zstandard, HTTP/2 et HTTP/3 dépendent du serveur : vérifiez-les avec les en-têtes et avec DevTools, comme l’expliquent les articles sur la compression et sur HTTP/3.
• Cache du navigateur. Les en-têtes d’expiration des ressources statiques, souvent configurés dans l’ancien serveur, doivent être reproduits, avec les règles de revalidation traitées dans l’article sur HTTP 304.
• Images. Conversion vers des formats modernes, tailles adaptatives et services d’optimisation, souvent liés à l’ancien hébergement ou à des plugins configurés avec des clés et des chemins spécifiques.
• Logiciels. Versions de PHP et de la base de données au moins égales aux précédentes, OPcache activé, limites de mémoire adaptées.
• Capacité. Un test de charge sur le nouvel environnement, comme décrit dans l’article sur les pics de trafic, vérifie qu’il tient face à un trafic réel, surtout sur les pages dynamiques.

Si la migration comprend un nouveau thème ou une refonte, la comparaison du front-end s’ajoute à la parité technique : poids de la page, nombre de requêtes, JavaScript, taille du DOM, élément LCP pour chaque modèle de page. C’est le moment idéal pour fixer un budget de performance : le nouveau site ne doit pas peser plus que l’ancien, sauf décision consciente.

Quelques jours avant le basculement, il vaut la peine d’abaisser le TTL des enregistrements DNS qui vont changer, par exemple à cinq minutes, pour que le changement d’adresse se propage vite et qu’un éventuel retour à l’ancien environnement soit tout aussi rapide. Après la migration, une fois les choses stabilisées, le TTL revient à ses valeurs habituelles, comme l’explique l’article sur le DNS, le TLS et les connexions.

Le jour du basculement

Le basculement doit être programmé à un moment de faible trafic, loin des campagnes et des périodes de soldes, avec les personnes nécessaires disponibles. Juste après le changement de DNS, quelques vérifications doivent être faites immédiatement : que les pages principales répondent correctement et depuis le nouveau serveur, que le cache de page fonctionne, que les redirections arrivent à la destination finale en un seul saut, que les formulaires, le panier et les paiements fonctionnent. Réchauffer le cache en visitant les pages les plus importantes évite que les premiers utilisateurs trouvent un site lent parce que chaque page doit être générée.

Il faut aussi préparer un plan de retour en arrière : que faire, et en combien de temps, si le nouvel environnement présente de graves problèmes. Avec un TTL bas et l’ancien environnement encore actif pendant quelques jours, revenir en arrière est l’affaire de quelques minutes.

Après : comparer et surveiller

Dans les jours qui suivent, on répète exactement les mêmes tests que dans la première phase, dans les mêmes conditions, et on compare les résultats. Les en-têtes collectés par le script, les temps, les waterfalls : chaque différence doit être expliquée. Un TTFB plus élevé sur les pages en cache indique un cache qui ne fonctionne pas ou un serveur plus éloigné ; une taille transférée plus grande pour les mêmes fichiers indique une compression différente ; de nouvelles requêtes dans le waterfall indiquent des scripts ou des ressources qui ont été ajoutés.

Les données d’utilisateurs réels sont la vérification décisive, mais elles arrivent à des vitesses différentes selon la source. Votre propre système de monitoring montre l’effet dès le lendemain ; les données du Chrome UX Report et de Search Console, calculées sur 28 jours, évoluent progressivement et ne montrent l’effet complet qu’au bout d’un mois.

C’est pourquoi, si vous n’avez pas de système de monitoring des utilisateurs réels, la migration est une bonne occasion d’en activer un quelques semaines plus tôt : il permet de comparer les valeurs quotidiennes avant et après et d’intervenir tout de suite. À défaut, la CrUX History API, avec des données hebdomadaires, offre au moins une vue plus rapide que le rapport de Search Console.

Migrations de CMS et de domaine

Certaines migrations s’accompagnent de complications supplémentaires. Passer d’un CMS à un autre, ou d’un site traditionnel à une architecture headless, change complètement la façon dont les pages sont générées et servies : la comparaison par modèle de page devient encore plus importante, et il est utile de surveiller le comportement des métriques dans les architectures monopages, comme nous l’avons vu dans l’article sur les Single Page Applications. Un changement de domaine, en revanche, repart de zéro pour les données du Chrome UX Report de la nouvelle origine : pendant quelques semaines, les données de terrain seront rares ou absentes, et votre propre monitoring devient la seule source fiable.

Un exemple

Un site de services passe d’un hébergement mutualisé à un VPS plus puissant, dans le but d’améliorer les temps de réponse. Les tests de laboratoire sur le nouvel environnement montrent le TTFB des pages dynamiques divisé par deux, et la migration est jugée réussie. Trois semaines plus tard, Search Console signale un LCP dégradé sur mobile. La comparaison des en-têtes collectés avant et après révèle la cause : l’ancien hébergement servait les pages depuis un cache au niveau du serveur, qui n’a pas été configuré sur le VPS, et compressait les ressources avec Brotli, alors que le nouveau serveur n’utilise que Gzip. Les pages en cache, c’est-à-dire la grande majorité des visites, sont devenues plus lentes même si le serveur est plus puissant. Une fois le cache configuré et Brotli activé, les valeurs redeviennent meilleures qu’avant. Avec les bonnes mesures collectées au préalable et un monitoring quotidien ensuite, le problème serait apparu le jour même.

Les erreurs les plus courantes

Les mêmes erreurs reviennent sans cesse. La première est de ne mesurer que la page d’accueil, presque toujours en cache et rarement représentative : les régressions se cachent dans les fiches produit, les articles et les pages dynamiques. La deuxième est de comparer des tests réalisés dans des conditions différentes, depuis des lieux, des appareils ou des outils différents, et d’imputer à la migration des écarts qui viennent du test. La troisième est d’oublier la configuration qui vit en dehors du site : règles du CDN, en-têtes ajoutés par l’ancien serveur, redirections gérées au niveau de l’hébergement, enregistrements DNS. La quatrième est de considérer la migration comme terminée le jour du basculement, sans période de surveillance active.

Les personnes à impliquer

Une migration fait intervenir des compétences différentes, et la performance se retrouve souvent au milieu. Celui qui gère l’hébergement connaît le serveur et la configuration des caches ; celui qui développe le thème connaît le front-end ; celui qui s’occupe du SEO connaît les URL, les redirections et Search Console ; celui qui dirige le marketing sait quels scripts et quelles campagnes sont actifs. Il vaut mieux décider dès le départ qui est responsable de la performance dans le projet, avec pour mission de collecter les mesures initiales, de vérifier la parité et de suivre les données dans les semaines suivantes, et il est utile que le fournisseur du nouvel hébergement connaisse les objectifs, pas seulement les exigences techniques.

La checklist courte

1. Activer le monitoring des utilisateurs réels quelques semaines plus tôt.
2. Enregistrer les données de terrain, les tests de laboratoire reproductibles et les en-têtes pour chaque modèle de page.
3. Configurer cache, compression, protocoles, cache du navigateur et images sur le nouvel environnement, et les vérifier un par un.
4. Exécuter un test de charge sur les pages dynamiques.
5. Abaisser le TTL du DNS, préparer le plan de retour en arrière, choisir un moment de faible trafic.
6. Après le basculement, répéter les mêmes tests, comparer, surveiller les données quotidiennes et vérifier Search Console au bout d’un mois.

En résumé

Les migrations sont l’un des moments où les sites perdent le plus facilement en performance, à cause d’une configuration qui n’est pas transférée, de thèmes plus lourds ou d’une infrastructure différente. La méthode pour l’éviter est simple mais demande de la discipline : prendre un instantané du point de départ avec les données de terrain, des tests reproductibles et la configuration technique ; vérifier la parité sur le nouvel environnement avant le basculement ; répéter ensuite les mêmes tests et surveiller les données d’utilisateurs réels jour après jour.

Les données de Google arriveront avec des semaines de retard et confirmeront le résultat ; le vrai travail se fait avant, avec les mesures qui rendent la comparaison possible, et juste après, avec une surveillance qui permet d’intervenir. Une migration bien préparée n’est pas seulement neutre pour la performance : c’est souvent l’occasion de l’améliorer.