Performance

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 :

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 20 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.

Les fenêtres

24 h (un point par quart d'heure), 7 jours (un point toutes les 2 heures, la fenêtre par défaut), 30 jours (un point toutes les 6 heures), 90 jours (un point toutes les 18 heures). Les 4 fenêtres arrivent avec la page : basculer de l'une à l'autre est immédiat. Une fenêtre plus longue que la rétention du plan est fermée, avec la raison : « Votre plan conserve 7 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 2 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 5 plus lentes sont allumées au départ ; cliquez une URL pour l'allumer ou l'éteindre. 3 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 5 au moins par URL, dans les 24 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 12 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 pages ont ralenti depuis ce déploiement. », avec 420 → 640 ms et 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. 3 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

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 5 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 2 « après ».

Seuil de latence

Transformer un temps de réponse trop long en échec, donc en alerte, donc en incident.

Une page qui met 3 secondes à commencer à répondre n'est pas « en ligne » pour celui qui l'attend. La vérification HTTP ne regarde pourtant que le statut. Le seuil de latence pose une limite en millisecondes sur une URL : au-delà, le passage échoue comme pour une erreur. C'est la différence entre voir la lenteur sur la page Performance après coup, et être prévenu pendant.

Ce que PostShip vérifie

À chaque passage d'une cible HTTP, PostShip mesure le TTFB — le temps entre l'envoi de la requête et le premier octet de la réponse, redirections comprises, depuis ses serveurs. Cette mesure est toujours enregistrée et alimente Performance.

Avec un seuil réglé, la règle est simple : si le TTFB mesuré dépasse le seuil, le passage porte le manque ttfb_depasse:<seuil>:<mesure> et son verdict est fail. Un seuil vide ou nul ne fait rien.

Ce que ça mesure, et ce que ça ne mesure pas : le TTFB dit combien de temps votre serveur met à commencer à répondre — génération de page, base de données, cache manqué. Il ne dit rien du rendu dans le navigateur ; pour ça, il y a les vitals réels et le budget de performance.

Régler

Sur le détail de l'URL (Projet → URLs → l'URL), panneau « Seuil de latence » :

1. Saisissez une valeur dans le champ Millisecondes : entre 50 et 60 000, par pas de 50. Le champ suggère 800.
2. Cliquez sur « Enregistrer ». Le panneau confirme : « Alerte au-delà de 800 ms. »
3. Pour retirer le seuil, videz le champ et enregistrez : « Seuil de latence retiré. »

Hors de ces bornes, l'enregistrement est refusé : « Un seuil entre 50 et 60 000 ms. »

Le seuil est propre à chaque URL. Une page d'accueil servie par le CDN et un tableau de bord généré à la demande n'ont pas la même normale, et un seuil global forcerait l'un des deux à se taire ou à crier.

Ce qui déclenche une alerte

L'empreinte du passage garde le seuil mais pas la mesure : ttfb_depasse:800:1243 puis ttfb_depasse:800:1301 sont la même panne. Sans cela, une page lente aurait alerté à chaque cycle, 5 minutes sur 5. Vous recevez une alerte au franchissement — après la confirmation réglée pour le projet — puis « Rétabli » quand la page repasse sous le seuil.

Un dépassement compte comme n'importe quel échec HTTP : il ouvre un incident, apparaît sur la page de statut et coûte 10 points au Ship Score s'il survient sur un déploiement (40 si la page fait partie des pages de paiement).

Limites et plans

Le seuil de latence est disponible sur tous les plans, sur toute cible HTTP. Ce qui change avec le plan est la fréquence de la mesure : toutes les 5 minutes sur Découverte, toutes les 2 sur Pro, chaque minute sur Pro Plus, où la sonde de 30 secondes relance la mesure complète dès qu'une page franchit le seuil. Pour être prévenu d'une lenteur inhabituelle sans poser de seuil — une page qui sort de son rythme à cette heure-là — voyez Anomalies de latence (Pro et Pro Plus).

Dépannage

Pourquoi le TTFB de PostShip est plus haut que celui de mon navigateur ?

PostShip mesure depuis ses serveurs, avec une connexion neuve à chaque passage (pas de connexion gardée ouverte, pas de cache), et le temps inclut les redirections suivies. Comparez à la valeur habituelle affichée sur Performance, pas à votre onglet Réseau. Sur Pro Plus, Régions mesure depuis 5 continents pour distinguer une lenteur locale d'une lenteur du serveur.

Pourquoi l'alerte n'est pas partie alors que la page a dépassé le seuil ?

Soit la confirmation du projet demande 2 ou 3 échecs d'affilée (Projet → Alertes → Règles), soit un silence ou des heures calmes sont actifs. Le détail de l'URL montre le passage en échec dans les deux cas.

Le seuil vaut-il pour un parcours de paiement ?

Non. Les étapes d'un parcours sont vérifiées avec un statut 200 attendu et les assertions des pages de paiement, sans seuil de latence. Posez le seuil sur la page correspondante ajoutée en cible HTTP.

