L’hébergement WordPress influe-t-il sur les Core Web Vitals ?

Quand un site WordPress rame, le réflexe habituel est d’installer un plugin de cache, de compresser les images ou d’optimiser le CSS. On ne pense pas forcément tout de suite à l’hébergeur lui-même. Pourtant, le choix de l’hébergement WordPress conditionne une partie des signaux que Google mesure désormais directement dans son algorithme. Nous parlons ici des Core Web Vitals. Depuis 2021, ces métriques font officiellement partie des facteurs de classement. Étant donné que la performance est une priorité SEO, découvrons ensemble ce que l’hébergement WordPress influence sur vos Core Web Vitals.

Tout ce que vous devez retenir à propos de l’hébergement WordPress et des Core Web Vitals

• L’hébergement WordPress a un impact direct sur le TTFB, qui conditionne lui-même le LCP

• Un passage d’un hébergement mutualisé à un VPS ou cloud peut faire passer le LCP de 4-5 secondes à moins de 2 secondes sans toucher au code

• Le CLS est quasi indépendant de l’hébergeur : si votre score est mauvais, la solution est dans le code, pas dans l’infrastructure

• OPcache, Redis, LiteSpeed ou Nginx, PHP 8.2 minimum et HTTP/2 sont les critères techniques à vérifier en priorité

• L’hébergement crée les conditions de la performance, l’optimisation WordPress fait le reste

Qu’est-ce que les Core Web Vitals mesurent ?

Les Core Web Vitals sont trois métriques définies par Google pour évaluer l’expérience utilisateur d’une page web. Elles mesurent la vitesse de chargement de l’élément principal, la réactivité aux interactions et la stabilité visuelle de la page. Ces éléments se traduisent par des métriques données par Google quand on réalise un test Page Speed Insights.

Le LCP (Largest Contentful Paint) mesure le temps d’affichage de l’élément le plus grand visible à l’écran, généralement une image hero ou un bloc de texte principal. Google considère un LCP sous 2,5 secondes comme « Good », entre 2,5 et 4 secondes comme « Needs Improvement », au-delà de 4 secondes comme « Poor ».

L’INP (Interaction to Next Paint) a remplacé le FID en mars 2024. Il mesure le délai entre une interaction utilisateur (clic, frappe clavier) et la mise à jour visuelle de la page en réponse. Seuil Good : sous 200ms. Entre 200 et 500ms, le signal se dégrade. Au-delà, Google considère l’expérience comme mauvaise.

Le CLS (Cumulative Layout Shift) quantifie les décalages visuels inattendus pendant le chargement. Un score sous 0,1 est Good, acceptable entre 0,1 et 0,25, et problématique au-delà.

Ces trois métriques forment ce que Google appelle les Page Experience signals. Elles s’ajoutent aux critères SEO historiques (balisage, contenu, liens) et constituent un quatrième pilier qu’est l’UX technique. Un site qui échoue sur l’ensemble s’expose à un désavantage mesurable face à ses concurrents.

Les effets de l’hébergement WordPress sur vos Core Web Vitals

Le TTFB : première ligne de front

Le TTFB (Time To First Byte) n’est pas un Core Web Vital à proprement parler, mais il conditionne tous les autres. C’est en effet le temps qui s’écoule entre la requête du navigateur et le premier octet renvoyé par le serveur. Google recommande un TTFB sous 800ms. En pratique, sur des hébergements mutualisés entrée de gamme, il n’est pas rare de mesurer des TTFB entre 1,5 et 3 secondes sur des sites WordPress sans cache serveur configuré.

Les causes d’un tel TTFB sont généralement :

• ressources CPU partagées entre des dizaines ou centaines de sites
• PHP exécuté sans OPcache
• une base de données MySQL sur un serveur distant du serveur web
• une absence de cache d’objets…

Un hébergement VPS ou cloud correctement configuré ramène généralement ce TTFB sous les 200ms.

Le LCP : directement tributaire du serveur

Le LCP part du TTFB. Si le serveur met 2 secondes à répondre, le LCP ne peut pas être bon, quels que soient les efforts d’optimisation côté WordPress. L’élément LCP est dans la grande majorité des cas une image ou un bloc HTML servi directement depuis le serveur. Sans CDN, sans cache de page, chaque visiteur déclenche une génération PHP complète avant que quoi que ce soit ne s’affiche.

Sur des audits menés pour des clients e-commerce et des sites vitrines, on constate régulièrement que le passage d’un hébergement mutualisé à un hébergement dédié avec cache serveur fait passer le LCP de 4-5 secondes à moins de 2 secondes, sans toucher une seule ligne de code WordPress.

L’INP

