Como avaliar as Métricas da Web com sua ferramenta de análise atual.
Medir e gerar relatórios sobre a performance real dos seus é fundamental para diagnosticar e melhorar o desempenho ao longo do tempo. Sem campo dados, é impossível saber com certeza se as mudanças feitas no site estão realmente alcançando os resultados desejados.
Muitos recursos populares de monitoramento real de usuários (RUM) já oferecem suporte às Core Web Vitals nos seus da Web, além de muitas outras métricas da Web (em inglês). Se você estiver usando uma dessas ferramentas de análise RUM, você está em grande forma para avalie se as páginas do seu site atendem às Core Web Vitals recomendadas limites e evita regressões no futuro.
Embora seja recomendado usar uma ferramenta de análise compatível com as Core Web Vitals métricas. Se a ferramenta de análise que você usa atualmente não for compatível com elas, não precisam mudar necessariamente. Quase todas as ferramentas analíticas oferecem uma maneira de definem e medem dados personalizados métricas ou eventos, o que significa que você pode usar seu provedor de análise atual para medir as Core Web Vitals métricas e adicioná-las aos seus relatórios e painéis de análise atuais.
Este guia aborda as práticas recomendadas para avaliar as 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 as ferramenta de análise de dados oferece suporte para isso, você pode medir cada um dos métricas do Android vitals usando esse mecanismo.
Medir métricas ou eventos personalizados em uma ferramenta de análise costuma ser uma um processo de três etapas:
- Defina ou inscreva-se a métrica personalizada na seção "Administrador" da ferramenta (se necessário). (Observação: nem todas provedores de análise de dados 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 de análise, garantindo que o nome ou ID corresponde 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 instruções. Para a etapa 2, use o método web-vitals para para calcular o valor de cada uma das Core Web Vitals.
O exemplo de código a seguir mostra como pode ser fácil acompanhar essas métricas em e enviá-los para 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);
Evitar médias
É tentador somar um intervalo de valores para uma métrica de desempenho calcular uma média. As médias parecem convenientes à primeira vista, pois são uma de uma grande quantidade de dados, mas você deve resistir à tentação de confiar 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 individual. Outliers em qualquer intervalo da distribuição podem distorcer a média de forma enganosa.
Por exemplo, um pequeno grupo de usuários pode estar em redes ou dispositivos extremamente lentos que estão no intervalo máximo de valores, mas não contabilizam para impactar a média de uma forma que sugira que há um problema.
Sempre que possível, use percentis em vez de médias. Percentis em um para uma determinada métrica de desempenho descreve melhor a gama completa de experiências do usuário para seu site. Isso permite que você se concentre em subconjuntos de experiências reais, que fornecem mais insights do que um único valor podia.
Verifique se é possível denunciar uma distribuição
Depois de calcular os valores de cada uma das Core Web Vitals e enviar ao seu serviço de análise usando uma métrica ou evento personalizado, a próxima etapa é para criar um relatório ou painel que mostre os valores coletados.
Para garantir que você está atendendo às Core Web Vitals recomendadas limites mínimos, você precisará do relatório para exibir o valor de cada métrica no 75o percentil.
Se a sua ferramenta de análise não oferecer relatórios de quantil como um recurso integrado, ainda é possível obter esses dados manualmente, gerando um relatório que lista cada valor de métrica classificado em ordem crescente. Depois que esse relatório é gerado, que representa 75% do caminho em toda a lista classificada e completa de todos os valores em esse relatório será o 75o percentil dessa métrica, e esse será o independentemente de como segmentar seus dados (por tipo de dispositivo, tipo de conexão, país etc.).
Se sua ferramenta de análise não fornecer granularidade de relatório no nível de métrica padrão, você provavelmente poderá alcançar o mesmo resultado se sua ferramenta de análise oferece suporte ao cliente e as dimensões personalizadas. Ao definir um um valor de dimensão personalizado exclusivo para cada instância de métrica individual acompanhada, você poderá gerar um relatório detalhado por métrica individual instâncias, 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 ocorrerá.
O Relatório de Métricas da Web é um exemplo dessa técnica que usa o Google Analytics. O código do arquivo relatório é de código aberto, para que os desenvolvedores possam consultá-lo como um exemplo das técnicas descritas neste nesta seção.
Envie seus dados no momento certo
Algumas métricas de desempenho podem ser calculadas assim que a página terminar de carregar. enquanto outros (como CLS) consideram toda a vida útil da página e são apenas quando a página começar a descarregar.
No entanto, isso pode ser um problema, já que tanto beforeunload quanto unload
eventos não são confiáveis (especialmente em dispositivos móveis) e o uso deles não é
recomendado
(pois eles podem impedir que uma página seja qualificada para a função Voltar
cache).
Para métricas que acompanham toda a vida útil de uma página, é melhor enviar o que
o valor atual da métrica for durante o evento visibilitychange, sempre que o
o estado de visibilidade da página muda para hidden. Isso acontece porque, quando a página
o estado de visibilidade mudar para hidden. Não há garantia de que algum script
a página poderá ser executada novamente. Isso é ainda mais válido para dispositivos móveis
sistemas em que o próprio app de navegador pode ser fechado sem callbacks de página.
sendo disparada.
Os sistemas operacionais para dispositivos móveis geralmente acionam visibilitychange.
ao trocar de guia ou de app ou fechar o próprio navegador.
Ele também dispara o evento visibilitychange ao fechar uma guia ou navegar até
uma nova página. Isso torna o evento visibilitychange muito mais confiável do que o
unload ou beforeunload.
Monitorar o desempenho ao longo do tempo
Depois de atualizar sua implementação de análise para acompanhar e gerar relatórios sobre as Core Web Vitals, a próxima etapa é acompanhar como as alterações no seu site afetam o desempenho ao longo do tempo.
Versão das mudanças
Uma abordagem simples (e, em última instância, não confiável) para rastrear alterações é implantar alterações na produção e, a seguir, suponha que todas as métricas recebidas após o de implantação correspondem ao novo site e a todas as métricas recebidas antes da de implantação correspondem ao site antigo. No entanto, qualquer número de fatores (incluindo armazenamento em cache na camada de HTTP, service worker ou CDN) pode evitar que isso de funcionar.
Uma abordagem muito melhor é criar uma versão exclusiva para cada alteração implantada e acompanhe essa versão na sua ferramenta de análise. A maioria das ferramentas de análise oferece suporte a configuração de uma versão. Se a sua não tiver, você pode criar uma dimensão personalizada e definir essa dimensão à versão implantada.
Fazer experimentos
Você pode ir além no controle de versões acompanhando várias versões (ou de pesquisa) ao mesmo tempo.
Se sua ferramenta de análise permitir que você defina grupos experimentais, use esse recurso. Também é possível usar dimensões personalizadas para garantir que cada um dos valores de métrica podem ser associadas a um grupo experimental específico em seus relatórios.
Com a experimentação em vigor na análise, você pode lançar uma alteração experimental em um subconjunto de usuários e comparar o desempenho que mudam no desempenho dos usuários do grupo de controle. Depois de ter a confiança de que uma mudança de fato melhora o desempenho, você pode lançá-la para para todos os usuários.
Verifique se a medição não afeta a performance
Ao avaliar o desempenho de usuários reais, é absolutamente essencial que qualquer o código de medição de performance que você está executando não afeta negativamente o o desempenho da sua página. Se sim, quaisquer conclusões que você tentar tirar de como seu desempenho afeta os negócios não serão confiáveis, nunca se sabe se a presença do código de análise em si é a maior impacto negativo.
Sempre siga estes princípios ao implantar o código de análise RUM no seu site de produção:
Adiar a análise
O código do Google Analytics deve sempre ser carregado de maneira assíncrona e sem bloqueio, e geralmente ele será carregado por último. Se você carregar seu código de análise isso pode afetar negativamente a LCP.
Todas as APIs usadas para medir as Core Web Vitals foram especificamente
projetada para dar suporte ao carregamento de script assíncrono e adiado (por meio da
buffered).
não é preciso apressar para carregar os scripts antecipadamente.
Se você estiver medindo uma métrica que não pode ser computada mais tarde na
linha do tempo de carregamento da página, coloque apenas o código que precisa ser executado antecipadamente
no <head> do documento (para que não seja um bloqueio de renderização)
solicitação) e adiar o restante. Não carregue todos os seus
a análise com antecedência só porque uma única métrica precisa dela.
Não criar tarefas longas
O código do Google Analytics geralmente é executado em resposta a entradas do usuário, mas se ele está realizando muitas medições de DOM ou usando outras APIs com uso intensivo de processador o próprio código de análise pode causar uma baixa capacidade de resposta de entradas. Além disso, se o arquivo JavaScript que contém o código de análise é grande, executando esse arquivo pode bloquear a linha de execução principal e afetar negativamente a Interação com a Next Paint (INP) de uma página.
Usar APIs sem bloqueio
APIs como
sendBeacon()
e
requestIdleCallback()
são projetados especificamente para executar tarefas não críticas de uma maneira que não
para bloquear
tarefas críticas ao usuário.
Essas APIs são ótimas ferramentas para usar em uma biblioteca de análise 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
os períodos de inatividade.
Não monitore mais do que precisa
O navegador expõe muitos dados de desempenho, mas só porque os dados estão disponível não significa necessariamente que você deve gravá-lo e enviá-lo para o seu servidores de análise de dados.
Por exemplo, a API Resource Timing fornece dados de tempo detalhados para cada recurso carregado na sua página. No entanto, é improvável que todos os dados sejam, necessariamente, úteis melhorando o desempenho do carregamento de recursos.
Resumindo, não acompanhe os dados porque eles estão lá, garanta que eles sejam usados antes de consumir recursos para monitorá-lo.