• EnglishEspañol日本語한국어Português
  • EntrarComeçar agora

Esta tradução de máquina é fornecida para sua comodidade.

Caso haja alguma divergência entre a versão em inglês e a traduzida, a versão em inglês prevalece. Acesse esta página para mais informações.

Criar um problema

PageViewTiming: detalhes da página assíncrona ou dinâmica

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 BrowserInteraction e PageView indefinidamente.

Dados adicionais

Comentários

firstPaint e firstContentfulPaint

Os atributos firstPaint e firstContentfulPaint já estão disponíveis com o evento BrowserInteraction e PageView . No entanto, eles nem sempre são capturados de forma confiável antes que o evento onload da janela seja acionado.

Usar PageViewTiming oferece uma maneira de capturar essas métricas mesmo que elas ocorram após o tempo de carregamento da página original. Isso lhe dá uma melhor compreensão da correlação entre a capacidade de resposta desse evento de carregamento e a renderização visual do seu conteúdo.

largestContentfulPaint

A métrica largestContentfulPaint está disponível com o agente versão 1163 ou superior. Ele informa o tempo de renderização do maior elemento de conteúdo visível na janela de visualização.

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

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

firstInteraction e interactionToNextPaint

Com a adição de firstInteraction e interactionToNextPaint, você pode determinar rapidamente as formas como seu usuário está interagindo com aquele conteúdo visual. Essas métricas informam não apenas quando eles interagiram, mas que tipo de interação (mousedown, pointerdown, etc.) e quanto tempo demorou para receberem uma resposta do seu site.

A métrica interactionToNextPaint fica no meio das métricas FirstContentfulPaint e Time to Interactive (TTI). Ele mede o tempo entre o momento em que uma primeira entrada pode ser feita e o momento em que o thread principal do browser é capaz de responder a qualquer interação.

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

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

cumulativeLayoutShift

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

interactionToNextPaint

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

timingName

Você pode revisar diferentes tipos de atividades com o atributo timingName , como firstPaint, firstContentfulPaint, firstInteraction, largestContentfulPaint, pageHide e windowUnload. Por exemplo, um evento PageViewTiming pode ter um timingName de firstPaint e um valor firstPaint de .03. O evento também incluirá todos os atributos padrão incluídos nos eventos padrão BrowserInteraction e PageView .

elementId

Este é o Id, se especificado, do elemento largestContentfulPaint . Este valor só será reportado com a métrica LCP. Esse valor pode ser null.

elementSize

Este é o tamanho relatado do elemento largestContentfulPaint . Este valor só será reportado com a métrica LCP.

longTask

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 init , por exemplo init: { page_view_timing: { long_task: true } }.

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 interactionToNextPaint . Observe que a API atualmente não fornece nenhum contexto detalhado sobre a causa dessas tarefas e agrupa todas as tarefas longas dentro de um quadro de navegação, mesmo que consistam em várias funções diferentes.

pageHide

O evento pageHide , disponível com o agente v1177 ou superior, é enviado quando o documento fica oculto para o usuário. Na prática moderna, isso sinaliza o potencial fim de uma sessão do usuário de forma mais confiável. Este evento sempre acompanha windowUnload se isso ocorrer, mas também pode ser acionado separadamente quando o usuário muda de guia. Nesse caso, o descarregamento não é acionado.

Também relatamos o atributo de pontuação de mudança cumulativa de layout (CLS) com pageHide. Este atributo é relatado como cumulativeLayoutShift.

windowLoad

O evento windowLoad está disponível com o agente v1177 ou superior. Isso é acionado quando toda a página é carregada, incluindo todos os recursos dependentes, como folhas de estilo e imagens. Para documentação de suporte e compatibilidade do browser para o evento windowLoad , consulte o site MDN Web Docs.

Também relatamos o atributo de pontuação de mudança cumulativa de layout (CLS) com windowLoad. Este atributo é relatado como cumulativeLayoutShift.

windowUnload

O evento windowUnload , disponível com o agente v1163 ou superior, é enviado quando o descarregamento da página é detectado. Na prática moderna, isso se baseia no disparo do evento window pagehide e significa que o usuário está navegando para longe.

Também relatamos o atributo de pontuação de mudança cumulativa de layout (CLS) com windowUnload. Este atributo é relatado como cumulativeLayoutShift.

Compatibilidade e requisitos

Requisitos:

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

cumulativeLayoutShift

firstPaint

firstContentfulPaint

  • Chrome 60 ou superior para desktop e dispositivos móveis (Android webview e Chrome para Android)
  • Opera 47 ou superior para desktop
  • Opera 44 ou superior para celular Android
  • Internet Samsung para celular

largestContentfulPaint

  • Chrome 77 ou superior para computadores e dispositivos móveis

interactionToNextPaint

longTask

pageHide

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.

windowLoad

Este evento é atualmente suportado por todos os browsers em desktops e dispositivos móveis. Matriz de compatibilidade via documentação MDN.

windowUnload

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.

Copyright © 2024 New Relic Inc.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.