Core Web Vitals et hébergement web : ce que tu peux réellement contrôler

Les trois indicateurs Web Vitals essentiels et l'impact de l'hébergement sur chacun d'entre eux

Plus grand élément peignant le contenu (LCP)

Le LCP mesure le temps nécessaire au chargement de l'élément visible le plus grand d'une page. Pour la plupart des sites web, il s'agit d'une image principale, d'un gros titre ou d'une vignette vidéo. Un bon résultat se situe en dessous de 2,5 secondes. Un mauvais résultat est supérieur à 4 secondes.

L'hébergement est le principal facteur déterminant pour le LCP. Le temps de réponse du serveur (Time to First Byte, TTFB) est le premier délai de la chaîne LCP. Avant que le navigateur puisse commencer à charger le contenu principal, il doit recevoir le premier octet du document HTML provenant du serveur. Une réponse lente du serveur se traduit par un LCP lent, quel que soit le niveau d'optimisation de la page côté client.

Sur un NVMe bien configuré, le TTFB est inférieur à 200 millisecondes. Sur une formule d'hébergement mutualisé avec un serveur surchargé, il dépasse généralement les 600 à 800 millisecondes. À elle seule, cette différence peut faire passer le LCP de « bon » à « à améliorer », sans qu'aucune image ne soit trop volumineuse.

Interaction jusqu'à la prochaine peinture (INP)

En 2024, l'INP a remplacé le First Input Delay (FID) parmi les Core Web Vitals. Il mesure la latence de toutes les interactions sur une page tout au long de la session, et pas seulement celle de la première interaction. Un bon seuil est inférieur à 200 millisecondes.

L'INP dépend principalement de l'exécution du JavaScript et du rendu du navigateur, et non du temps de réponse du serveur. Les frameworks JS front-end lourds, les plugins surdimensionnés et les scripts tiers excessifs sont les principaux facteurs à l'origine d'un mauvais INP. L'hébergement a un effet indirect : un serveur plus rapide permet à la page de se charger plus vite, ce qui donne au navigateur plus de temps pour traiter le JavaScript avant que l'utilisateur ne commence à interagir.

Déplacement cumulatif de la mise en page (CLS)

Le CLS mesure l'ampleur des déplacements inattendus du contenu lors du chargement d'une page. Un score inférieur à 0,1 est considéré comme bon. Le CLS dépend presque entièrement du front-end et n'est pas vraiment influencé par la configuration du serveur. Les causes typiques sont les dimensions d'image non définies, les polices chargées tardivement et le contenu injecté dynamiquement.

Temps de réponse jusqu'au premier octet : la contribution directe de ton serveur

Le TTFB est la variable d'hébergement la plus facile à contrôler dans les Core Web Vitals. Il correspond au temps écoulé entre le moment où un navigateur envoie une requête HTTP et celui où il reçoit le premier octet de la réponse. Il inclut le temps de résolution DNS, l'établissement de la connexion (TCP et TLS) et le temps de traitement du serveur.

C'est le temps de traitement du serveur qui dépend directement de ton infrastructure. Une application PHP qui doit générer une page à partir d'une requête de base de données à chaque demande met plus de temps à répondre qu'une application qui fournit une version HTML mise en cache. L'infrastructure d'hébergement détermine la rapidité avec laquelle ce cache est mis à disposition et l'efficacité avec laquelle la base de données répond en cas d'échec du cache.

Ce qu'apporte réellement une bonne infrastructure d'hébergement au LCP

L'écart de performances entre les différents niveaux d'hébergement n'est pas qu'une question de théorie. Des tests indépendants réalisés par GTmetrix sur l'infrastructure NVMe InMotion Hostingmontrent systématiquement un TTFB inférieur à 200 millisecondes pour WordPress hébergés sur des configurations VPS optimisées, contre 600 à plus de 1 000 millisecondes sur des environnements d'hébergement mutualisé de niveau inférieur ou mal configurés.

UltraStack d'InMotion, disponible sur les formules VPS gérées et WordPress , combine NGINX proxy inverse, PHP-FPM pour la gestion des processus, OPcache pour la mise en cache des opcodes PHP et Redis pour la mise en cache des objets. Chaque composant permet de résoudre un goulot d'étranglement différent dans la chaîne de réponse du serveur.

NGINX proxy inverse : gère la diffusion des fichiers statiques et la gestion des connexions plus efficacement qu'Apache en cas de charge simultanée. Les ressources statiques (CSS, JS, images) sont diffusées directement par NGINX passer par PHP.

PHP-FPM : gère un pool de processus PHP actifs persistants. Ça évite d'avoir à lancer un nouveau processus PHP à chaque requête, ce qui est justement ce qui ralentit Apache avec mod_php quand il y a beaucoup de trafic.

