Como medir as Métricas da Web com sua ferramenta de análise atual.
A capacidade de medir e gerar relatórios sobre o desempenho real das suas páginas é fundamental para diagnosticar e melhorar o desempenho ao longo do tempo. Sem os dados de campo, é impossível saber com certeza se as mudanças que você está fazendo no seu site estão realmente atingindo os resultados desejados.
Muitos provedores de análise famosos de monitoramento real de usuários (RUM, na sigla em inglês) já oferecem suporte às Core Web Vitals nas ferramentas, além de muitas outras Métricas da Web. Se você usa atualmente uma dessas ferramentas de análise RUM, pode avaliar se as páginas do seu site atendem aos limites recomendados das Core Web Vitals e evitar regressões no futuro.
Embora recomendemos o uso de uma ferramenta de análise que ofereça suporte às Core Web Vitals, não será necessário mudar se a ferramenta usada no momento não for compatível com elas. Quase todas as ferramentas de análise oferecem uma maneira de definir e medir métricas personalizadas ou eventos, o que significa que provavelmente pode usar seu provedor de análise atual para avaliar as métricas das Core Web Vitals e adicioná-las aos seus relatórios e painéis de análise existentes.
Este guia aborda as práticas recomendadas para avaliar as Core Web Vitals (ou métricas personalizadas) com uma ferramenta de análise interna ou de terceiros. Ele também pode servir como um guia para fornecedores de análise que querem adicionar a compatibilidade com as Core Web Vitals ao serviço.
Usar métricas ou eventos personalizados
Conforme mencionado acima, a maioria das ferramentas de análise permite medir dados personalizados. Se sua ferramenta de análise oferecer suporte para isso, você poderá medir cada uma das Core Web Vitals usando esse mecanismo.
A medição de métricas ou eventos personalizados em uma ferramenta de análise geralmente é um processo de três etapas:
- Defina ou registre a métrica personalizada no administrador da sua ferramenta (se necessário). Observação: nem todos os provedores de análise exigem a definição prévia das métricas personalizadas.
- Calcule o valor da métrica no código JavaScript do front-end.
- Envie o valor da métrica ao back-end de análise, garantindo que o nome ou ID corresponda ao que foi definido na etapa 1 (novamente, se necessário).
Para saber mais sobre as etapas 1 e 3, consulte a documentação da ferramenta de análise. Na etapa 2, use a biblioteca JavaScript web-vitals para calcular o valor de cada uma das métricas das Core Web Vitals.
O exemplo de código a seguir mostra como pode ser fácil rastrear essas métricas em código e enviá-las a um serviço de análise.
import {onCLS, onFID, 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);
onFID(sendToAnalytics);
onLCP(sendToAnalytics);
Evitar médias
É tentador somar um intervalo de valores de uma métrica de desempenho calculando uma média. As médias parecem convenientes à primeira vista, porque são um resumo ordenado de uma grande quantidade de dados, mas você precisa resistir à vontade de confiar nelas para interpretar o desempenho da página.
As médias são problemáticas porque não representam a sessão de nenhum usuário. Os outliers em qualquer intervalo da distribuição podem distorcer a média de maneira enganosa.
Por exemplo, um pequeno grupo de usuários pode estar em redes ou dispositivos extremamente lentos que estão dentro do intervalo máximo de valores, mas não considera sessões de usuário suficientes para afetar a média de forma a sugerir que há um problema.
Sempre que possível, confie em percentis em vez de médias. Os percentis de uma distribuição para uma determinada métrica de performance descrevem melhor toda a variedade de experiências do usuário no seu site. Isso permite que você se concentre em subconjuntos de experiências reais, o que fornecerá mais insights do que um único valor jamais poderia.
Verifique se é possível denunciar uma distribuição
Depois de calcular os valores de cada uma 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 exiba os valores coletados.
Para garantir que você está atendendo aos limites recomendados das Core Web Vitals, seu relatório precisa mostrar o valor de cada métrica no 75o percentil.
Se sua ferramenta de análise não oferece relatórios de quantil como um recurso integrado, ainda é possível conseguir esses dados manualmente gerando um relatório que liste todos os valores de métricas classificados em ordem crescente. Depois que esse relatório for gerado, o resultado que estiver em 75% da lista completa e classificada de todos os valores nesse relatório será o 75o percentil dessa métrica. Isso acontecerá independentemente de como você segmentar os dados (por tipo de dispositivo, tipo de conexão, país etc.).
Se a ferramenta de análise não fornecer granularidade de relatórios no nível de métrica por padrão, você provavelmente poderá alcançar o mesmo resultado se oferecer suporte a dimensões personalizadas. Ao definir um valor de dimensão personalizada e exclusivo para cada instância de métrica individual que você acompanha, será possível gerar um relatório detalhado por instâncias de métricas individuais se você incluir a dimensão personalizada na configuração do relatório. Como cada instância terá um valor de dimensão único, não haverá agrupamento.
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, então os desenvolvedores podem consultá-lo como um exemplo das técnicas descritas nesta seção.
Envie seus dados no momento certo
Algumas métricas de desempenho podem ser calculadas depois que a página termina de carregar, enquanto outras (como o CLS) consideram toda a vida útil da página e são definitivas apenas depois que a página começa a ser descarregada.
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, já que podem impedir que uma página seja qualificada para o cache de avanço e retorno.
Para métricas que acompanham 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 qualquer script nessa página será executado novamente. Principalmente nos sistemas operacionais móveis
em que o próprio app do navegador pode ser fechado sem que nenhum retorno de chamada da página
seja disparado.
Os sistemas operacionais para dispositivos móveis geralmente disparam o evento visibilitychange
ao trocar de guia, trocar de app ou fechar o próprio app do navegador.
Elas também disparam 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 sua implementação de análise para rastrear e gerar relatórios sobre as Core Web Vitals, a próxima etapa é acompanhar como as mudanças no seu site afetam o desempenho ao longo do tempo.
Versão das mudanças
Uma abordagem simples e não confiável para acompanhar alterações é implantar as alterações na produção e presumir que todas as métricas recebidas após a data de implantação correspondem ao novo local e todas as que foram recebidas antes dessa data. No entanto, vários fatores, como armazenamento em cache na camada HTTP, service worker ou CDN, podem impedir que isso funcione.
Uma abordagem muito melhor é criar uma versão exclusiva para cada alteração implantada e, em seguida, rastrear essa versão na ferramenta de análise. A maioria das ferramentas de análise aceita a definição de uma versão. Caso contrário, crie uma dimensão personalizada e defina-a como a versão implantada.
Fazer experimentos
Você pode ir além e acompanhar várias versões (ou experimentos) ao mesmo tempo.
Se sua ferramenta de análise permite definir grupos experimentais, use esse recurso. Caso contrário, você pode usar dimensões personalizadas para garantir que cada um dos valores de métrica seja associado a um determinado grupo experimental nos seus relatórios.
Com a experimentação em vigor na sua análise, é possível lançar uma alteração experimental em um subconjunto de usuários e comparar o desempenho dessa alteração com a dos usuários no grupo de controle. Quando você tiver confiança de que uma mudança realmente melhora o desempenho, poderá implementá-la para todos os usuários.
Verifique se a medição não afeta a performance
Quando você avalia a performance de usuários reais, é absolutamente fundamental que nenhum código de medição de performance que você execute não afete negativamente a performance da sua página. Se isso acontecer, as conclusões que você tentar tirar sobre como seu desempenho afeta seus negócios não serão confiáveis, já que você nunca saberá se a presença do código de análise em si 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 sempre carregado de forma assíncrona e sem bloqueio e, em geral, o carregamento por último. Se você carregar o código de análise de maneira bloqueada, a LCP poderá ser afetada negativamente.
Todas as APIs usadas para medir as Core Web Vitals foram projetadas
especificamente para oferecer suporte ao carregamento de scripts assíncrono e adiado (usando a flag
buffered). Portanto, não é necessário se apressar para carregar os scripts com antecedência.
Caso você esteja medindo uma métrica que não pode ser calculada mais tarde na
linha do tempo de carregamento da página, in-line somente o código que precisa ser executado antecipadamente
na <head> do documento (portanto, não é uma solicitação
de bloqueio de renderização) e adie o restante. Não carregue todas as suas análises antecipadamente só porque uma única métrica precisa dele.
Não crie tarefas longas
O código do Analytics geralmente é executado em resposta à entrada do usuário. No entanto, se o código de análise estiver realizando muitas medições de DOM ou usando outras APIs com uso intensivo de processador, o próprio código de análise poderá causar uma baixa capacidade de resposta das entradas. Além disso, se o arquivo JavaScript que contém o código de análise for grande, a execução desse arquivo poderá bloquear a linha de execução principal e afetar negativamente a latência na primeira entrada (FID, na sigla em inglês) ou a interação com a próxima exibição (INP, na sigla em inglês).
Usar APIs sem bloqueio
APIs como
sendBeacon()
e
requestIdleCallback()
foram projetadas especificamente para executar tarefas não críticas de uma maneira que não
bloqueia tarefas essenciais aos usuários.
Essas APIs são ótimas ferramentas para usar em uma biblioteca de análise de RUM.
Em geral, todos os beacons de análise precisam ser enviados usando a API sendBeacon()
(se disponível), e todo o código de medição de análise passiva precisa ser executado durante
períodos de inatividade.
Não monitore mais do que o necessário
O navegador expõe muitos dados de desempenho, mas o fato de estarem disponíveis não significa necessariamente que você precisa registrá-los e enviá-los aos servidores de análise.
Por exemplo, a API Resource Timing fornece dados de tempo detalhados para cada recurso carregado na sua página. No entanto, é pouco provável que todos esses dados sejam necessariamente ou úteis para melhorar o desempenho da carga de recursos.
Em suma, não acompanhe os dados apenas porque eles estão lá. Garanta que os dados serão usados antes de consumir os recursos que os rastreiam.