Como medir as Core Web Vitals com sua ferramenta de análise atual.
Ter a capacidade de medir e informar 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álise de monitoramento de usuários reais (RUM) conhecidos já oferecem suporte às métricas de Core Web Vitals nas ferramentas (assim como a muitos outros recursos do tipo). 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álises que queiram adicionar suporte às Core Web Vitals ao serviço.
Usar métricas ou eventos personalizados
Como mencionado acima, a maioria das ferramentas de análise permite medir dados personalizados. Se a sua ferramenta de análise for compatível, você poderá medir cada uma das métricas 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:
- 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.
- Calcule o valor da métrica no código JavaScript do front-end.
- 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 métricas 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 de uma métrica de performance 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 um único usuário. Os valores atípicos 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 ou dispositivos extremamente lentos que estão na faixa máxima de valores, mas não representam sessões de usuário 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 desempenho 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, você ainda poderá gerar esses dados manualmente, criando um relatório que liste todos os valores de métrica em ordem crescente. Depois que esse relatório é gerado, o resultado que está a 75% da lista completa e classificada de todos os valores nesse relatório será a 75ª percentil da métrica. Isso vai acontecer independentemente de como você segmentar 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.
Enviar 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 qualquer script nessa 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 de navegação.
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 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, vários fatores (incluindo o armazenamento em cache no HTTP, no service worker ou na camada CDN) podem 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 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 medir a performance em usuários reais, é fundamental que qualquer código de medição de desempenho que você esteja executando 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 do 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 calculada mais tarde na
linha do tempo de carregamento da página, somente o código que precisa ser executado mais cedo
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 fornece 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.