Vitesse site web et hébergement : Core Web Vitals expliqués

Vitesse de site web : les quatre indicateurs à connaître

La vitesse d’un site web dépend à la fois de l’hébergement et du site lui-même, et le premier réflexe utile est de séparer les deux. Google résume cette vitesse par trois Core Web Vitals (LCP, INP, CLS), mesurés sur les visites réelles des utilisateurs de Chrome, et par un indicateur de diagnostic, le TTFB, qui isole la part du serveur.

LCP (Largest Contentful Paint) : le délai d’affichage du plus grand élément visible à l’écran, en général l’image principale ou le bloc de titre. Seuil « bon » : 2,5 s au plus.
INP (Interaction to Next Paint) : le délai entre une action de l’utilisateur (clic, touche, saisie) et la mise à jour visible de la page, en retenant la pire interaction de la visite. Seuil « bon » : 200 ms au plus. INP a remplacé FID en mars 2024.
CLS (Cumulative Layout Shift) : la somme des décalages de mise en page subis sans action de l’utilisateur, comme un bouton qui descend quand une bannière se charge. Seuil « bon » : 0,1 au plus.
TTFB (Time to First Byte) : le délai entre la demande du navigateur et le premier octet reçu ; il comprend le DNS, la connexion TLS et la génération de la page par le serveur. web.dev recommande de rester sous 800 ms.

Indicateur	Bon	À améliorer	Médiocre	Dépend surtout de
LCP	≤ 2,5 s	2,5 s à 4 s	> 4 s	Hébergement et site
INP	≤ 200 ms	200 à 500 ms	> 500 ms	Site
CLS	≤ 0,1	0,1 à 0,25	> 0,25	Site
TTFB	≤ 800 ms	800 à 1 800 ms	> 1 800 ms	Hébergement

Google évalue chaque indicateur au 75e percentile des visites : trois visites sur quatre doivent passer le seuil, et le mobile est jugé séparément du bureau. Un site rapide sur votre poste fibré peut donc être classé « médiocre » sur mobile.

Ce que l’hébergement change vraiment dans la vitesse d’un site web

L’hébergement agit sur tout ce qui se passe avant que le navigateur reçoive le premier octet, puis sur la rapidité de transfert des fichiers. Il pèse directement sur le TTFB, indirectement sur le LCP, et presque pas sur l’INP ni le CLS. Pour une page dynamique, le serveur exécute PHP, interroge la base de données puis renvoie le HTML : ce temps de génération représente en général la plus grosse part du TTFB, et sept leviers relèvent de l’hébergeur ou de votre formule.

La version de PHP et OPcache

PHP 8.x exécute le même code plus vite que PHP 7, et OPcache garde en mémoire le code compilé au lieu de le relire à chaque visite. Sur un hébergement NovaHoster, PHP 8.x avec OPcache se choisit dans Plesk ; vérifiez que votre site n’est pas resté sur une version antérieure.

Le disque NVMe

Chaque page WordPress ou PrestaShop lit des dizaines de fichiers et exécute plusieurs requêtes SQL. Un disque NVMe sert ces lectures bien plus vite qu’un disque SATA ou mécanique. Les formules d’hébergement web mutualisé NovaHoster reposent sur du NVMe.

Le cache serveur

Un cache de pages côté serveur conserve le HTML déjà généré et le sert sans relancer PHP : pour un visiteur anonyme, le TTFB passe de plusieurs centaines de millisecondes à quelques dizaines. L’hébergement WordPress intègre un cache serveur ; une extension de cache reste utile pour les pages que le serveur ne met pas en cache.

HTTP/2 et la compression

HTTP/2 charge plusieurs fichiers sur une seule connexion, ce qui réduit l’attente des CSS, scripts et images. La compression gzip ou Brotli réduit le poids du HTML, du CSS et du JavaScript, souvent de plus de moitié. Les deux se vérifient en une commande.

Les limites CPU et LVE

Sur un mutualisé CloudLinux, chaque compte dispose d’un quota de CPU, de mémoire et de processus simultanés. Un site qui touche sa limite ralentit ou renvoie une erreur 508 aux heures de pointe. Le guide pour comprendre CloudLinux, LVE et CageFS détaille comment lire ces indicateurs dans Plesk et distinguer une limite atteinte d’un bug applicatif.

La localisation du serveur

Chaque aller-retour entre le navigateur et le serveur coûte quelques millisecondes par millier de kilomètres, multipliées par les étapes DNS, TCP et TLS. Un serveur en France réduit ce coût fixe pour un public français. Les offres mutualisées, WordPress, e-commerce et dédiées NovaHoster sont hébergées dans des datacenters en France.

Ce qui dépend du site et que l’hébergeur ne corrigera pas