OPcache : stocke en mémoire le bytecode précompilé des scripts PHP. Les fichiers WordPress sont compilés une seule fois, puis servis depuis la mémoire lors des requêtes suivantes, ce qui réduit considérablement le temps d'exécution PHP.

Cache d'objets Redis : stocke en mémoire les résultats des requêtes de base de données les plus gourmandes en ressources. Une page qui nécessiterait 20 requêtes de base de données sur un WordPress sans cache peut être servie depuis Redis en une seule lecture en mémoire.

L'emplacement du serveur et son impact sur les Core Web Vitals

La distance physique entre ton serveur et tes utilisateurs augmente la latence. Chaque tranche de 160 km de trajet réseau ajoute environ 1 milliseconde au temps aller-retour. Pour les utilisateurs de ton marché principal, c'est négligeable. Pour ceux qui se trouvent à l'autre bout du monde, cela s'ajoute au TTFB et devient un facteur significatif pour le LCP.

InMotion exploite des centres de données à Los Angeles, en Californie, et à Amsterdam, aux Pays-Bas. Pour les entreprises dont le public se trouve principalement aux États-Unis ou en Europe, ces emplacements couvrent la majeure partie de leur base d'utilisateurs grâce à des connexions à faible latence. Pour un public international, l'intégration d'un CDN achemine le contenu statique via des nœuds périphériques situés plus près des utilisateurs, ce qui réduit la charge sur le serveur d'origine et améliore les performances perçues, quel que soit l'emplacement d'origine.

Les indicateurs que tu ne peux pas améliorer uniquement grâce à l'hébergement

Il y a deux situations qui entraînent de mauvais résultats pour les Core Web Vitals, et aucune amélioration de l'hébergement ne peut y remédier.

Le premier problème, c'est le surpoids du front-end. Une page qui charge 40 scripts tiers, une image principale non optimisée de 8 Mo et un thème qui exécute 200 Ko de JavaScript non fractionné obtiendra de mauvais résultats pour le LCP et l'INP, quelle que soit la vitesse du serveur. Une fois que le TTFB est inférieur à 200 ms, le temps restant pour le LCP correspond presque entièrement au temps de téléchargement et de rendu. Ça nécessite une optimisation des images, un audit des scripts et un travail sur les performances front-end.

La deuxième raison, c'est une mauvaise mise en œuvre de la mise en cache. NGINX un environnement d'hébergement géré équipé NVMe et NGINX affichera des pages lentes si l'application ne gère pas correctement la mise en cache côté serveur. WordPress qui n'ont pas de plugin de mise en cache adapté et configuré pour fonctionner avec la pile serveur génèrent des exécutions PHP sur toute la page à chaque requête, ce qui annule les avantages d'un matériel sous-jacent rapide.

À lire aussi : « Core Web Vitals : le nouveau critère de classement de Google » présente en détail les outils de mesure et les méthodes de diagnostic.

Une liste de contrôle pratique pour les agences qui gèrent les sites de leurs clients

Pour les agences chargées de gérer les scores Core Web Vitals pour le compte de leurs clients, il faut s'occuper de l'hébergement et de l'infrastructure avant de se lancer dans l'optimisation du front-end. Un serveur rapide doté d'une mise en cache efficace offre au front-end la base dont il a besoin.

• Vérifie que le TTFB est inférieur à 200 ms à l'aide de GTmetrix ou de PageSpeed Insights. S'il dépasse 400 ms, commence par vérifier ton hébergement.
• Assure-toi que la mise en cache côté serveur est activée. Pour WordPress, l'utilisation de W3 Total Cache de WP Super Cache, configurés pour la pile serveur spécifique, permet d'éviter toute exécution PHP inutile.
• Assure-toi que NGINX LiteSpeed sert directement les ressources statiques sans passer par PHP. Cela dépend de la configuration et il vaut mieux vérifier auprès de ton hébergeur.
• Vérifie si la mise en cache d'objets Redis ou Memcached est activée et configurée pour la WordPress .
• Vérifie la version de PHP. PHP 8.x offre des gains de performances significatifs par rapport à la version 7.x et devrait être la version par défaut pour toute WordPress en production.

À lire aussi : « Comparatif des hébergeurs web les plus rapides » comprend des tests de performance et des détails sur l'infrastructure liés aux performances LCP.

L'hébergement VPS d'InMotion, NVMe, offre systématiquement un temps de réponse (TTFB) inférieur à 200 ms lorsque UltraStack est activée. Découvre comment notre infrastructure influence tes scores Core Web Vitals : inmotionhosting.com/vps-hosting.