Rapports de crash et de page bloquée du navigateur, un signal de disponibilité côté client

Quand l'onglet du navigateur qui exécute votre page plante, manque de mémoire ou se fige, vos outils d'analytics et de suivi d'erreurs tombent avec lui. La page censée signaler le problème est justement celle qui vient de mourir, donc la panne reste invisible pour tous les outils qui tournent à l'intérieur. Les rapports de crash comblent ce trou. Le navigateur se souvient que la page a planté et envoie un rapport à la prochaine visite sur votre origine, depuis l'extérieur de l'onglet mort, ce qui vous donne un signal de disponibilité côté client impossible à obtenir autrement.

Ce que vous apprend un rapport de crash

Un rapport crash indique que le processus de rendu qui héberge votre page a cessé de fonctionner. Le corps contient un champ reason qui explique comment il s'est terminé. Deux raisons comptent le plus :

• oom, le processus de rendu a été tué parce qu'il a manqué de mémoire.
• unresponsive, la page est restée bloquée assez longtemps pour que le navigateur l'abandonne.

Un crash sans raison précise est un simple crash du processus de rendu. Dans tous les cas, le rapport concerne le processus qui exécutait votre page, pas votre serveur. C'est le navigateur qui vous dit que, pour cet utilisateur, votre page a totalement cessé de fonctionner.

Pourquoi la livraison est retardée

Un rapport normal peut être envoyé pendant que la page est vivante. Un rapport de crash, non, car ce qui devrait l'envoyer est justement ce qui a échoué. Le navigateur conserve donc le rapport et le livre plus tard, à la prochaine visite sur votre origine. Le crash est enregistré dans une session et signalé dans la suivante.

Ce délai est le trait caractéristique des rapports de crash, et il conditionne la manière de les lire. Un pic ne coïncide pas avec la minute où les crashs se sont produits, il coïncide avec le moment où ces utilisateurs sont revenus. Anticipez ce décalage, et ne traitez jamais le décompte comme du temps réel.

Comme tous les types de rapports, les rapports de crash ne sont liés à aucune politique unique, ils sont donc envoyés à l'endpoint nommé default. Déclarez-le une fois avec Reporting-Endpoints et le navigateur y achemine automatiquement les crashs.

Reporting-Endpoints: default="https://<Endpoint-ID>.report.centralcsp.com"

À quoi ressemble un rapport de crash

{
  "type": "crash",
  "url": "https://api-next.centralcsp.com/checkout",
  "body": {
    "reason": "unresponsive"
  }
}

Le corps est volontairement réduit. Par conception, un rapport de crash ne transporte aucun contenu de page, puisque la page a disparu. Au-delà du champ reason, Chromium peut inclure les indicateurs is_top_level, visibility_state et crash_report_api, ainsi qu'une stack JavaScript pour les blocages (voir plus bas). Associé à l'url qui était chargée, cela suffit à répondre à la question qui compte : quelles pages tuent l'onglet, et comment.

Ajouter une pile d'appels aux rapports unresponsive

Pour les crashs unresponsive, Chromium peut inclure une pile d'appels JavaScript pour vous montrer où la page s'est bloquée. Vous l'activez avec le header Document-Policy (Document-Policy expliqué) et le point de configuration include-js-call-stacks-in-crash-reports.

Document-Policy: include-js-call-stacks-in-crash-reports

Une fois activé, un rapport unresponsive peut transporter la pile JS du code qui s'exécutait au moment où la page s'est figée, ce qui transforme « une page s'est bloquée » en « cette fonction s'est bloquée ». Cela s'applique aux blocages unresponsive, où il y a une pile à capturer, pas à un arrêt oom. La prise en charge est propre à Chromium et récente.

Lisez-le comme un signal SRE et sécurité

Les rapports de crash sont un signal ténu, mais significatif quand vous surveillez la tendance plutôt que l'événement isolé.

• Des oom répétés sur une même route pointent vers une fuite mémoire ou une allocation non bornée sur cette page. Une page dont la mémoire grimpe jusqu'à la mort de l'onglet apparaîtra ici avant partout ailleurs, car le crash tue votre surveillance intégrée à la page.
• Une hausse des rapports unresponsive signifie que de vrais utilisateurs rencontrent des blocages, souvent une boucle serrée ou du travail bloquant sur le thread principal dans des conditions que vos appareils de test ne reproduisent pas. La pile d'appels optionnelle vous indique quel code.
• Une rafale soutenue de l'un ou l'autre, surtout concentrée sur une origine ou un endpoint, peut aussi se lire comme un signal de déni de service : une entrée ou un contenu qui épuise de façon fiable la mémoire ou coince le processus de rendu est un problème de disponibilité côté client, pas juste un bug.

Associez la raison à l'url et vous obtenez une courte liste de pages à durcir, classées selon la fréquence à laquelle elles font tomber un onglet.

Collectez les crashs sans agent dans la page

Tout l'intérêt d'un rapport de crash est qu'il arrive depuis l'extérieur de la page en échec, il lui faut donc une destination toujours disponible pour le recevoir. CentralCSP ingère tous les types de rapports du navigateur, donc pointer votre endpoint default vers lui collecte les rapports crash et unresponsive aux côtés de vos rapports CSP, NEL et deprecation, groupés par url et reason pour qu'une route qui fuit ou un blocage qui se propage ressorte. Vous surveillez la disponibilité côté client au même endroit que vos rapports de sécurité, sans aucun agent qui tourne dans l'onglet qui vient de mourir.

Étapes suivantes

• Câblez d'abord l'endpoint : comment configurer le Reporting API.
• Lisez la référence du rapport crash.
• Activez les piles d'appels avec Document-Policy.

Surveillez la disponibilité côté client depuis le trafic réel.

Sources

• Le crash reporting sur MDN
• Spécification du Reporting API (W3C)
• Surveiller votre application web avec le Reporting API sur Chrome for Developers

Articles liés

• Comment configurer le Reporting API du navigateur
• Qu'est-ce que NEL, le network error logging du navigateur
• Rapports de deprecation et d'intervention