# Rapports de crash et de page bloquée du navigateur, un signal de disponibilité côté client (/fr/blog/browser-crash-reports)





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.

<Callout type="warn" title="Disponibilité limitée">
  Le crash reporting est implémenté dans les navigateurs basés sur Chromium et évolue encore. Firefox et Safari n'envoient pas de rapports de crash, donc traitez cela comme un signal provenant d'une partie de votre trafic, pas comme un décompte complet.
</Callout>

## Ce que vous apprend un rapport de crash [#ce-que-vous-apprend-un-rapport-de-crash]

Un [rapport `crash`](/fr/docs/web-security/reporting-api/reports/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 [#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`](/fr/docs/web-security/reporting-api/headers/reporting-endpoints)
et le navigateur y achemine automatiquement les crashs.

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

## À quoi ressemble un rapport de crash [#à-quoi-ressemble-un-rapport-de-crash]

```json
{
  "type": "crash",
  "url": "https://example.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 [#ajouter-une-pile-dappels-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`](/fr/docs/web-security/policies/document-policy)
([Document-Policy expliqué](/fr/blog/document-policy-explained)) et le point de
configuration `include-js-call-stacks-in-crash-reports`.

```http
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é [#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 [#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](/platform/monitoring) 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.

<img alt="La répartition des crashs groupée par raison, avec des lignes oom et unresponsive, les navigateurs qui les ont envoyés et le nombre de rapports" src="__img0" width="1359" height="359" />

## Étapes suivantes [#étapes-suivantes]

* Câblez d'abord l'endpoint : [comment configurer le Reporting API](/fr/blog/how-to-set-up-the-reporting-api).
* Lisez la [référence du rapport crash](/fr/docs/web-security/reporting-api/reports/crash).
* Activez les piles d'appels avec [Document-Policy](/fr/docs/web-security/policies/document-policy).

[Surveillez la disponibilité côté client depuis le trafic réel](/register).

## Sources [#sources]

* [Le crash reporting sur MDN](https://developer.mozilla.org/en-US/docs/Web/API/Reporting_API)
* [Spécification du Reporting API (W3C)](https://www.w3.org/TR/reporting-1/)
* [Surveiller votre application web avec le Reporting API sur Chrome for Developers](https://developer.chrome.com/docs/capabilities/web-apis/reporting-api)

## Articles liés [#articles-liés]

* [Comment configurer le Reporting API du navigateur](/fr/blog/how-to-set-up-the-reporting-api)
* [Qu'est-ce que NEL, le network error logging du navigateur](/fr/blog/what-is-nel-network-error-logging)
* [Rapports de deprecation et d'intervention](/fr/blog/deprecation-intervention-reports)