Changement de thème en chiffres : un vrai site WordPress migre vers Hafen

Les promesses publicitaires sur la vitesse des thèmes abondent, les séries de mesures sur de vraies migrations sont rares. Nous en documentons donc une complète : flirtuniversity.de, une école de séduction avec 17 ans de contenus, un espace membres, une gestion du consentement, des embeds vidéo et tout ce qui s’accumule sur un site WordPress qui a vécu, est passé le 1er septembre 2026 de Neve à Hafen. Pas de montage en laboratoire, pas de site de démonstration fraîchement installé. C’est précisément pour cela que les chiffres sont prudents, et précisément pour cela qu’ils ont de la valeur.

La situation de départ

Neve n’est pas un mauvais thème, au contraire, il compte à juste titre parmi les thèmes classiques les plus rapides. Le site affichait pourtant sur mobile des scores Lighthouse de 56 à 59, avec un First Contentful Paint autour de 4 secondes. La cause n’est pas la négligence, mais l’architecture : un thème classique embarque son propre framework CSS, ses propres scripts et ses propres couches de réglages, chargés sur chaque page, utiles ou non.

Hafen vient de la direction opposée : un thème de blocs, où la mise en page, les couleurs et la typographie vivent dans theme.json et où WordPress génère lui-même le CSS nécessaire. Au total, le thème ne pèse que deux requêtes et 7 KB sur le réseau. La question de cette étude de cas était de savoir ce qu’il en reste sur un vrai site bien rempli.

La méthode, pour que les chiffres soient vérifiables

Les mesures ont été réalisées avec Lighthouse 13.4.1 dans un Chrome headless, sur la même machine, le même jour : Neve à midi avant la migration, Hafen juste après la mise en ligne, avec un cache vidé puis réchauffé. Trois passages par page et par catégorie d’appareil, la valeur retenue est la médiane de chaque métrique. Quatre types de pages couvrent le site : la page d’accueil, les archives du blog, un article et une page de cours avec un hero vidéo. Ce sont des valeurs de laboratoire, pas des données de terrain, mais elles ont été relevées dans des conditions identiques, et c’est tout ce qui compte pour une comparaison.

Ce que le changement de thème a apporté à lui seul

Sur mobile, là où ça fait mal, le simple changement donne ceci, à chaque fois Neve contre Hafen, même jour, mêmes plugins :

À cela s’ajoutent 22 à 38 % de requêtes en moins, un Total Blocking Time divisé par deux sur la page d’accueil et un Largest Contentful Paint en baisse de 29 à 44 %. La stabilité de la mise en page est restée à 0,00. Le desktop était déjà dans le vert sous Neve et l’est resté, avec 23 à 34 % de poids de page en moins.

Le chiffre le plus important est le First Contentful Paint : environ 4 secondes deviennent 1,3 seconde sur chaque page mesurée. C’est le moment où les visiteurs voient quelque chose pour la première fois au lieu d’attendre devant un écran blanc, et il dépend presque entièrement de la quantité de CSS et de JavaScript que le thème place avant le rendu.

La partie honnête : ce que le changement n’a pas résolu

Les quelque 360 à 400 KB de JavaScript restants proviennent presque entièrement des plugins : espace membres, gestion du consentement, statistiques, embeds vidéo. Un changement de thème ne nettoie pas cette couche, il révèle seulement que c’est elle qui porte le vrai poids. Et le Largest Contentful Paint restait sur mobile entre 4 et 6 secondes même sous Hafen, parce que le plus grand élément des pages les plus importantes est un poster vidéo qui n’était chargé que par JavaScript. Un thème léger ne sauve pas des contenus lourds, nous l’avions déjà écrit, et cette mesure le confirme.

Deuxième passe : ce qu’il restait à gagner sur le nouveau thème

Le changement a donc été suivi d’une deuxième passe, cette fois sur les contenus et le comportement de chargement, autant de mesures qui n’agissent proprement que sur des fondations assainies :

• Preload du poster pour les heros vidéo : l’image d’aperçu du plus grand élément est chargée en preload avec une priorité haute et affichée immédiatement comme arrière-plan CSS, au lieu d’attendre le script d’embed.
• Connexions établies en avance vers les hôtes d’analyse via preconnect, ce qui épargne aux connexions mobiles la négociation DNS et TLS dans le chemin critique.
• content-visibility pour les sections sous la ligne de flottaison : le navigateur ne rend que ce qui approche de la zone visible.
• Cure d’amaigrissement des scripts : un widget d’avis ne se charge plus que sur la page d’accueil, où il est réellement intégré, et les scripts d’annonces automatiques d’un compte publicitaire désactivé ont complètement disparu du site.

Résultat sur la page de cours, le cas le plus difficile avec son hero vidéo : score mobile de 71 à 86, le Largest Contentful Paint est passé de 5,2 à 4,0 secondes. L’article est monté de 77 à 86, les archives du blog de 76 à 80, la page d’accueil a conservé son score et a progressé sur le chemin de chargement et le poids. Le JavaScript a encore nettement baissé, à 215 à 254 KB par page. Sur les deux étapes cumulées, cela donne : des scores mobiles de 56 à 59 sous Neve à 71 à 86, avec un contenu inchangé.

Ce qui a été réinjecté dans le thème

Cette migration était pour nous les deux à la fois, projet client et test grandeur nature de notre propre produit. Une poignée de constats issus de la migration a directement alimenté le développement du thème et arrive avec la prochaine version, Hafen 0.9.0 : les archives du blog ont reçu une grille magazine avec une carte à la une, les articles sans image mise en avant un visuel de repli soigné, la pagination des cibles adaptées au tactile. Ce qui était corrigé auparavant par du CSS sur le site du client deviendra le standard pour tous ceux qui installent le thème dès la prochaine mise à jour. C’est ainsi que le dogfooding doit fonctionner : l’étude de cas améliore le produit, pas seulement un site.

Ce que vous pouvez en retenir

Si vous envisagez un changement de thème, trois enseignements de cette migration sont transposables. Premièrement : mesurer avant, mesurer après, avec la même méthode. Sans chiffres de départ, impossible de savoir ensuite si l’effort en valait la peine. Deuxièmement : le changement améliore les fondations, pas les contenus. Les images lourdes, les embeds vidéo et les scripts de plugins vous suivent, ils ressortent simplement davantage sur des fondations rapides, et c’est exactement là que la deuxième passe devient rentable. Troisièmement : les contenus restent, les mises en page se refont. L’en-tête, le pied de page et les pages d’archives doivent être repensés, les textes et les images restent intacts dans la base de données.

Questions fréquentes