Coletar dados sobre os sinais vitais da Web do seu site é o primeiro passo para melhorá-los. Uma análise completa coletará dados de desempenho de ambientes do mundo real e de laboratório. Medir Web Vitals requer mudanças mínimas de código e pode ser realizado usando ferramentas gratuitas.
Medir dados vitais da Web usando dados RUM
Os dados do Real User Monitoring (RUM), também conhecidos como dados de campo, capturam o desempenho experimentado pelos usuários reais de um site. Os dados RUM são o que o Google usa para determinar se um site atende aos limites recomendados do Core Web Vitals.
Primeiros passos
Se você não tiver uma configuração de RUM, as ferramentas a seguir fornecerão rapidamente dados sobre o desempenho do seu site no mundo real. Essas ferramentas são todas baseadas no mesmo conjunto de dados subjacente (o Relatório de experiência do usuário do Chrome ), mas têm casos de uso ligeiramente diferentes:
- PageSpeed Insights (PSI) : relatórios do PageSpeed Insights sobre o desempenho agregado de nível de página e de origem nos últimos 28 dias. Além disso, fornece sugestões sobre como melhorar o desempenho. Se você está procurando uma ação única para começar a medir e melhorar os sinais vitais da Web do seu site, recomendamos o uso do PSI para auditar o seu site. O PSI está disponível na web e como API .
- Search Console : o Search Console relata dados de desempenho por página. Isso o torna adequado para identificar páginas específicas que precisam de melhorias. Ao contrário do PageSpeed Insights, os relatórios do Search Console incluem dados históricos de desempenho. O Search Console só pode ser usado com sites de sua propriedade e dos quais tenha a propriedade verificada.
- Painel CrUX : O painel CrUX é um painel pré-construído que apresenta dados CrUX para uma origem de sua escolha. Ele é baseado no Data Studio e o processo de configuração leva cerca de um minuto. Em comparação com o PageSpeed Insights e o Search Console, os relatórios do painel CrUX incluem mais dimensões – por exemplo, os dados podem ser divididos por dispositivo e tipo de conexão.
É importante notar que embora as ferramentas listadas acima sejam adequadas para “começar” a medir os sinais vitais da Web, elas também podem ser úteis em outros contextos.
Em particular, o CrUX e o PSI estão disponíveis como uma API e podem ser usados para construir painéis e outros relatórios.
Coletando dados RUM
Embora as ferramentas baseadas em CrUX sejam um bom ponto de partida para investigar o desempenho do Web Vitals, é altamente recomendável complementá-lo com seu próprio RUM.
Os dados RUM que você mesmo coleta podem fornecer feedback mais detalhado e imediato sobre o desempenho do seu site. Isso torna mais fácil identificar problemas e testar possíveis soluções.
As fontes de dados baseadas em CrUX relatam dados usando uma granularidade de aproximadamente um mês – no entanto, os detalhes disso variam ligeiramente de acordo com a ferramenta. Por exemplo, o PSI e o Search Console relatam o desempenho observado nos últimos 28 dias, enquanto o conjunto de dados CrUX e o painel são divididos por mês.
Você pode coletar seus próprios dados RUM usando um provedor de RUM dedicado ou configurando suas próprias ferramentas.
Provedores de RUM dedicados se especializam em coletar e relatar dados RUM. Para usar o Core Web Vitals com esses serviços, pergunte ao seu provedor de RUM sobre a ativação do monitoramento do Core Web Vitals para o seu site.
Se você não tiver um provedor RUM, poderá aumentar sua configuração de análise existente para coletar e relatar essas métricas usando a web-vitalsbiblioteca JavaScript . Este método é explicado com mais detalhes abaixo.
A biblioteca JavaScript web-vitals
Se você estiver implementando sua própria configuração de RUM para Web Vitals, a maneira mais fácil de coletar medições Web Vitals é usar a web-vitals biblioteca JavaScript. web-vitalsé uma pequena biblioteca modular (~ 1 KB) que fornece uma API conveniente para coletar e relatar cada uma das métricas Web Vitals mensuráveis em campo.
As métricas que constituem o Web Vitals não são todas expostas diretamente pelas APIs de desempenho integradas do navegador – mas sim construídas sobre elas. Por exemplo, Cumulative Layout Shift (CLS) é implementado usando a API de instabilidade de layout .
Ao usar web-vitals, você não precisa se preocupar em implementar essas métricas sozinho; também garante que os dados coletados correspondam à metodologia e às práticas recomendadas para cada métrica.
Para obter mais informações sobre a implementação web-vitals, consulte a documentação e as práticas recomendadas para medir os sinais vitais da Web no guia de campo.
Agregação de dados
É essencial que você relate as medições coletadas por web-vitals. Se esses dados forem medidos, mas não relatados, você nunca os verá. A web-vitalsdocumentação inclui exemplos que mostram como enviar os dados para um terminal de API genérico , Google Analytics ou Gerenciador de tags do Google.
Se você já tem uma ferramenta de relatório favorita, considere usá-la. Caso contrário, o Google Analytics é gratuito e pode ser usado para essa finalidade.
Ao considerar qual ferramenta usar, é útil pensar sobre quem precisará ter acesso aos dados. Normalmente, as empresas obtêm as maiores vitórias de desempenho quando toda a empresa, em vez de um único departamento, está interessada em melhorar o desempenho.
Consulte Corrigindo a velocidade de um site multifuncional para saber como obter a adesão de diferentes departamentos.
Interpretação de dados
Ao analisar os dados de desempenho, é importante prestar atenção às caudas da distribuição. Os dados RUM geralmente revelam que o desempenho varia amplamente – alguns usuários têm experiências rápidas, outros têm experiências lentas. No entanto, usar a mediana para resumir os dados pode mascarar facilmente esse comportamento.
Com relação ao Web Vitals, o Google usa a porcentagem de experiências “boas”, em vez de estatísticas como medianas ou médias, para determinar se um site ou página atende aos limites recomendados.
Especificamente, para um site ou página ser considerado como atingindo os limites do Core Web Vitals, 75% das visitas à página devem atender ao limite “bom” para cada métrica.
Medindo Web Vitals usando dados de laboratório
Os dados de laboratório , também conhecidos como dados sintéticos, são coletados de um ambiente controlado, em vez de usuários reais. Ao contrário dos dados RUM, os dados de laboratório podem ser coletados de ambientes de pré-produção e, portanto, incorporados aos fluxos de trabalho do desenvolvedor e processos de integração contínua. Exemplos de ferramentas que coletam dados sintéticos são Lighthouse e WebPageTest.
Algumas considerações
Sempre haverá discrepâncias entre os dados RUM e os dados do laboratório – principalmente se as condições da rede, tipo de dispositivo ou localização do ambiente do laboratório forem significativamente diferentes dos usuários.
No entanto, quando se trata de coletar dados de laboratório sobre métricas Web Vitals em particular, há algumas considerações específicas que são importantes a serem observadas:
- Mudança de layout cumulativa (CLS): A mudança de layout cumulativa medida em ambientes de laboratório pode ser artificialmente menor do que o CLS observado nos dados RUM. CLS é definido como a “soma total de todas as pontuações de mudança de layout individual para cada mudança de layout inesperada que ocorre durante toda a vida útil da página .” No entanto, a vida útil de uma página é normalmente muito diferente, dependendo se ela está sendo carregada por um usuário real ou por uma ferramenta de medição de desempenho sintética. Muitas ferramentas de laboratório carregam apenas a página – elas não interagem com ela. Como resultado, eles capturam apenas mudanças de layout que ocorrem durante o carregamento inicial da página. Por outro lado, o CLS medido pelas ferramentas RUM captura mudanças inesperadas de layout que ocorrem ao longo de toda a vida útil da página.
- Atraso da primeira entrada (FID): O atraso da primeira entrada não pode ser medido em ambientes de laboratório porque requer interações do usuário com a página. Como resultado, o Total Blocking Time (TBT) é o proxy de laboratório recomendado para FID. O TBT mede a “quantidade total de tempo entre a Primeira pintura com conteúdo e o Tempo para interação durante a qual a página é bloqueada de responder à entrada do usuário”. Embora o FID e o TBT sejam calculados de forma diferente, ambos são reflexos de um thread principal bloqueado durante o processo de bootstrap. Quando o thread principal é bloqueado, o navegador demora para responder às interações do usuário. O FID mede o atraso, se houver, que ocorre na primeira vez que um usuário tenta interagir com uma página.
ferramentas que irão te ajudar na mensuração
Essas ferramentas podem ser usadas para coletar medições de laboratório de Web Vitals:
- Web Vitals Chrome Extension: Os Web Vitals Chrome extensão medidas e reporta o Core Web Vitals (LCP, FID, e CLS) para uma determinada página. Esta ferramenta se destina a fornecer aos desenvolvedores feedback de desempenho em tempo real conforme eles fazem alterações no código.
- Lighthouse: o Lighthouse relata sobre LCP, CLS e TBT e também destaca possíveis melhorias de desempenho. O Lighthouse está disponível no Chrome DevTools, como uma extensão do Chrome e como um pacote npm. O Lighthouse também pode ser incorporado a fluxos de trabalho de integração contínua por meio do Lighthouse CI .
- WebPageTest: WebPageTest inclui Web Vitals como parte de seu relatório padrão. WebPageTest é útil para coletar informações sobre Web Vitals sob condições específicas de dispositivo e rede.
