# LCP, INP, CLS : la part qui revient à l'hébergeur

> Core Web Vitals et hébergement : ce qui dépend du serveur (le TTFB, donc le LCP) et ce qui n'en dépend presque pas (INP, CLS), seuils et lecture de CrUX.


*Ou : on ne repeint pas la façade pour réparer une porte qui grince.*

La réponse courte : l'hébergeur pèse sur une seule des trois Core Web Vitals de Google, le LCP, et par un seul canal, le temps de réponse du serveur. [Selon web.dev](https://web.dev/articles/vitals), une page offre une bonne expérience quand son plus grand élément visible s'affiche en 2,5 secondes ou moins (LCP), qu'elle réagit aux interactions en 200 millisecondes ou moins (INP) et que sa mise en page bouge peu (un CLS de 0,1 ou moins), au 75e centile des visites. L'INP et le CLS dépendent du code de la page, du JavaScript, des scripts tiers et des dimensions réservées aux images, pas de la machine qui les sert. Changer d'hébergeur pour corriger un mauvais CLS ne sert à rien ; c'est la limite à garder en tête quand on juge [les performances d'un hébergement](/guides/hebergement-web/vitesse-disponibilite-hebergeur/).

Le TTFB, le délai avant le premier octet, n'est pas une Core Web Vital, mais il entre dans le LCP : web.dev recommande qu'il n'en occupe qu'environ 40 %. Le calcul est vite fait. Un serveur qui répond en 1,2 seconde laisse 1,3 seconde pour télécharger et afficher l'image principale ; un serveur qui répond en 0,3 seconde en laisse 2,2.

> **Pour qui** : un site dont PageSpeed Insights signale un LCP lent avec un TTFB au-dessus de 0,8 seconde, signe que le serveur est en cause.
>
> **À partir de** : 5,75 € par mois hors taxes pour l'hébergement web Infomaniak, facturés à l'année (relevé du 12 novembre 2026).
>
> **Pour démarrer** : copier une page représentative sur l'hébergement web Infomaniak pendant l'essai de 30 jours, comparer son TTFB et son LCP de laboratoire, puis décider de déplacer le reste.

## Core Web Vitals et hébergement : séparer ce qui vient du serveur

| Métrique | Bon | Mauvais | Part de l'hébergeur | Ce qui la dégrade d'abord |
|---|---|---|---|---|
| LCP | 2,5 s ou moins | plus de 4 s | le TTFB, environ 40 % du budget recommandé | serveur lent, image principale lourde ou chargée tard |
| INP | 200 ms ou moins | plus de 500 ms | presque nulle | JavaScript lourd, scripts tiers |
| CLS | 0,1 ou moins | plus de 0,25 | nulle | images sans dimensions, bandeaux injectés, polices |
| TTFB (repère) | 0,8 s ou moins | plus de 1,8 s | presque tout | serveur, cache, distance |

Seuils de [la documentation de PageSpeed Insights](https://developers.google.com/speed/docs/insights/v5/about), relevés le 12 novembre 2026.

Le LCP se découpe lui-même en quatre parts, que [le guide d'optimisation du LCP de web.dev](https://web.dev/articles/optimize-lcp) répartit ainsi pour une page bien construite : environ 40 % pour le TTFB, moins de 10 % pour le délai avant que l'image principale ne commence à charger, environ 40 % pour son téléchargement, moins de 10 % pour son rendu. Seule la première part appartient vraiment à l'hébergeur. La troisième en dépend un peu, par le débit et la compression ; les deux autres, pas du tout.

![Illustration : une tarte coupée en parts sur une assiette sombre, une part écartée et éclairée d'une lumière ambre](/images/core-web-vitals-part-hebergeur-part.original.webp "Dans le LCP, l'hébergeur a droit à une part, rarement à la tarte entière.")

Le terrain confirme que le premier octet reste le maillon faible. En juillet 2025, selon [le chapitre performance du Web Almanac](https://almanac.httparchive.org/en/2025/performance), la part des sites jugés bons s'établissait ainsi :

| Mesure | Sur mobile | Sur ordinateur |
|---|---|---|
| TTFB | 44 % | 55 % |
| LCP | 62 % | 74 % |
| INP | 77 % | 97 % |
| CLS | 81 % | 72 % |
| Les trois Core Web Vitals | 48 % | 56 % |

La méthode pour faire la part des choses sur votre propre site tient en trois lectures dans PageSpeed Insights :

1. **Les données de terrain d'abord.** Elles viennent du rapport CrUX, collecté auprès des utilisateurs de Chrome qui ont activé la synchronisation et les statistiques d'usage, sur les 28 derniers jours. Une page doit être publique et assez visitée pour y figurer, selon [la méthodologie de CrUX](https://developer.chrome.com/docs/crux/methodology) ; un petit site n'y figure parfois qu'à l'échelle de l'origine, toutes pages confondues, voire pas du tout.
2. **Le TTFB à côté du LCP.** TTFB au-dessus de 0,8 seconde et LCP mauvais : le serveur, le cache ou la distance sont en cause. TTFB bon et LCP mauvais : regardez l'image principale, son poids et le moment où elle est découverte.
3. **INP et CLS à part.** S'ils sont mauvais, la réponse est dans le code, les extensions et les scripts publicitaires ou de mesure d'audience. Aucun hébergeur ne les corrige.

Les données de laboratoire, celles de Lighthouse, servent ensuite à reproduire le problème, pas à le constater. Google, de son côté, recommande d'obtenir de bonnes Core Web Vitals, qui rejoignent selon lui ce que ses systèmes de classement cherchent à récompenser.

### Quand le TTFB mange le budget

Si le premier octet arrive après une seconde, aucune compression d'image ne sauvera le LCP. La mesure du TTFB, poste par poste, avec curl, se trouve dans [réduire le temps de réponse](/guides/hebergement-web/vitesse-disponibilite-hebergeur/ttfb-temps-reponse-serveur/).

### Servir la page sans la recalculer

Un cache de page côté serveur ramène souvent le TTFB d'une page dynamique au niveau d'un fichier statique. Ce que l'hébergeur doit fournir pour cela est détaillé dans [un cache côté serveur](/guides/hebergement-web/vitesse-disponibilite-hebergeur/cache-serveur-navigateur-cdn/).

### Des visiteurs loin du serveur

Les données CrUX mélangent tous vos visiteurs. Si une part d'entre eux est sur un autre continent, leur latence tire le 75e centile vers le haut, ce qu'explique [la localisation du serveur](/guides/hebergement-web/vitesse-disponibilite-hebergeur/localisation-serveur-latence/).


---

Cette page contient des liens d'affiliation. Si tu souscris via ces liens, je peux toucher une commission sans coût supplémentaire pour toi. Mon avis reste indépendant et s'appuie sur mon expérience de client de plusieurs hébergeurs, sur leur documentation officielle et sur les tarifs vérifiés à la date de rédaction.


---

**Tarifs :** prix relevés le 12 novembre 2026 sur les sites officiels des hébergeurs et des registrars, en euros sauf mention contraire, hors taxes ou toutes taxes comprises selon ce que le fournisseur affiche (précisé dans le texte). Le prix d'appel ne vaut souvent que pour la première période d'engagement, et les promotions changent sans préavis. Les montants cités peuvent avoir bougé depuis cette date.