Anomalies de latence

Disponible avec les plans Pro et Pro Plus.

Une alerte quand une page devient anormalement lente pour cette heure de la semaine, avec la formule exacte.

Un seuil fixe sur le temps de réponse ment 2 fois : il crie sur un site lent par nature, et il se tait sur un site rapide qui vient de tripler. Ce qu'on veut savoir, c'est si ce passage sort de ce que cette page fait d'habitude à ce moment : le lundi 9 h n'a rien à voir avec le dimanche 3 h. Les anomalies de latence comparent chaque passage réussi à l'habitude de la page à cette heure de la semaine, et n'alertent qu'à l'entrée dans l'anomalie.

La ligne de base

Chaque nuit, PostShip recalcule pour chaque URL de sorte HTTP, formulaire ou parcours, et pour chacune des 168 heures de la semaine (lundi 9 h, mardi 9 h…, en UTC), 2 nombres sur les passages réussis des 14 derniers jours :

• la médiane du TTFB ;
• l'écart absolu médian (MAD) : la médiane des écarts à la médiane.

Médiane et MAD plutôt que moyenne et écart-type, parce qu'une ligne de base doit résister aux anomalies qu'elle sert à détecter : 3 pics dans la fenêtre ne bougent pas la médiane, ils auraient doublé l'écart-type. Un créneau qui a moins de 3 passages réussis n'a pas de ligne ; un passage dont le créneau est vide se compare à l'heure d'avant, à défaut à l'heure d'après, jamais plus loin : à 2 heures, on n'est plus sûr d'être dans le même régime de trafic.

Ce rythme est visible sur la page de chaque URL, « rythme de la semaine » : la grille heure par jour de la médiane, en UTC. On y lit la nuit qui dort, le lundi 9 h qui souffre, la sauvegarde de 3 h.

La formule

Pour un passage réussi de TTFB t, avec la médiane m et le MAD de son créneau :

z = (t − m) / (1,4826 × max(MAD, 20 ms))

1,4826 est la constante qui fait d'un MAD un écart-type pour une loi normale : le score se lit alors comme un z classique. Le plancher de 20 ms est le bruit réseau qu'on ne sait pas distinguer d'un vrai changement : un site très stable a un MAD presque nul, et diviser par zéro rendrait n'importe quel écart infini.

Un passage est une anomalie quand il franchit les 4 gardes, chacune contre un faux positif connu :

Un passage plus rapide que d'habitude n'est jamais une anomalie : z est négatif, et un CDN qui se réveille n'est pas une alerte. Un passage en échec non plus : le TTFB d'une page 500 mesure une panne, déjà signalée par ailleurs.

Ce qui déclenche une alerte

À l'entrée seulement. Une page lente pendant une heure, c'est 12 passages anormaux : la première alerte dit tout, les 11 suivantes ne disent plus rien. PostShip regarde si le passage précédent portait déjà une anomalie et se tait tant qu'elle dure. Le retour à la normale ne fait pas d'alerte non plus : le silence est le message.

L'alerte emprunte le canal « Contenu modifié » des alertes d'URL, avec sa propre phrase, et elle passe devant une mutation de contenu du même passage parce qu'elle est plus urgente :

3× plus lent que d'habitude à cette heure (1 850 ms contre 600 ms en temps normal)

Le rapport est arrondi au dixième (« 2,5× »). L'alerte suit les règles des autres : silence, heures calmes, maintenance, et la case « Le contenu a changé après un déploiement » pour l'email. Voir Email, Discord, Slack et Règles.

Les passages qui suivent un déploiement ne sont pas évalués : un déploiement rend les pages plus lentes le temps que le cache se remplisse, et cette lenteur-là a une cause connue.

Où le voir

• Sur la page Performance : la bande « normal » de chaque courbe (médiane ± 2 écarts robustes, plus étroite que le seuil d'alerte, exprès) et un point rouge à chaque passage consigné anormal. Voir Performance.
• Sur la page de l'URL : le rythme de la semaine.
• Dans la cause probable : une anomalie dans l'heure avant la panne vaut +40 à l'hypothèse « Saturation ».

Régler

Rien à régler : la détection est active dès que le plan le permet, sur toutes les URL HTTP, formulaire et parcours, dès que leur ligne de base existe. Pour un seuil fixe choisi par vous, voir le seuil de latence : un échec à partir d'une valeur, à chaque passage.

Limites et plans

Voir les plans.

Dépannage

Pourquoi aucune alerte alors que ma page a doublé ?

Regardez les 4 gardes : sous 300 ms, pas d'alerte ; avec un MAD large (un site qui oscille beaucoup), doubler ne fait pas z > 4. Ou bien la page était déjà lente au passage précédent : l'alerte n'est partie qu'à l'entrée.

Pourquoi la ligne de base est vide sur une URL récente ?

Elle est calculée la nuit, sur 14 jours, avec au moins 3 passages réussis par créneau horaire. Une URL ajoutée aujourd'hui aura ses premiers créneaux demain matin, et un rythme complet dans 2 semaines.