Vitals réels
LCP, INP, CLS et TTFB mesurés dans le navigateur de vos vrais visiteurs, par appareil, anonymes par construction.
Mis à jour le 11 septembre 2026
Sur cette page
Un audit mesure une machine de test sur une bonne connexion. Vos visiteurs, eux, ont un téléphone de cinq ans dans un train. Les vitals réels sont ce qu'ils voient : un petit script sur vos pages envoie à PostShip, une fois par page et à son départ, quatre durées et le chemin. Ni cookie, ni identifiant, ni user-agent : le chemin de la page, l'appareil, quatre nombres. C'est le complément du TTFB de PostShip : l'un dit si le serveur va bien, l'autre si la page va bien pour ceux qui la lisent.
Ce que PostShip mesure
Les quatre métriques des Core Web Vitals, et les seuils de Google pour les classer :
| Métrique | Ce que c'est | Bon | À améliorer | Mauvais |
|---|---|---|---|---|
| LCP | Le temps d'affichage du plus grand élément visible | ≤ 2 500 ms | ≤ 4 000 ms | au-delà |
| INP | Le délai de réaction à une interaction (clic, touche), le pire de la page | ≤ 200 ms | ≤ 500 ms | au-delà |
| CLS | Les décalages de mise en page subis sans interaction, la pire fenêtre | ≤ 0,1 | ≤ 0,25 | au-delà |
| TTFB | Le temps avant le premier octet, vu du navigateur | ≤ 800 ms | ≤ 1 800 ms | au-delà |
La page Performance affiche le p75 par appareil (mobile ou ordinateur), sur la fenêtre choisie, avec le nombre de pages vues. Le p75 est le seuil des Core Web Vitals : un quart des visiteurs a pire. « Aucune visite. » quand un appareil n'a rien envoyé.
Poser le snippet
Projet → Intégrations, carte « Vitals réels ».
- Cochez « Accepter les mesures de ce site » et enregistrez. Tant que la case n'est pas cochée, les mesures reçues sont ignorées.
- Copiez le snippet (bouton « Le snippet ») et posez-le dans le
<head>ou avant</body>de toutes vos pages. Le jeton est propre au projet.
<script src="https://postship.fr/rum.js" data-token="VOTRE_JETON" defer></script>Le script tient en une centaine de lignes, ne charge rien d'autre, ne lève jamais d'erreur chez le visiteur, et ne fait rien si le navigateur n'a pas PerformanceObserver.
Ce qui est envoyé, et ce qui ne l'est pas
Un seul envoi par page, au moment où le visiteur la quitte (onglet caché ou fermé), en sendBeacon pour survivre à la fermeture :
{ "p": "/pricing", "d": "mobile", "lcp": 2140, "inp": 96, "ttfb": 412, "cls": 0.032 }p: le chemin seul, jamais la requête ni le fragment, parce que c'est là que vivent les jetons, les identifiants de session et les adresses pré-remplies. Ce qui n'est pas stocké ne peut pas fuir. 200 caractères au plus.d:mobilesi le pointeur principal est tactile,desktopsinon. Rien d'autre sur l'appareil.- Les durées en millisecondes entières, le CLS au millième. Une métrique absente (un navigateur sans INP) est simplement omise ; une métrique absurde (au-delà de 120 s, un onglet resté ouvert) est ignorée sans rejeter les trois autres.
Côté PostShip : l'origine de l'envoi doit être le domaine du projet, avec ou sans www. (beaucoup de sites servent les deux), sinon la mesure est refusée. Un jeton copié sur un autre site ne pollue donc pas vos chiffres. Le débit est limité à 120 envois par minute et par adresse, sans que l'adresse soit conservée. Tout refus répond sans détail : le navigateur du visiteur ne lira jamais la réponse.
Le même script porte aussi les erreurs des visiteurs : erreurs JavaScript, promesses rejetées, ressources introuvables, envoyées par petits lots sur la même route.
Ce qui déclenche une alerte
Rien pour les vitals eux-mêmes : ce sont des mesures à lire sur la page Performance, sur la même fenêtre que le reste. L'alerte liée au snippet est celle des erreurs des visiteurs après un déploiement. Pour une alerte sur la vitesse, voir le budget de performance (PageSpeed après chaque déploiement) et les anomalies de latence.
Limites et plans
| Free | Pro | Team | |
|---|---|---|---|
| Snippet et vitals réels | Oui | Oui | Oui |
| Mesures conservées | 7 jours | 14 jours | 30 jours |
Les mesures suivent la rétention du plan, comme le reste de l'historique. Voir les plans et Données et rétention.
Dépannage
Pourquoi « Aucune visite » alors que le snippet est posé ?
Vérifiez que la case « Accepter les mesures de ce site » est cochée, que le domaine de base du projet est bien celui qui sert les pages (le protocole compte : http:// et https:// sont deux origines), et attendez quelques visites : le beacon part au départ du visiteur, pas à l'arrivée.
Pourquoi le mobile est bien pire que l'ordinateur ?
C'est presque toujours vrai, et c'est pour ça que les deux sont séparés. Le p75 mobile est celui que Google regarde en premier.
Pourquoi le CLS est à 0 alors que ma page bouge ?
Les décalages provoqués par une interaction du visiteur (un clic qui ouvre un menu) ne comptent pas, par définition. Un CLS à 0 veut dire « l'observateur existe et n'a rien vu » ; un navigateur qui ne sait pas mesurer n'envoie rien.