Performance
Le temps de réponse de chaque page dans le temps, l'avant/après déploiement, et la bande « normal ».
Mis à jour le 11 septembre 2026
Sur cette page
Chaque vérification d'une URL enregistre son temps de réponse, le TTFB : le temps que met la page à commencer à répondre, mesuré depuis le serveur de PostShip. La page Performance répond à la seule question qu'on se pose devant ces mesures, « est-ce que mon site ralentit, et depuis quand » : la médiane, le 95e centile, la courbe, et la comparaison avant/après le dernier déploiement. Ce que vos visiteurs mesurent, eux, est sur Vitals réels.
Ce que PostShip mesure
Seules les URL de sorte HTTP, formulaire et parcours portent un temps de réponse qui veut dire « la page » : un certificat ou un sitemap en ont un aussi, mais personne ne les attend derrière un navigateur. Pour chaque URL, sur la fenêtre choisie :
| Colonne | Sens |
|---|---|
| p50 | La médiane : l'expérience courante |
| p95 | Le 95e centile : le visiteur sur vingt qui attend le plus |
| max | Le pire passage |
| n | Le nombre de mesures |
Le résumé en tête de page nomme la page la plus lente et ce qu'elle vaut : « La page la plus lente est /checkout : 640 ms en médiane, 1 200 ms pour le visiteur sur vingt le moins chanceux. »
Les allures
Les seuils sont ceux de la perception, pas de l'infrastructure : sous 200 ms on ne voit rien, sous 500 ms on ne s'en plaint pas, sous une seconde on attend, au-delà on part.
| Allure | Médiane |
|---|---|
| Rapide | moins de 200 ms |
| Correct | de 200 à 499 ms |
| Lent | de 500 à 999 ms |
| Très lent | 1 000 ms et plus |
Les fenêtres
24 h (une colonne par heure), 7 jours (une colonne par jour, la fenêtre par défaut), 30 jours. Une fenêtre plus longue que la rétention du plan est fermée, avec la raison : « Votre plan conserve 14 jours d'historique. 30 jours demande d'en garder davantage. » Un lien vers une fenêtre fermée redescend à la plus grande disponible plutôt que d'afficher une erreur.
Les trous sont gardés : une courbe qui relierait deux points mesurés masquerait une interruption de surveillance.
La courbe
Un graphique commun à toutes les URL, à la même échelle, parce que la comparaison entre pages est l'intérêt du graphique. Les cinq plus lentes sont allumées au départ ; cliquez une URL pour l'allumer ou l'éteindre. Trois choses de plus sont dessinées :
- Les déploiements de production de la fenêtre : un trait fin vertical, avec le SHA. Un ralentissement est presque toujours un ship, et le trait est là pour le voir.
- La bande « normal » : quand une seule courbe est allumée, la zone grisée est la médiane ± 2 écarts robustes de cette page à cette heure de la semaine, sur 14 jours, soit 95 % des passages habituels. Plus étroite que le seuil d'alerte, exprès : le graphique montre l'habitude, l'alerte ne sonne que bien au-delà. Sans référence pour un créneau, un blanc. Voir Anomalies de latence.
- Les points d'anomalie : un point rouge à l'instant exact d'un passage consigné « anormalement lent », avec sa phrase : « 3× plus lent que d'habitude à cette heure (1 850 ms contre 600 ms en temps normal) ».
Avant / après le dernier déploiement
La comparaison la plus utile n'est pas « cette semaine contre la précédente » : c'est depuis le dernier déploiement contre avant. La section « Depuis le dernier déploiement » met côte à côte, URL par URL, la médiane des 24 heures avant et celle des 24 heures après le dernier déploiement de production.
- Il faut 5 mesures au moins de chaque côté, sinon la médiane n'est qu'une coïncidence : « Pas assez de mesures des deux côtés pour comparer — il en faut cinq au moins par URL, dans les vingt-quatre heures avant et après. »
- Une URL est dite ralentie ou accélérée quand l'écart dépasse à la fois 20 % et 50 ms. Les deux, parce que passer de 10 à 13 ms est un bruit de mesure, et passer de 800 à 900 ms n'est que douze pour cent. Sinon, stable.
- Une URL absente d'un côté (ajoutée hier) est écartée plutôt que comparée à zéro.
- Les ralentissements d'abord, les plus forts en tête : « 2 page(s) ont ralenti depuis ce déploiement. », avec
420 → 640 mset le pourcentage. Ou « Aucune page n'a ralenti. »
La comparaison demande un déploiement enregistré : webhook ou détection par empreinte.
Le reste de la page
- Vitals réels et Erreurs des visiteurs, sur la même fenêtre, si le snippet est posé : voir Vitals réels et Erreurs des visiteurs.
- CSV : le lien en tête exporte les mesures de la fenêtre, voir Exports.
Ce qui déclenche une alerte
La page Performance n'alerte pas par elle-même. Trois mécanismes le font : le seuil de latence fixé sur une URL (« a mis 2 300 ms à répondre (seuil : 1 500 ms) »), les anomalies de latence (quand une page sort de son rythme), et le budget de performance mesuré par PageSpeed après chaque déploiement.
Limites et plans
| Free | Pro | Team | |
|---|---|---|---|
| Fenêtres disponibles | 24 h, 7 jours | 24 h, 7 jours | 24 h, 7 jours, 30 jours |
| Mesures conservées | 7 jours | 14 jours | 30 jours |
| Bande « normal » | Oui | Oui | Oui |
| Points d'anomalie sur la courbe | Non | Oui | Oui |
Voir les plans et Données et rétention.
Dépannage
Pourquoi la page dit « Pas encore de mesure » ?
Aucune URL de sorte HTTP, formulaire ou parcours n'a encore été vérifiée. Ajoutez une URL ou attendez le prochain passage.
Pourquoi la comparaison avant/après est vide ?
Pas de déploiement de production enregistré, ou moins de cinq mesures d'un côté : sur un plan à 30 minutes, 24 heures font 48 passages, mais un déploiement d'il y a une heure n'en a que deux « après ».