Une fois le premier octet reçu, le navigateur doit télécharger, exécuter et afficher ce que le site lui envoie. Cette partie dépend du thème, des extensions et du contenu, pas du serveur. Changer d’hébergeur n’y change rien.

Images : une photo de 4 000 pixels affichée en 800 pixels, ou en PNG au lieu de WebP, retarde le LCP et provoque un CLS si ses dimensions ne sont pas déclarées.
Thème : un thème « tout-en-un » charge souvent des centaines de kilooctets de CSS et de JavaScript pour une page simple, ce qui occupe le processeur du téléphone.
Extensions : un constructeur de pages, un slider, un module de réservation ajoutent chacun leurs scripts, souvent sur toutes les pages.
Scripts tiers : statistiques, pixels publicitaires, widgets de chat, vidéos intégrées. Ils viennent de serveurs que vous ne contrôlez pas et dégradent surtout l’INP.
Polices : une police chargée depuis un service externe arrive après le texte, qui se redessine avec un décalage visible (CLS) et un LCP retardé quand le titre en dépend.

La règle de lecture est simple : un TTFB correct avec un LCP médiocre désigne le site ; un TTFB élevé désigne d’abord le serveur ou l’absence de cache. L’INP et le CLS désignent presque toujours le site.

Mesurer la vitesse de son site en 10 minutes

Trois outils gratuits suffisent pour un premier diagnostic : comment les visiteurs réels vivent le site, quelles pages Google juge lentes, et combien de temps le serveur met à répondre.

PageSpeed Insights (3 minutes). Testez la page d’accueil puis une page intérieure représentative (fiche produit, article), en mobile et en ordinateur. Lisez d’abord le bloc consacré aux utilisateurs réels : ce sont les données de terrain du rapport d’expérience utilisateur Chrome, sur 28 jours. Le score Lighthouse en dessous est une simulation en laboratoire, utile pour trouver des pistes, pas pour juger.
Search Console, rapport « Signaux Web essentiels » (2 minutes). Dans la propriété du site, menu « Expérience », le rapport regroupe les URL par problème (« LCP supérieur à 2,5 s », « CLS supérieur à 0,1 ») et par gabarit. Notez le nombre d’URL « médiocres » et « à améliorer » : c’est votre point de départ.
curl pour le TTFB (5 minutes). Depuis un terminal (macOS, Linux, ou Windows avec WSL), lancez la commande ci-dessous en remplaçant le domaine. Elle affiche chaque étape du chargement en secondes.

curl -o /dev/null -s -w "DNS : %{time_namelookup}s\nConnexion TCP : %{time_connect}s\nTLS : %{time_appconnect}s\nTTFB : %{time_starttransfer}s\nTotal : %{time_total}s\n" https://www.exemple.fr/

Lancez-la trois fois de suite et gardez la valeur médiane. Pour vérifier HTTP/2 et la compression, une seconde commande suffit :

curl -sI --compressed https://www.exemple.fr/ | grep -i -E "^HTTP/|content-encoding|cache-control|x-cache"

La première ligne doit afficher HTTP/2 200 et content-encoding doit valoir gzip ou br. Un en-tête x-cache ou équivalent indique si la page vient du cache serveur (HIT) ou vient d’être générée (MISS).

TTFB élevé : lire la ligne de temps et isoler la part du serveur

Les valeurs de curl sont cumulatives : chaque étape inclut les précédentes, et la lecture consiste à soustraire. Un TTFB élevé peut venir de quatre endroits, chacun avec un responsable distinct.

Écart observé	Interprétation	Piste
`time_namelookup` élevé	Résolution DNS lente	Serveurs DNS du domaine ; vérifiez la zone DNS
`time_connect` − `time_namelookup` élevé	Distance réseau ou serveur injoignable	Localisation du serveur, incident réseau, filtrage
`time_appconnect` − `time_connect` élevé	Négociation TLS lente	Chaîne de certificats longue, serveur chargé
`time_starttransfer` − `time_appconnect` élevé	Génération de la page par PHP et la base	Absence de cache, extension lente, requête SQL coûteuse, limite LVE

Le dernier écart domine dans la grande majorité des cas. Pour confirmer que le cache serveur fait son travail, comparez l’URL normale avec la même URL suivie d’un paramètre inutile du type ?test=1 : beaucoup de caches ignorent les URL avec paramètres et génèrent la page à neuf. Si la seconde mesure est nettement plus lente, le cache fonctionne et le problème se limite aux pages non cachées (panier, compte client, administration).

Mesurez aussi un fichier statique du même site, par exemple robots.txt. Si son TTFB est bas alors que celui de l’accueil est élevé, le serveur répond vite et c’est l’application qui prend du temps. Si les deux sont élevés, la cause se situe en amont de PHP : réseau, DNS, TLS ou serveur saturé.

