Managed Server : de 76-86 à 100 sur mobile avec des Core Web Vitals déjà au vert

Contexte

Managed Server SRL est une entreprise italienne qui propose de l’hébergement géré et de l’ingénierie de systèmes Linux haute performance. Le site de l’entreprise tourne sur WordPress avec le thème Astra et le page builder Elementor, sur une pile serveur soigneusement réglée : nginx avec TLS, HTTP/2 et HTTP/3, Varnish comme cache de page, PHP-FPM et MariaDB, avec Autoptimize pour l’agrégation du CSS et du JavaScript. La page d’accueil compte 34 sections et environ 3 300 éléments DOM.

Ce cas est atypique : le site était déjà rapide pour les utilisateurs réels. L’objectif n’était pas de réussir les Core Web Vitals, mais d’obtenir un score de laboratoire cohérent avec l’expérience réelle, sans recourir à des services d’optimisation qui repoussent le JavaScript au-delà de la fenêtre de mesure et font se comporter la page différemment pendant les tests. Le travail est documenté en détail dans le récit de l’optimisation publié par Managed Server.

Ce que disaient les données

Les données de terrain du Chrome UX Report étaient déjà excellentes : LCP à 0,7 seconde, INP à 73 millisecondes et CLS à 0. PageSpeed Insights sur mobile oscillait pourtant entre 76 et 86 points, avec un First Contentful Paint entre 2,0 et 2,4 secondes, un Largest Contentful Paint entre 3,8 et 5,3 secondes, un Speed Index entre 3,3 et 5,0 secondes, un Total Blocking Time entre 0 et 100 millisecondes et un CLS à 0. Sur ordinateur, le score était déjà compris entre 97 et 100.

L’écart entre terrain et laboratoire s’explique par les conditions de test : un appareil mobile émulé avec un CPU bridé et un réseau lent fait apparaître des coûts que les utilisateurs réels, avec de meilleurs appareils et de meilleures connexions, remarquent à peine. Ce sont pourtant de vrais coûts pour la queue des utilisateurs les plus lents, et c’est pourquoi il valait la peine de les éliminer.

Le diagnostic

L’analyse, faite avec des exécutions Lighthouse en local, le JSON brut de PageSpeed Insights et des traces Chrome DevTools, a isolé quelques causes, chacune avec un poids précis :

• document HTML lourd : 128 Ko compressés, dont 71 Ko de SVG en ligne sur la seule page d’accueil mobile, presque un quart du document ; une seule icône pesait environ 100 Ko non compressés ;
• délai de rendu du LCP entre 1 050 et 2 112 millisecondes : l’élément principal était prêt, mais le navigateur l’affichait tard à cause du CSS bloquant le rendu et du travail de mise en page ;
• JavaScript forçant la mise en page de sections qui n’étaient pas visibles, comme le script qui étire les sections sur toute la largeur ;
• polices et préchargements non optimaux : 14 variantes latin-ext d’Open Sans inutilisées et le préchargement d’une police située sous la ligne de flottaison, qui dégradait le LCP de 170 millisecondes.

Travail côté serveur

• microcache nginx devant Varnish, avec mise à jour en arrière-plan et l’exemplaire précédent en secours : moins de requêtes vers Varnish et PHP-FPM, et plus de résilience ;
• compression déplacée vers le backend, ce qui retire 30 à 40 millisecondes de CPU sur le frontal : Brotli 9 et Zstandard 15 pour le HTML, Brotli 11 et Zstandard 19 pour les fichiers Autoptimize, qui ont une longue durée de cache ;
• correction d’une erreur de lecture intermittente entre nginx et le backend, présente dans environ 1,5 % des requêtes et causée par des connexions keepalive expirées, résolue avec keepalive_timeout 0 sur le backend ;
• mémoire de Varnish portée de 512 Mo à 2 Go ;
• préchauffage du cache pour 781 URL, deux appareils et trois encodages, soit 4 386 requêtes en environ trois heures un quart, menées en douceur : 24 HIT sur 24 lors des contrôles ponctuels, avec des réponses entre 22 et 48 millisecondes.

Travail côté application

• SVG sortis du document, le principal levier : les icônes en ligne ont été déplacées dans des fichiers séparés, chargés au besoin, et le HTML compressé est passé de 128 à 62 Ko ;
• CSS critique par page et par appareil, généré avec Penthouse sur 47 pages en versions mobile et ordinateur, avec JavaScript activé pour appliquer les classes d’Astra : d’environ 130 Ko à 55-60 Ko ;
• content-visibility: auto sur les sections sous la ligne de flottaison, avec un contain-intrinsic-size mesuré pour chaque section et chaque appareil afin de ne pas provoquer de décalages ; le pied de page mobile, haut de 4 400 pixels, sort du rendu initial ;
• mise en page sans JavaScript : le script Elementor qui étirait les sections a été remplacé par du CSS ; sur les 18 sections concernées, 15 avaient déjà la largeur de la fenêtre et 3 ont été résolues avec width: 100vw et margin-left: calc(50% - 50vw) ;
• polices : variantes inutilisées supprimées, une icône Font Awesome de 10 Ko remplacée par un SVG de 457 octets, préchargements conservés uniquement là où ils sont utiles de façon mesurable ;
• report du JavaScript, mesuré : jQuery différé avec un petit shim de compatibilité, wp-i18n et wp-hooks retirés là où ils ne servent pas, bandeau de cookies, infobulles et chat chargés plus tard, analytics dans le respect du consentement, sans retarder l’initialisation des composants visibles.

Résultats

La première série de travaux, environ 20 heures, a porté le score mobile à 98, avec un LCP de 2,3 secondes et un délai de rendu du LCP ramené de plus d’une seconde à 130 millisecondes. Avec les affinements ultérieurs, la mesure actuelle de PageSpeed Insights sur mobile est de 100 points :

Métrique (laboratoire, mobile)	Avant	Après
Score PageSpeed Insights	76-86	100
First Contentful Paint	2,0-2,4 s	1,2 s
Largest Contentful Paint	3,8-5,3 s	1,7 s
Total Blocking Time	0-100 ms	0 ms
Cumulative Layout Shift	0	0
Speed Index	3,3-5,0 s	1,8 s
HTML compressé	128 Ko	62 Ko

Les données de terrain sont restées au vert, comme avant. C’est tout l’intérêt de ce cas : le score décrit désormais un site réellement rapide, obtenu en réduisant le travail du navigateur plutôt qu’en le déplaçant hors de la fenêtre de mesure.

Comment nous maintenons le résultat

Le CSS critique doit être régénéré quand la mise en page d’une page change, et chaque nouvelle section située sous la ligne de flottaison demande sa propre mesure de contain-intrinsic-size. Chaque modification est vérifiée avec plusieurs exécutions Lighthouse, car un seul test ne suffit pas à distinguer une amélioration du bruit, et les données du Chrome UX Report restent la référence finale. Quelques points ont été volontairement reportés, comme un CSS critique limité au seul premier écran, qui gagnerait 35 à 50 millisecondes au prix d’un risque de décalages, et l’alignement des métriques de police sur la page des tarifs.