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

# Performance de front-end no AppSignal

> Como web vitals são agregadas por rota e por release, e o que a visualização Performance mostra.

<Note>
  Browser monitoring é uma funcionalidade em beta do [AppSignal Labs](/labs). O
  pacote `@appsignal/browser` é publicado sob a tag `beta` no npm, e sua
  configuração e API ainda podem mudar entre releases beta. Compartilhe seu
  feedback na nossa [comunidade no Discord](https://discord.gg/EjF6ykYx63).
</Note>

A visualização Performance relata as [web vitals](/browser/web-vitals) medidas em carregamentos de página reais, nos próprios dispositivos e conexões dos seus usuários. Diferente de um teste sintético em laboratório, ela mostra como a aplicação se comporta para as pessoas que realmente a usam, no hardware e nas redes que elas realmente têm.

<h2 id="web-vitals-summary">
  Resumo das web vitals
</h2>

Cinco métricas são resumidas para o período que você seleciona: LCP, INP, CLS, FCP e TTFB. Cada uma mostra seu valor atual, uma indicação de se esse valor é bom ou precisa de trabalho, e uma linha de tendência. É a linha de tendência que diferencia um número estável de um que vem subindo.

Cada período também é comparado com o período anterior de mesma duração. Selecionar as últimas quatro horas compara essas quatro horas com as quatro anteriores, e é isso que mostra se um número está melhorando ou piorando.

Quando uma tendência mostra um pico, verifique quantas medições estão por trás dele antes de tratá-lo como uma regressão. Um pico feito de uma única medição é ruído.

As classificações vêm dos limites do Google, listados com cada métrica na [página de web vitals](/browser/web-vitals#what-each-metric-measures). As três Core Web Vitals são LCP, INP e CLS. FCP e TTFB são métricas de apoio que ajudam a explicar um LCP ruim: um TTFB lento aponta para o servidor ou a rede, enquanto um TTFB rápido com um LCP lento aponta para o front end.

<h2 id="percentiles">
  Percentis
</h2>

Os valores são relatados em um percentil que você escolhe: p75, p90 ou p95.

Comece com p75, que é o percentil contra o qual os limites do Google são definidos, e o que usar quando você quer saber se uma página está boa ou não. Passe para p90 ou p95 quando quiser saber o que seus usuários mais lentos estão enfrentando, que é onde tendem a aparecer os problemas que as médias escondem.

<h2 id="per-route-breakdown">
  Detalhamento por rota
</h2>

Abaixo do resumo, cada rota é listada com sua contagem de samples e seu valor para cada uma das cinco métricas. A contagem de samples importa tanto quanto os valores: uma rota com quatro samples é um indício, não uma conclusão.

É nesta tabela que você encontra o trabalho a fazer. Ordenar por LCP traz as páginas mais lentas para o topo, e ler uma linha inteira diz por que uma página está lenta:

* Um TTFB lento com um LCP aceitável significa que seu servidor é o gargalo.
* Um TTFB rápido com um CLS ruim significa que a página chega rápido, mas salta enquanto termina de carregar.

As rotas são listadas como os templates que sua aplicação relatou. Para tudo que não relatou nenhum, o AppSignal deduz um template a partir da URL, o que é mais grosseiro do que informá-lo diretamente. Leia mais em [relatar a rota atual](/browser/installation#report-the-current-route).

<h2 id="comparing-releases">
  Comparando releases
</h2>

Filtrar por versão da aplicação restringe toda a visualização, resumo e tabela, aos carregamentos de página relatados por aquele release. Selecionar uma versão também rotula as linhas de tendência com ela.

É a forma mais rápida de responder se um deploy deixou algo mais lento. Defina [`appVersion`](/browser/configuration#appversion) com sua tag de release ou seu SHA de commit e cada medição passa a carregá-lo.

<h2 id="filtering-by-route">
  Filtrando por rota
</h2>

Filtrar por rota restringe tanto o resumo quanto a tabela, então você lê os números de uma parte da aplicação em vez de uma média sobre tudo.

Essas médias muitas vezes não ajudam sozinhas. Uma página de marketing rápida e um dashboard lento se combinam em um único número que não descreve nenhum dos dois.

<h2 id="what-the-numbers-leave-out">
  O que os números deixam de fora
</h2>

Dois pontos a ter em mente ao interpretar o que você vê:

* **CLS e INP cobrem apenas parte dos seus usuários.** Os dois dependem de recursos de navegador que só o Chrome e outros navegadores Chromium têm, então visitantes no Safari e no Firefox não contribuem para eles. LCP, FCP e TTFB cobrem todo mundo. Leia mais em [suporte dos navegadores](/browser/web-vitals#browser-support).
* **LCP, FCP e TTFB pertencem ao carregamento da página, não à rota.** O navegador os mede uma vez, quando a página carrega pela primeira vez. Em uma aplicação de página única, eles pertencem à rota que o usuário abriu primeiro, não às rotas para as quais ele foi depois. CLS e INP são medidos por rota. Leia mais em [como os valores são atribuídos às rotas](/browser/web-vitals#how-values-are-attributed-to-routes).

Se nenhuma web vital aparecer, lembre-se de que elas são enviadas em lotes, não uma a uma. Percorra a [solução de problemas](/browser/troubleshooting#errors-arrive-web-vitals-do-not).