Symptôme, cause probable, qui corrige : le tableau de diagnostic

La colonne « Qui corrige » indique si l’action relève de l’hébergeur, du propriétaire du site, ou des deux.

Symptôme	Cause probable	Qui corrige
TTFB élevé sur toutes les pages, fichiers statiques compris	Serveur saturé, réseau, DNS ou TLS lents	Hébergeur
TTFB élevé sur les pages dynamiques, bas sur les fichiers statiques	Pas de cache de pages, extension lente, requêtes SQL coûteuses	Site ; hébergeur pour le cache serveur
TTFB correct, LCP médiocre	Image principale lourde, CSS bloquant, police externe	Site
INP médiocre, surtout sur mobile	JavaScript du thème ou des extensions, scripts tiers, constructeur de pages	Site
CLS médiocre	Images sans largeur et hauteur, bannière de consentement injectée, police qui change la hauteur du texte	Site
Lenteurs aux heures de pointe, erreurs 508	Limite CPU ou processus LVE atteinte	Site (réduire la charge) ou hébergeur (formule avec plus de ressources)
Lenteur seulement dans l’administration	Pages non cachées, extension qui appelle un service externe, cron lourd	Site
Ni compression ni HTTP/2 dans les en-têtes	Configuration serveur ou règle `.htaccess` qui désactive la compression	Hébergeur, après vérification du `.htaccess` par le site

Quand une ligne pointe vers l’hébergeur, joignez au ticket les trois mesures curl, l’heure exacte et l’URL testée : le support peut alors comparer avec la charge du serveur au même moment.

Plan d’action priorisé pour accélérer son site

L’ordre va du geste le plus rentable au plus coûteux. Mesurez avant et après chaque étape.

Passer sur PHP 8.x et vérifier OPcache. Dans Plesk, « Paramètres PHP » du domaine, choisissez la version 8.x la plus récente compatible avec vos extensions et contrôlez que opcache.enable est actif. Effet : TTFB en baisse sur toutes les pages dynamiques.
Activer un cache de pages. Cache serveur de la formule quand il existe, complété par une extension de cache pour le CMS. Effet : TTFB divisé par plusieurs sur les pages publiques.
Traiter l’image LCP. Identifiez l’élément LCP dans PageSpeed Insights, redimensionnez l’image à la taille d’affichage, convertissez-la en WebP et retirez son chargement différé. Effet : LCP souvent ramené sous 2,5 s.
Retirer les extensions inutiles et les scripts tiers superflus. Désactivez une extension à la fois sur un environnement de test et mesurez l’INP. Une vidéo intégrée en page d’accueil se remplace par une image cliquable.
Déclarer les dimensions des images et héberger les polices sur votre domaine avec font-display: swap, et réserver l’espace des bannières. Effet : CLS sous 0,1.
Vérifier HTTP/2 et la compression avec la commande curl vue plus haut. En cas d’absence, vérifiez d’abord votre .htaccess, puis ouvrez un ticket.
Surveiller les limites LVE dans Plesk pendant une semaine. Si le CPU plafonne chaque jour aux mêmes heures malgré le cache, déplacez les tâches planifiées la nuit ou passez à une formule avec plus de ressources.
Changer d’hébergeur seulement si le TTFB sur fichier statique reste élevé après les étapes précédentes. C’est la dernière étape, pas la première.

Site lent, hébergeur en cause ? Liste de contrôle avant de changer

Beaucoup de migrations sont décidées sur une impression. Avant de conclure que l’hébergeur est responsable d’un site lent, cochez les points suivants ; sinon, la migration déplacera le problème sans le résoudre.

Le TTFB d’un fichier statique (robots.txt) dépasse régulièrement 500 ms depuis la France, à des heures différentes.
Les en-têtes ne montrent ni HTTP/2 ni content-encoding, et aucune règle de votre .htaccess ne l’explique.
Le site tourne déjà sur PHP 8.x avec OPcache actif et un cache de pages fonctionnel (réponse HIT sur l’accueil).
Les limites CPU ou mémoire sont atteintes chaque jour malgré le tri des extensions et des tâches cron.
Le serveur se trouve hors de la zone géographique de vos visiteurs.
Le support n’explique pas les écarts de charge aux heures de lenteur.

Si vous changez, exigez ce que vous venez de vérifier : PHP 8.x, OPcache, disques NVMe, cache serveur, serveur en France pour un public français, limites de ressources connues à l’avance. Chez NovaHoster, la migration est gratuite en 24 h et la période satisfait ou remboursé de 30 jours permet de refaire les mesures avant de s’engager ; le support 7j/7 assuré par des développeurs peut relire vos mesures curl.

WordPress, e-commerce et suivi dans le temps

