Não existe uma maneira única de medir o desempenho do site. Dito isso, as métricas Core Web Vitals que o Google usa como fator de classificação são um excelente ponto de partida, pois cobrem diferentes aspectos da experiência do visitante:
- Pintura com maior conteúdo (LCP): Mede o tempo de carregamento inicial da página.
- Mudança cumulativa de layout (CLS): mede se o conteúdo está estável após a renderização.
- Interação com a próxima pintura (INP): mede a rapidez com que a página responde à entrada do usuário.
Existem também muitas outras métricas de desempenho da web que você pode usar para rastrear aspectos técnicos, como peso da página ou tempo de resposta do servidor. Embora muitas vezes não importem diretamente para o usuário final, eles fornecem informações sobre o que está deixando suas páginas mais lentas.
Você também pode usar a API User Timing para rastrear marcos de carregamento de página que são importantes especificamente em seu site.
Dados sintéticos e reais do usuário
Existem dois tipos diferentes de dados de desempenho na web:
- Testes sintéticos são executados em um ambiente de teste controlado.
- Dados reais do usuário é coletado de visitantes reais do site.
O monitoramento sintético pode fornecer relatórios superdetalhados para ajudá-lo a identificar problemas de velocidade da página. Você pode configurar exatamente como deseja coletar os dados, escolhendo uma velocidade de rede específica, tamanho do dispositivo ou local de teste.
Tenha uma ideia prática do monitoramento sintético usando o teste de velocidade de site DebugBear gratuito para verificar seu site.
Dito isso, suas configurações de teste sintético podem não corresponder ao que é típico de seus visitantes reais e você não pode criar um script de todas as maneiras possíveis pelas quais as pessoas podem interagir com seu site.
É por isso que você também precisa de monitoramento de usuário real (RUM). Em vez de olhar para uma experiência, você vê diferentes tempos de carregamento e como segmentos específicos de visitantes são impactados. Você pode revisar visualizações de páginas específicas para identificar o que causou o baixo desempenho de um determinado visitante.
Ao mesmo tempo, os dados reais do usuário não são tão detalhados quanto os relatórios de testes sintéticos, devido às limitações da API da web e às preocupações de desempenho.
DebugBear oferece monitoramento sintético e monitoramento de usuário real:
- Para configurar testes sintéticos, você só precisa inserir o URL de um site e
- Para coletar métricas reais do usuário, você precisa instalar um snippet analítico em seu site.
Três etapas para um site rápido
A coleta de dados ajuda você durante todo o ciclo de vida de suas otimizações de desempenho na web. Você pode seguir este processo de três etapas:
- Identificar: colete dados em seu site e identifique experiências lentas dos visitantes.
- Diagnosticar: mergulhe profundamente na análise técnica para encontrar otimizações.
- Monitor: verifique se as otimizações estão funcionando e seja alertado sobre regressões de desempenho.
Vamos dar uma olhada em cada etapa em detalhes.
Etapa 1: identificar experiências lentas de visitantes
O que está levando você a analisar os problemas de desempenho do site em primeiro lugar? Você provavelmente já tem alguns problemas específicos em mente, seja por causa de relatórios de clientes ou por causa de pontuações baixas na seção Core Web Vitals do Google Search Console.
Dados reais do usuário são o melhor lugar para verificar páginas lentas. Ele informa se os problemas técnicos em seu site realmente resultam em uma experiência ruim para o usuário. É fácil coletar dados em todo o site (embora seja necessário configurar testes sintéticos para cada URL). E muitas vezes você pode obter uma contagem de visualizações junto com as métricas de desempenho. Uma página moderadamente lenta que recebe dois visitantes por mês não é tão importante quanto uma página moderadamente rápida que recebe milhares de visitas por dia.
O painel Web Vitals no produto RUM da DebugBear verifica a integridade do desempenho do seu site e exibe as páginas e URLs mais visitados onde muitos visitantes têm uma experiência ruim.
Você também pode executar uma verificação do site para obter uma lista de URLs do mapa do site e, em seguida, verificar cada uma dessas páginas com dados reais do usuário do Relatório de experiência do usuário do Chrome (CrUX) do Google. No entanto, isso só funcionará para páginas que atendam a um limite mínimo de tráfego a ser incluído no conjunto de dados CrUX.
O resultado da verificação destaca páginas com pontuações baixas de sinais vitais da web, nas quais você pode querer investigar mais detalhadamente.
Se nenhum dado do usuário real estiver disponível, existe uma ferramenta de verificação chamada Unlighthouse, que é baseada na ferramenta Lighthouse do Google. Ele executa testes sintéticos para cada página, permitindo filtrar os resultados para identificar as páginas que precisam ser otimizadas.
Etapa 2: diagnosticar problemas de desempenho na Web
Depois de identificar páginas lentas em seu site, você precisa observar o que realmente está acontecendo em sua página e que está causando atrasos.
Depurando o tempo de carregamento da página
Se houver problemas com as métricas de tempo de carregamento da página – como o Largest Contentful Paint (LCP) – os resultados dos testes sintéticos podem fornecer uma análise detalhada. Você também pode realizar experimentos de velocidade de página para testar e medir o impacto de certas otimizações.
Os dados reais do usuário ainda podem ser importantes ao depurar a velocidade da página, pois o tempo de carregamento depende de muitos fatores específicos do usuário e do dispositivo. Por exemplo, dependendo do tamanho do dispositivo do usuário, o elemento da página responsável pelo LCP pode variar. Os dados RUM podem fornecer uma análise de possíveis fatores de influência, como seletores CSS e URLs de imagens, para todos os visitantes, ajudando você a identificar exatamente o que precisa ser corrigido.
Depurando interações lentas
Geralmente, os dados RUM também são necessários para diagnosticar corretamente problemas relacionados à métrica Interação com a próxima pintura (INP). Especificamente, os dados reais do usuário podem fornecer informações sobre o que causa interações lentas, o que ajuda a responder perguntas como:
- Quais elementos da página são responsáveis?
- O tempo gasto é processado em tarefas em segundo plano já ativas ou no tratamento da interação em si?
- Quais scripts contribuem mais para o tempo geral de processamento da CPU?
Você pode visualizar esses dados em alto nível para identificar tendências, bem como revisar visualizações de páginas específicas para ver o que impactou a experiência de um visitante específico.
Etapa 3: monitorar o desempenho e responder às regressões
O monitoramento contínuo do desempenho do seu site permite acompanhar se o desempenho está melhorando após fazer uma alteração e alerta quando as pontuações diminuem.
A forma como você responde às regressões de desempenho depende se você está analisando testes sintéticos baseados em laboratório ou análises de usuários reais.
Dados Sintéticos
As configurações de teste para testes sintéticos são padronizadas entre as execuções. Embora alterações de infraestrutura, como atualizações de navegador, ocasionalmente causem alterações, o desempenho é geralmente determinado pelos recursos carregados pelo site e pelo código que ele executa.
Quando uma métrica muda, o DebugBear permite visualizar uma comparação antes e depois entre os dois resultados de teste. Por exemplo, a próxima captura de tela exibe uma regressão na métrica First Contentful Paint (FCP). A comparação revela que novas imagens foram adicionadas à página, competindo por largura de banda com outros recursos da página.
A partir do relatório, fica claro que um arquivo CSS que antes demorava 255 milissegundos para carregar agora leva 915 milissegundos. Como as folhas de estilo são necessárias para renderizar o conteúdo da página, isso significa que a página agora carrega mais lentamente, proporcionando uma visão melhor do que precisa de otimização.
Dados reais do usuário
Quando você observa uma mudança nas métricas reais do usuário, pode haver duas causas:
- Uma mudança nas características ou comportamento do visitante, ou
- Uma mudança técnica em seu site.
O lançamento de uma campanha publicitária, por exemplo, muitas vezes aumenta os redirecionamentos, reduz os acessos ao cache e altera a demografia dos visitantes. Ao observar uma regressão nos dados RUM, o primeiro passo é descobrir se a alteração ocorreu no seu site ou no navegador do visitante. Verifique se há alterações na contagem de visualizações em campanhas publicitárias, domínios de referência ou velocidade da rede para obter uma imagem mais clara.
Se essas visitas tiverem desempenho diferente em comparação com os visitantes típicos, isso sugere que a repressão não se deve a uma mudança no seu site. No entanto, talvez você ainda precise fazer alterações em seu site para melhor atender esses grupos de visitantes e proporcionar-lhes uma boa experiência.
Para identificar a causa de uma alteração técnica, observe as métricas de detalhamento de componentes, como subpartes do LCP. Isso ajuda a identificar a causa de uma regressão, seja devido a alterações no tempo de resposta do servidor, a novos recursos de bloqueio de renderização ou à imagem LCP.
Você também pode verificar mudanças nas propriedades de visualização de página, como diferentes seletores de elementos LCP ou scripts específicos que causam baixo desempenho.
Conclusão
Testes únicos de velocidade de página são um excelente ponto de partida para otimizar o desempenho. No entanto, uma ferramenta de monitoramento como o DebugBear pode formar a base para uma web mais abrangente. estratégia de desempenho isso ajuda você a permanecer rápido no longo prazo.
Obtenha uma avaliação gratuita do DebugBear em nosso site!
