Práticas recomendadas para medir as Métricas da Web no campo

Como avaliar as Métricas da Web com sua ferramenta de análise atual.

Ter a capacidade de medir e gerar relatórios sobre o desempenho real das suas páginas é essencial para diagnosticar e melhorar a performance ao longo do tempo. Sem dados de campo, é impossível saber se as mudanças feitas no site estão realmente alcançando os resultados desejados.

Muitos provedores de análises de Real User Monitoring (RUM) conhecidos já oferecem suporte às métricas de Core Web Vitals nas ferramentas, assim como a muitas outras métricas do Core Web Vitals. Se você estiver usando uma dessas ferramentas de análise do RUM, poderá avaliar se as páginas do seu site atendem aos limites recomendados das Core Web Vitals e evitar regressões no futuro.

Embora recomendemos usar uma ferramenta de análise que ofereça suporte às métricas do Core Web Vitals, se a ferramenta de análise que você está usando não oferecer suporte a elas, não será necessário mudar. Quase todas as ferramentas de análise oferecem uma maneira de definir e medir métricas personalizadas ou eventos. Isso significa que você pode usar seu provedor de análise atual para medir as métricas do Core Web Vitals e adicioná-las aos relatórios e painéis de análise atuais.

Este guia discute as práticas recomendadas para medir as métricas das Core Web Vitals (ou qualquer métrica personalizada) com uma ferramenta de análise interna ou de terceiros. Ele também pode servir como um guia para fornecedores de análise que queiram adicionar suporte às Core Web Vitals ao serviço deles.

Usar métricas ou eventos personalizados

Como mencionado acima, a maioria das ferramentas de análise permite que você meça dados personalizados. Se sua ferramenta de análise oferecer suporte para isso, você poderá medir cada uma das Core Web Vitals usando esse mecanismo.

Geralmente, a medição de métricas ou eventos personalizados em uma ferramenta de análise é um processo de três etapas:

  1. Defina ou registre a métrica personalizada no administrador da ferramenta (se necessário). Observação: nem todos os provedores de análise exigem que as métricas personalizadas sejam definidas com antecedência.
  2. Calcule o valor da métrica no código JavaScript do front-end.
  3. Envie o valor da métrica para o back-end do Google Analytics, garantindo que o nome ou ID corresponda ao que foi definido na etapa 1 (novamente, se necessário).

Para as etapas 1 e 3, consulte a documentação da ferramenta de análise para instruções. Na etapa 2, use a biblioteca JavaScript web-vitals para calcular o valor de cada uma das Core Web Vitals.

O exemplo de código abaixo mostra como é fácil rastrear essas métricas no código e enviá-las a um serviço de análise.

import {onCLS, onINP, onLCP} from 'web-vitals';

