O eventoPageViewTiming de monitoramento do browser envia cada ponto de dados como um evento separado assim que estiver disponível. Como não restringimos o tempo, você pode receber dados da primeira pintura ou da primeira interação, independentemente de quando ela for acionada. Este documento descreve por que e como usar PageViewTiming e sua contribuição para consultar dados sobre seu site, carregamento de componentes e métricas de desempenho do usuário, tanto do ponto de vista visual quanto de responsividade.
Por que usar o PageViewTiming?
Se sua aplicação utiliza páginas assíncronas ou dinâmicas, você pode precisar de detalhes adicionais sobre o carregamento do site ou de componentes. Mas as páginas podem carregar conteúdo de muitas maneiras diferentes e o usuário pode controlar quando interage com esse conteúdo. É por isso que algumas métricas de desempenho centradas no usuário acontecem fora do onload padrão da janela (tempo de carregamento da página) no agente browser.
Por exemplo, o usuário pode ficar impaciente e começar a clicar assim que o conteúdo estiver na página web. Ou eles podem esperar para usar a página muito depois do conteúdo ser carregado.
O evento PageViewTiming fornece um mecanismo de entrega mais em tempo real que não depende de nenhum outro evento. A métrica adicional pode ajudar você a entender como é a experiência do usuário em seu site, tanto do ponto de vista visual quanto de responsividade.
Suporte para core web vitals do Google
A partir da versão 1177 do agente para monitoramento de Browser, temos suporte completo para core web vitals. Este recurso está disponível em todas as versões do agente (Lite, Pro ou Pro+SPA).
Observe que as métricas que compõem core web vitals evoluem com o tempo. O conjunto atual concentra-se em três aspectos da experiência do usuário: carregamento, interatividade e estabilidade visual. Inclui as seguintes métricas e respetivo limite:
- Largest contentful paint (LCP): mede o desempenho de carregamento. Para proporcionar uma boa experiência ao usuário, o LCP deve ocorrer within 2.5 seconds no momento em que a página começa a carregar.
- Interaction to next paint (INP): mede a latência de toda interação do usuário com uma página. Para proporcionar uma boa experiência do usuário, as páginas devem ter um INP de less than 200 milliseconds.
- Cumulative layout shift (CLS): mede a estabilidade visual. Para proporcionar uma boa experiência do usuário, as páginas devem manter um CLS de less than 0.1.
Para cada uma dessas métricas, para garantir que você atinja o destino recomendado para a maioria dos seus usuários, um bom limite a ser medido é o 75th percentile de carregamentos de página, segmentados em dispositivos móveis e desktop.
Para saber mais, assista à nossa palestra do Nerd Days sobre desempenho percebido.
Métricas detalhadas de visual, interatividade e capacidade de resposta
Os eventos BrowserInteraction e PageView encerram seus relatórios quando recebem o tempo de carregamento da janela da página (ou carregamento da janela e AJAX). Porém, a métrica de pintura e interatividade pode acontecer a qualquer momento. PageViewTiming entrega essas métricas como um evento separado para:
- Considere a variabilidade neste momento.
- Evite definir um tempo limite arbitrário.
- Impedir a retenção dos eventos
BrowserInteractionePageViewindefinidamente.
Dados adicionais | Comentários |
|---|---|
| Os atributos Usar |
| A métrica A pesquisa do Google descobriu que observar quando o maior elemento foi renderizado era uma forma mais precisa de medir quando o conteúdo principal de uma página está carregado e é útil. Para obter mais informações sobre essa métrica, incluindo limitações e considerações, consulte o rascunho do w3c. Também relatamos o atributo cumulativo de pontuação de mudança de layout com LCP. Este atributo é relatado como A pintura de maior conteúdo é uma das três métricas identificadas pelo Google como os core web vitals. Valores de LCP até 2,5 segundos são considerados “Bom”, entre 2,5 e 4 segundos são considerados “Precisa Melhorar” e acima de 4 segundos são considerados “Ruim”. |
| Com a adição de A métrica Também relatamos o atributo de pontuação cumulativa de mudança de layout (CLS) no momento da primeira interação do usuário. Este atributo é relatado como INP é uma das três métricas identificadas pelo Google como os core web vitals. Uma pontuação INP de 200 ms ou menos é considerada “Boa”, entre 200-500 ms é considerada “Precisa Melhorar” e acima de 500 ms é considerada “Ruim”. |
| A mudança cumulativa de layout (CLS) está disponível com o agente v1177 ou superior. CLS é uma métrica importante centrada no usuário para medir a estabilidade visual porque ajuda a quantificar a frequência com que a experiência do usuário muda inesperadamente de layout. Um CLS baixo ajuda a garantir que a página seja agradável. A mudança cumulativa de layout é uma das três métricas identificadas pelo Google como os core web vitals. Pontuações CLS até 0,1 são consideradas "Boas", entre 0,1-0,25 são consideradas "Precisa Melhorar" e acima de 0,25 são consideradas "Ruim". |
| A interação com a próxima pintura (INP) está disponível com o agente v1227 ou superior. INP é uma métrica mais recente para medir a capacidade de resposta do tempo de execução e o desempenho percebido pelo usuário. Mede a maior latência entre a interação do usuário e a resposta ou repintura da página. Esta é uma métrica experimental, mas identificada como significativa, adicionada no Web Vitals v3. Pontuações INP de até 200 ms são consideradas “Boas”, entre 200-500 ms são consideradas “Precisa Melhorar” e acima de 500 ms são consideradas “Ruim”. |
| Você pode revisar diferentes tipos de atividades com o atributo |
| Este é o |
| Este é o tamanho relatado do elemento |
| Relatórios de tarefas longas estão disponíveis a partir do agente v1227. Este evento representa por entrada observada pela API experimental PerformanceLongTaskTiming, que relata tarefas que bloqueiam o thread da interface principal por >50 ms. NOTA: Embora este evento esteja disponível como um recurso experimental, os dados dele não são coletados automaticamente. Deve ser habilitado na configuração do agente browser usando uma flag no objeto Geralmente é recomendado dividir e otimizar essas tarefas para evitar atrasos no processamento da entrada ou interação do usuário. Tarefas longas podem afetar ou estar intimamente relacionadas à métrica |
| O evento Também relatamos o atributo de pontuação de mudança cumulativa de layout (CLS) com |
| O evento Também relatamos o atributo de pontuação de mudança cumulativa de layout (CLS) com |
| O evento Também relatamos o atributo de pontuação de mudança cumulativa de layout (CLS) com |
Compatibilidade e requisitos
Requisitos:
- Atende aos requisitos de instalação.
- O relatório deste evento requer o agente browser versão 1153 ou superior.
Siga nossas notas de lançamento do agente browser para saber quando novas métricas são lançadas.
Estas métricas são suportadas pelas seguintes versões de browsers. Para browsers não suportados, nenhum evento PageViewTiming será registrado.
Métrica | Versões de browser suportadas |
|---|---|
|
|
|
|
|
|
|
|
|
|
| Este evento é atualmente compatível com a maioria das versões modernas de browsers, exceto Safari abaixo de 14.1 (desktop) ou 14.5 (iOS). Matriz de compatibilidade via documentação MDN. |
| Este evento é atualmente suportado por todos os browsers em desktops e dispositivos móveis. Matriz de compatibilidade via documentação MDN. |
| Este evento é atualmente suportado por todos os browsers em desktops e dispositivos móveis. Matriz de compatibilidade via documentação MDN. |
CumulativeLayoutShift
A mudança cumulativa de layout (CLS) é uma métrica que mede a estabilidade do conteúdo em uma página da web. Para obter uma descrição completa, consulte web.dev/cls.
Como o CLS é capturado no New Relic
As mudanças no layout da página, conforme relatadas pela API Layout Instability , são agregadas ao longo da vida da página e relatadas como um atributo em todos os eventos PageViewTiming , representando o valor CLS quando o evento ocorreu.
Usando este modelo, o usuário pode observar seu valor CLS em diferentes pontos da vida da página; por exemplo, valores CLS até o usuário interagir pela primeira vez com a página ou ocultá-la.
Aproximando outras fontes CLS
O Lighthouse captura o valor CLS apenas até o momento em que uma página é carregada, o que é útil em um ambiente de desenvolvimento ou de laboratório. Você pode aproximar os valores do Lighthouse observando o evento windowLoad PageViewTiming .
O relatório CrUX usa valores capturados ao longo da vida útil da página, o que é útil para analisar as mudanças de pior caso em um ambiente RUM. Você pode aproximar os valores CrUX observando o atributo CLS no evento windowUnload PageViewTiming . Esses valores não serão exatamente os mesmos devido a diferentes conjuntos de amostras e a uma diferença na forma como os valores de páginas da Web de longa duração são incluídos. O agente de monitoramento de browser da New Relic captura CLS quando a página é descarregada, enquanto o CrUX coleta e atualiza a métrica ao longo da vida útil da página.
Como o CLS é agregado
Em julho de 2021, o Google atualizou a forma como os valores CLS são agregados. O monitoramento das versões do agente Browser v12xx utiliza o método descrito em Evoluindo a métrica CLS.
Browser monitoring agent v12xx or higher:
Os valores de mudança de layout são capturados em janelas. Mudanças de layout que ocorreram com intervalo de 1 segundo entre si, mas não mais que 5 segundos entre o primeiro e o último turno, fazem parte da mesma janela. Uma pontuação CLS representa a soma dos valores de mudança de layout da janela com a maior soma de valores de mudança de layout.
Prior to Browser agent v12xx:
Uma pontuação CLS representa a soma de todas as mudanças de layout que ocorreram até aquele ponto na vida da página.
Consulte os dados do seu evento
Aqui estão alguns exemplos de consultas para os dados do evento para ajudá-lo a começar.