Erreurs des visiteurs

Un audit ne voit que la page qu'il charge. Le visiteur, lui, voit le bouton qui ne répond plus, le script tiers qui refuse de charger, la promesse que personne n'a rattrapée. Le snippet des vitals réels attrape ces erreurs dans son navigateur et les envoie par petits lots. PostShip ramène mille messages à une poignée de signatures, les montre sur la page Performance, et dit en une phrase ce qu'un déploiement a cassé.

Ce que PostShip capte

Trois sortes d'erreurs, depuis le navigateur du visiteur :

Bornes : 10 erreurs par page au plus, message et source de 300 caractères au plus, sans requête ni fragment (une URL de CDN peut porter un jeton signé). Le lot part deux secondes après la première erreur, le temps qu'une rafale se regroupe, ou au départ du visiteur.

La signature

Un même bug chez cent visiteurs est une ligne, pas cent. La signature est l'empreinte de quatre choses : la sorte, le message normalisé, la source stabilisée, la ligne.

• Le message perd ce qui varie sans changer l'erreur : le préfixe (Uncaught (in promise) TypeError:), les URL, les UUID, les hashes, les nombres de deux chiffres et plus. Le reste est gardé mot pour mot : « reading 'price' » et « reading 'name' » sont deux bugs, pas un.
• La source perd sa requête et le hash que le bundler glisse dans le nom du fichier (app-DkT3fWq2.js devient app-H.js) : sinon chaque build ferait de la même erreur une erreur nouvelle.
• La colonne n'entre pas : un minifieur la déplace à chaque build. La ligne, si.

La page Performance, section « Erreurs des visiteurs »

Sur la fenêtre choisie : le total d'occurrences, le nombre de pages vues, et le taux pour mille pages vues, parce qu'il dit si trente erreurs sont un désastre (trente pages vues) ou un bruit de fond (trente mille). Puis un groupe par signature, la plus fréquente d'abord, à égalité la plus récente : le message, le fichier et la ligne, le nombre d'occurrences, la première et la dernière vue, la répartition mobile/ordinateur, et jusqu'à 5 chemins où elle apparaît.

Quand la première occurrence suit un déploiement de production de moins de 24 heures, le groupe le nomme : « apparue après le déploiement a1b2c3d », avec un lien vers ce déploiement. Au-delà de 24 h, une erreur qui apparaît a plus probablement une autre cause : un navigateur mis à jour, un tiers qui a changé, une campagne qui amène un autre public.

Ce qui déclenche une alerte

Une alerte, une seule, par déploiement de production, 30 minutes après lui. Avant, il n'y a pas de visiteurs, donc pas d'erreurs, et on conclurait « rien » à tort. PostShip compare alors les signatures des 24 heures avant le déploiement à celles vues depuis : une signature inconnue avant et présente après, c'est ce que le ship a introduit. Si le passage a manqué sa fenêtre (plus de 2 heures après le déploiement), la comparaison n'a plus de sens et n'est pas faite.

Le message, par email (si les emails d'alerte du compte sont actifs) et sur les salons du projet :

Mon site : le déploiement a1b2c3d a introduit une erreur chez vos visiteurs
Depuis le déploiement, 2 erreurs nouvelles chez vos visiteurs : « Cannot read properties of undefined (reading 'price') » (checkout.js:12) et « img introuvable » (hero.webp), 41 fois sur 380 pages vues (11 %).

Deux noms au plus, puis « et 3 autres » : au-delà, la phrase ne se lit plus et l'écran est à un clic. Le pourcentage rapporte les occurrences aux pages vues depuis le déploiement ; sans page vue, il n'y a rien à rapporter. Aucune erreur nouvelle : aucun message, le silence est la réponse.

Cette alerte ne passe pas par les règles de silence des alertes d'URL : c'est un message d'équipe, comme l'escalade. Elle ne part pas non plus sur le webhook sortant.

Régler

Rien de plus que le snippet : Projet → Intégrations, carte « Vitals réels », case « Accepter les mesures de ce site », et le script posé sur vos pages. Sans la case, les erreurs reçues sont ignorées comme les vitals. L'alerte demande un déploiement de production enregistré : webhook ou détection par empreinte.

Limites et plans

L'alerte suit les alertes de qualité de déploiement. Voir les plans.

Dépannage

Pourquoi je vois des erreurs d'extensions de navigateur ?

Le snippet capte tout ce que la page reçoit, y compris ce qu'une extension injecte. Leur source est en général chrome-extension://… ou moz-extension://… : c'est le fichier qui vous le dit. Elles restent rares et ne sont « nouvelles » qu'une fois.

Pourquoi la même erreur apparaît deux fois ?

Deux signatures : la ligne diffère (le fichier n'est pas minifié et le code a bougé), ou le message contient un mot qui change (un nom de champ). C'est voulu : deux endroits, deux bugs.