function sendToAnalytics({name, value, id}) {
  const body = JSON.stringify({name, value, id});
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

Evite médias

É tentador somar um intervalo de valores para uma métrica de desempenho calculando uma média. As médias parecem convenientes à primeira vista, porque são um resumo organizado de uma grande quantidade de dados, mas você não deve confiar nelas para interpretar a performance da página.

As médias são problemáticas porque não representam a sessão de nenhum usuário. Outliers em qualquer intervalo da distribuição podem distorcer a média de maneiras enganosas.

Por exemplo, um pequeno grupo de usuários pode estar em redes extremamente lentas ou dispositivos que estão perto do intervalo máximo de valores, mas não considera sessões de usuários suficientes para afetar a média de uma forma que sugira que há um problema.

Sempre que possível, use percentis em vez de médias. Os percentis em uma distribuição para uma determinada métrica de performance descrevem melhor toda a gama de experiências do usuário no seu site. Isso permite que você se concentre em subconjuntos de experiências reais, que vão fornecer mais insights do que um único valor.

Confirmar se você pode denunciar uma distribuição

Depois de calcular os valores de cada uma das métricas das Core Web Vitals e enviá-los ao serviço de análise usando uma métrica ou um evento personalizado, a próxima etapa é criar um relatório ou painel que mostre os valores coletados.

Para garantir que você atenda aos limites recomendados das Core Web Vitals, seu relatório precisa mostrar o valor de cada métrica no 75º percentil.

Se a sua ferramenta de análise não oferecer relatórios de quartis como um recurso integrado, provavelmente ainda será possível acessar esses dados manualmente, gerando um relatório que lista todos os valores de métrica em ordem crescente. Depois que o relatório for gerado, o resultado que estiver em 75% da lista completa e classificada de todos os valores desse relatório será o 75o percentil dessa métrica. Esse será o caso, não importa como você segmente seus dados (por tipo de dispositivo, tipo de conexão, país etc.).

Se a ferramenta de análise não oferecer granularidade de relatórios no nível da métrica por padrão, provavelmente você poderá alcançar o mesmo resultado se a ferramenta de análise oferecer suporte a dimensões personalizadas. Ao definir um valor de dimensão personalizada e única para cada instância de métrica individual que você acompanha, é possível gerar um relatório dividido por instâncias de métrica individuais se você incluir a dimensão personalizada na configuração do relatório. Como cada instância terá um valor de dimensão exclusivo, nenhum agrupamento vai ocorrer.

O Relatório de Métricas da Web é um exemplo dessa técnica que usa o Google Analytics. O código do relatório é de código aberto, para que os desenvolvedores possam fazer referência a ele como um exemplo das técnicas descritas nesta seção.

Capturas de tela do Relatório
de Métricas da Web

Envie seus dados no momento certo

Algumas métricas de performance podem ser calculadas quando a página termina de carregar, enquanto outras (como a CLS) consideram toda a vida útil da página e só são finalizadas quando a página começa a ser descarregada.

No entanto, isso pode ser problemático, já que os eventos beforeunload e unload não são confiáveis (especialmente em dispositivos móveis) e o uso deles não é recomendado, porque eles podem impedir que uma página se qualifique para o Back-Forward Cache.

Para métricas que rastreiam toda a vida útil de uma página, é melhor enviar o valor atual da métrica durante o evento visibilitychange sempre que o estado de visibilidade da página mudar para hidden. Isso ocorre porque, quando o estado de visibilidade da página muda para hidden, não há garantia de que algum script dessa página poderá ser executado novamente. Isso é especialmente verdadeiro em sistemas operacionais móveis em que o próprio app do navegador pode ser fechado sem que nenhum callback de página seja acionado.

Os sistemas operacionais móveis geralmente acionam o evento visibilitychange ao alternar guias, apps ou fechar o próprio app do navegador. Eles também acionam o evento visibilitychange ao fechar uma guia ou navegar para uma nova página. Isso torna o evento visibilitychange muito mais confiável do que os eventos unload ou beforeunload.

Monitorar o desempenho ao longo do tempo

Depois de atualizar a implementação de análise para acompanhar e gerar relatórios sobre as métricas das Core Web Vitals, a próxima etapa é acompanhar como as mudanças no seu site afetam a performance ao longo do tempo.

Fazer a versão das suas alterações

Uma abordagem ingênua (e não confiável) para acompanhar mudanças é implantar mudanças na produção e presumir que todas as métricas recebidas após a data de implantação correspondem ao novo site e todas as métricas recebidas antes da data de implantação correspondem ao site antigo. No entanto, qualquer número de fatores (incluindo armazenamento em cache em HTTP, service worker ou camada de CDN) pode impedir que isso funcione.

Uma abordagem muito melhor é criar uma versão exclusiva para cada mudança implantada e acompanhar essa versão na sua ferramenta de análise. A maioria das ferramentas de análise oferece suporte à definição de uma versão. Se não tiver, você pode criar uma dimensão personalizada e definir essa dimensão na versão implantada.

Fazer experimentos

Você pode ir além do controle de versões rastreando várias versões (ou experimentos) ao mesmo tempo.

Se a sua ferramenta de análise permite definir grupos de experimentos, use esse recurso. Caso contrário, use dimensões personalizadas para garantir que cada um dos valores de métrica possa ser associado a um grupo de experimentos específico nos seus relatórios.

Com a experimentação ativa na sua análise, é possível lançar uma mudança experimental para um subconjunto de usuários e comparar o desempenho dessa mudança com o desempenho dos usuários no grupo de controle. Quando você tiver confiança de que uma mudança realmente melhora o desempenho, poderá lançá-la para todos os usuários.

Garantir que a medição não afete a performance

Ao avaliar o desempenho de usuários reais, é essencial que qualquer código de medição de performance executado não afete negativamente a performance da sua página. Se isso acontecer, as conclusões que você tentar tirar sobre como a performance afeta sua empresa não serão confiáveis, porque você nunca saberá se a presença do código de análise está tendo o maior impacto negativo.

Sempre siga estes princípios ao implantar o código de análise RUM no seu site de produção:

Adiar suas análises

O código do Google Analytics precisa ser carregado de maneira assíncrona e sem bloqueio e, geralmente, por último. Se você carregar o código de análise de maneira bloqueante, isso poderá afetar negativamente o LCP.

Todas as APIs usadas para medir as métricas das Core Web Vitals foram projetadas especificamente para oferecer suporte ao carregamento de script assíncrono e diferido (usando a flag buffered). Portanto, não é necessário se apressar para carregar os scripts com antecedência.

Se você estiver medindo uma métrica que não pode ser computada mais tarde na linha do tempo de carregamento de página, alinhe apenas o código que precisa ser executado antecipadamente no <head> do documento (para que não seja uma solicitação de bloqueio de renderização) e adie o restante. Não carregue todos os seus dados de análise com antecedência só porque uma única métrica exige isso.

Não crie tarefas longas

O código de análise geralmente é executado em resposta à entrada do usuário, mas, se ele estiver realizando muitas medições de DOM ou usando outras APIs que exigem muito do processador, ele pode causar uma baixa capacidade de resposta à entrada. Além disso, se o arquivo JavaScript que contém seu código de análise for grande, a execução desse arquivo pode bloquear a linha de execução principal e afetar negativamente a Interação até a próxima pintura (INP) de uma página.

Usar APIs não bloqueantes

APIs como sendBeacon() e requestIdleCallback() são projetadas especificamente para executar tarefas não críticas de uma maneira que não bloqueie tarefas críticas do usuário.

Essas APIs são ótimas ferramentas para usar em uma biblioteca de análise do RUM.

Em geral, todos os beacons do Google Analytics precisam ser enviados usando a API sendBeacon() (se disponível), e todo o código de medição passiva do Google Analytics precisa ser executado durante períodos de inatividade.

Não monitore mais do que precisa

O navegador expõe muitos dados de desempenho, mas o fato de os dados estarem disponíveis não significa necessariamente que você precisa gravá-los e enviá-los aos seus servidores de análise.

Por exemplo, a API Resource Timing oferece dados de tempo detalhados para cada recurso carregado na página. No entanto, é improvável que todos esses dados sejam necessários ou úteis para melhorar a performance de carregamento de recursos.

Em resumo, não acompanhe os dados apenas porque eles estão disponíveis. Garanta que os dados serão usados antes de consumir recursos para rastreá-los.