Chaque CMS a ses pièges. Pour WordPress, le guide pour sauvegarder, accélérer et sécuriser WordPress détaille cache, images et tri des extensions. Pour une boutique, le guide sur la performance e-commerce et le traitement des incidents traite le panier et le tunnel de paiement, qui ne peuvent pas être mis en cache et dépendent donc du TTFB brut.

Les données de terrain portent sur 28 jours glissants : un correctif met jusqu’à un mois à se refléter dans le rapport « Signaux Web essentiels ». Prenez une capture du rapport avant les travaux, puis revenez tous les quinze jours.

Pour suivre en parallèle l’évolution du positionnement et repérer les pages qui perdent du trafic, la plateforme Zerkado regroupe audit technique et suivi de positions. Les Core Web Vitals ne sont qu’un des signaux pris en compte par Google : une page lente mais pertinente peut rester bien placée. L’objectif raisonnable est de sortir de la zone « médiocre » sur les gabarits qui comptent (accueil, catégories, fiches produits, articles), puis de tenir ce niveau à chaque mise à jour.

Questions fréquentes

Quel TTFB viser pour un site hébergé en France ?

web.dev considère qu’un TTFB reste bon jusqu’à 800 ms et devient médiocre au-delà de 1 800 ms. En pratique, une page servie depuis le cache d’un serveur en France répond souvent en moins de 200 ms depuis la France. Une page dynamique non cachée dépasse facilement 500 ms. Mesurez avec curl trois fois et comparez la page d’accueil avec un fichier statique.

Changer d’hébergeur améliore-t-il les Core Web Vitals ?

Seulement en partie. Un meilleur hébergement réduit le TTFB, donc le LCP, grâce à PHP 8, OPcache, NVMe, cache serveur et proximité géographique. Il ne change rien à l’INP ni au CLS, qui dépendent du JavaScript, des images et des polices du site. Vérifiez d’abord le TTFB d’un fichier statique avant de décider une migration.

Pourquoi PageSpeed Insights n’affiche-t-il pas de données réelles pour mon site ?

Les données de terrain proviennent du rapport d’expérience utilisateur Chrome, qui ne publie des valeurs que si la page ou l’origine reçoit suffisamment de visites sur 28 jours. Un site récent ou à faible trafic n’y figure pas. Appuyez-vous alors sur les données de laboratoire et sur une mesure du TTFB avec curl, en acceptant une marge d’incertitude.

Un cache serveur suffit-il pour accélérer son site ?

Il règle la part serveur pour les visiteurs anonymes et fait chuter le TTFB. Il ne réduit ni le poids des images, ni le JavaScript du thème, ni les scripts tiers, qui continuent de peser sur le LCP, l’INP et le CLS. Les pages personnalisées (panier, compte client, administration) ne sont pas mises en cache et révèlent la vitesse réelle du serveur.

Comment savoir si mon site lent vient d’une limite CPU de l’hébergeur ?

Ouvrez l’outil d’usage des ressources CloudLinux dans Plesk et comparez les heures de lenteur avec les pics de CPU, de mémoire ou de processus entrants. Une erreur 508 confirme une limite atteinte. Si le site atteint son quota alors que le cache fonctionne et que les extensions inutiles sont retirées, il faut plus de ressources ; sinon, c’est l’application qu’il faut alléger.

La localisation du serveur compte-t-elle vraiment pour la vitesse ?

Oui, pour le coût fixe de chaque connexion. DNS, poignée de main TCP et négociation TLS exigent plusieurs allers-retours, et chacun coûte d’autant plus que le serveur est loin. Pour un public français, un serveur en France réduit ce délai sur chaque page. Pour un public international, un CDN complète un serveur bien placé.

INP a-t-il remplacé FID, et que faut-il changer ?

Oui, depuis mars 2024, INP remplace FID parmi les Core Web Vitals. FID ne mesurait que le délai de la première interaction ; INP retient la pire interaction de toute la visite, ce qui rend l’indicateur plus exigeant. Les sites chargés en JavaScript, en scripts tiers ou en constructeurs de pages sont les plus touchés. Le seuil bon est de 200 ms.

Guides liés

Pour aller plus loin sur le même sujet, et sur ce qui l’entoure :

Sources techniques

[1] web.dev — Largest Contentful Paint (LCP) [2] web.dev — Interaction to Next Paint (INP) [3] web.dev — Cumulative Layout Shift (CLS) [4] web.dev — Time to First Byte (TTFB) [5] Google Search Central — Comprendre les Core Web Vitals et les résultats de recherche Google

Votre situation ne correspond pas exactement à ce guide ?

Les options visibles et les formules dépendent de votre abonnement. Faites vérifier le contexte depuis l’Espace client, sans transmettre de mot de passe.

Demander une vérification

Vitesse de site web et Core Web Vitals : ce que l’hébergement change vraiment (TTFB, LCP, INP, CLS)