> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Web vitals du navigateur

<Note>
  Browser monitoring est une fonctionnalité en beta d'[AppSignal Labs](/labs). Le
  package `@appsignal/browser` est publié sous le tag `beta` sur npm, et sa
  configuration ainsi que son API peuvent encore changer d'une release beta à
  l'autre. Partagez vos retours dans notre
  [communauté Discord](https://discord.gg/EjF6ykYx63).
</Note>

Les web vitals mesurent la rapidité avec laquelle une page se charge et répond. Elles indiquent aussi si sa mise en page se décale de façon inattendue. AppSignal les mesure sur les appareils et les connexions des utilisateurs réels.

La collecte démarre avec `init()`. Il n'y a rien à configurer.

<h2 id="what-each-metric-measures">
  Ce que mesure chaque métrique
</h2>

| Métrique | Ce qu'elle mesure | Bon | À améliorer | Mauvais |
| - | - | - | - | - |
| LCP (Largest Contentful Paint) | Le temps de rendu du plus grand élément visible. | ≤ 2 500 ms | 2 500–4 000 ms | > 4 000 ms |
| INP (Interaction to Next Paint) | La rapidité avec laquelle la page répond à une interaction. | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | L'ampleur des décalages inattendus de la mise en page pendant le chargement. | ≤ 0,1 | 0,1–0,25 | > 0,25 |
| FCP (First Contentful Paint) | Le délai avant l'apparition du premier contenu. | ≤ 1 800 ms | 1 800–3 000 ms | > 3 000 ms |
| TTFB (Time to First Byte) | Le temps que met le serveur à commencer à répondre. | ≤ 800 ms | 800–1 800 ms | > 1 800 ms |

LCP, INP et CLS sont les trois Core Web Vitals. FCP et TTFB aident à expliquer un mauvais LCP. Un TTFB lent désigne le serveur ou le réseau. Un TTFB rapide avec un LCP lent oriente plutôt vers le chargement des ressources ou le rendu.

Chaque valeur est évaluée par rapport à ces seuils. AppSignal étiquette chaque valeur du résumé avec une évaluation. Le tableau par route utilise les mêmes évaluations.

<h2 id="how-values-are-attributed-to-routes">
  Comment les valeurs sont attribuées aux routes
</h2>

LCP, FCP et TTFB mesurent le chargement de la page. Le navigateur mesure chacun d'eux une fois, au premier chargement de la page, et plus jamais ensuite. Dans une application monopage, ils appartiennent à la route chargée en premier. Les routes côté client suivantes ne reçoivent pas de nouvelles métriques de chargement. Les mesurer de nouveau à chaque route nécessiterait une fonctionnalité de navigateur encore expérimentale.

CLS et INP peuvent s'accumuler tant qu'une page reste ouverte. Quand le navigateur les prend en charge, AppSignal attribue les valeurs observées à la route active. Il les réinitialise à chaque navigation.

Pour que les routes restent distinctes et lisibles, indiquez à AppSignal le template de route à chaque navigation de votre routeur :

<CodeGroup>
  ```js JavaScript theme={null}
  import { setRouteTemplate } from "@appsignal/browser";

  setRouteTemplate("/orders/:id");
  ```
</CodeGroup>

Sans template, le processeur remplace les ID reconnaissables dans les URL de web vitals, comme les nombres et les UUID. Il peut passer à côté d'ID propres à votre application. Les erreurs utilisent le chemin brut tant que vous ne définissez pas de template, un seul appel améliore donc aussi le [regroupement des erreurs](/browser/error-tracking#how-errors-are-grouped).

Il y a une seconde raison d'utiliser des templates. AppSignal ne conserve qu'un nombre limité de routes distinctes par application. Au-delà, les autres sont regroupées dans un unique groupe sans nom que le filtre de route laisse de côté. Sans templates explicites, les routes dont le processeur ne reconnaît pas les ID peuvent atteindre cette limite plus tôt.

<h2 id="when-values-are-sent">
  Quand les valeurs sont envoyées
</h2>

Les web vitals sont regroupées par lots et envoyées aux frontières de page et de route :

* Quand la page est masquée, ce qui couvre le changement d'onglet et le passage de l'application en arrière-plan.
* Quand la page est fermée ou quittée.
* Lors d'un changement de route côté client.

Si une page plante ou est fermée de force avant qu'un de ces événements se produise, rien n'est enregistré pour cette visite.

Pour les routeurs basés sur le hash, AppSignal traite `#/orders` comme une navigation. Il ne traite pas une simple ancre sur la page, comme `#pricing`, comme telle.

<h2 id="browser-support">
  Prise en charge par les navigateurs
</h2>

Le SDK ne signale une métrique que si le navigateur fournit les entrées de performance nécessaires pour la mesurer. CLS nécessite `layout-shift` ; INP nécessite `event-timing`. Les navigateurs sans ces types d'entrée ne contribuent pas à ces métriques. LCP, FCP et TTFB sont collectées via la bibliothèque `web-vitals` quand elle est disponible.

<h2 id="reviewing-performance-in-appsignal">
  Examiner les performances dans AppSignal
</h2>

La vue Performance résume chaque métrique pour la période sélectionnée. Filtrez-la par percentile, période, version d'application ou route. Pour en savoir plus, consultez [les performances front-end dans AppSignal](/browser-monitoring/performance).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.