L’INP dépend principalement du thread principal JavaScript dans le navigateur, ce qui le rend moins directement lié à l’hébergeur. Mais la chaîne de causalité existe. Un serveur lent à délivrer les fichiers JS et CSS retarde leur parsing et leur exécution. Si le navigateur reçoit les scripts avec 800ms de retard, le thread principal reste occupé plus longtemps après le chargement initial, ce qui dégrade la réactivité aux premières interactions.

L’impact est indirect mais existe bel et bien, en particulier sur des pages WordPress chargées de scripts tiers et de plugins. Un hébergement avec HTTP/2 ou HTTP/3 activé qui permet le chargement parallèle des assets réduit ce goulot d’étranglement.

Le CLS : la métrique la plus indépendante du serveur

Le CLS mesure les décalages visuels. Il est presque entièrement conditionné par le code et les choix d’intégration : images sans attributs width et height définis, polices web qui provoquent un FOUT, iframes ou blocs publicitaires dont les dimensions ne sont pas réservées en amont. L’hébergeur n’a pratiquement aucune prise sur ce score.

Ce que l’hébergement dédié à WordPress ne peut pas corriger

Un bon hébergement règle une partie du problème mais pas la totalité. Sur des dizaines d’audits techniques, nous avons pu voir que le même schéma se répète. Des clients changent d’hébergeur, le TTFB s’améliore, mais les Core Web Vitals restent dans le rouge. Et nous leur expliquons que c’est parce que le reste du travail n’a pas été fait.

Les images non optimisées sont la première cause de LCP dégradé indépendamment du serveur. Aucun hébergeur ne peut compenser une image hero de 2Mo servie en PNG sans lazy loading, sans format WebP ou AVIF, et dans de mauvaises dimensions. Le navigateur doit télécharger, décoder et afficher un fichier surdimensionné qui fait s’envoler le LCP. L’optimisation des images est à travailler côté WordPress, ce qui peut être fait via un plugin comme Imagify ou ShortPixel.

Les scripts tiers sont un autre point que ne peut régler un hébergement dédié à WordPress. Plusieurs éléments peuvent ajouter du poids au thread principal :

• Google Tag Manager

• pixels publicitaires

• widgets de chat

• scripts de heatmap…

Un serveur rapide délivre la page vite, mais si le navigateur doit ensuite charger et exécuter quinze scripts externes, l’INP et le LCP en pâtissent. Par exemple, la gestion du chargement différé des scripts tiers et le recours au async ou au defer relèvent entièrement de la configuration WordPress.

Nous avons déjà parlé du CLS lié au DOM, mais il mérite d’être répété. Ce sont des éléments qui se déplacent au chargement car leurs dimensions ne sont pas déclarées. Ce sont par exemple des blocs Gutenberg ou Elementor qui injectent du contenu dynamiquement, des polices qui swappent après affichage. Eh bien tout ça génère du CLS. C’est du code, pas de l’infrastructure.

Comment choisir son hébergement WordPress pour avoir de bons Core Web Vitals ?

Le marché de l’hébergement WordPress est saturé d’offres qui promettent des performances sans toujours les détailler techniquement. Voici selon nous les critères qui comptent quand la performance SEO est votre objectif.

La version de PHP : 8.2 minimum

PHP 8.x apporte des gains de performance substantiels par rapport aux versions 7.x encore trop présentes sur certains hébergements anciens. PHP 8.2 ou 8.3 réduit les temps d’exécution des scripts WordPress, ce qui se répercute directement sur le TTFB. Vérifier la version PHP disponible chez votre hébergeur avant de signer est un réflexe à avoir.

HTTP/2 et HTTP/3

HTTP/2 permet le multiplexage des requêtes. Il s’agit de plusieurs ressources chargées en parallèle sur une seule connexion. HTTP/3, basé sur le protocole QUIC, pousse cette logique plus loin en réduisant la latence sur les connexions instables. Un hébergeur qui aujourd’hui ne supporte pas au minimum HTTP/2 est un hébergeur à éviter pour un site WordPress quand la performance est un grand enjeu.

La localisation du serveur

Chaque requête entre un navigateur et un serveur parcourt une distance physique. Plus le serveur est éloigné de l’utilisateur, plus la latence réseau est élevée. Un serveur localisé en Allemagne ou aux Pays-Bas pour un site ciblant une audience française ajoute quelques dizaines de millisecondes sur chaque requête. Ce n’est pas dramatique, mais ça s’accumule dans le calcul du TTFB et du LCP.

La meilleure option est de choisir un hébergeur dont les datacenters sont localisés en France. Plusieurs acteurs français ou à infrastructure française le proposent. Pour un site dont l’audience est majoritairement française, c’est la garantie d’une latence réseau minimale sans configuration supplémentaire.