Como monitorar a performance de vários sites e pegar regressões

Para acompanhar as Core Web Vitals de muitos sites e pegar regressões a tempo, uma agência precisa de duas fontes trabalhando juntas. Dados de campo dizem se o visitante real está tendo problema: o CrUX do Google dá a visão geral de graça, mas com atraso de até 28 dias, e uma coleta própria (RUM) mostra o efeito de um deploy em horas e aponta a causa. Testes de laboratório agendados, com várias execuções e comparação pela mediana, pegam a regressão antes ou logo depois da publicação. Por cima disso entram orçamentos de performance por tipo de página, alertas ligados ao momento do deploy, recorte por modelo de página e por dispositivo, e um relatório que separa o que é dado de campo do que é teste.

O texto vale para as ferramentas e limites públicos do Google em outubro de 2026. Ele não compara serviços comerciais; fala de categorias de ferramenta e do que cada fonte de dado permite.

Campo e laboratório têm papéis diferentes

Dado de campo vem de visitas reais. Dado de laboratório vem de um carregamento simulado, com aparelho, rede e local fixos. A web.dev recomenda usar o campo para medir e priorizar e o laboratório para diagnosticar (web.dev, ferramentas de Core Web Vitals). Os dois divergem por motivos conhecidos: cache vazio no teste, aparelho e rede únicos, ausência de rolagem e cliques, conteúdo personalizado e o fato de o campo ser uma distribuição de 28 dias (web.dev, diferenças entre laboratório e campo).

Para uma carteira de sites isso vira uma regra de trabalho: o alerta que importa ao cliente é o de campo, e o teste de laboratório serve para pegar a regressão cedo e explicar a causa. A comparação completa entre as fontes está em Lighthouse, CrUX e RUM; os limites de cada métrica, no guia de Core Web Vitals.

Dados de campo do CrUX: o que cada acesso entrega

O CrUX (Chrome User Experience Report) tem três formas de acesso programático. Elas diferem em frequência, granularidade e custo.

Fontes: CrUX API, CrUX History API e CrUX no BigQuery. Para ver a série semanal sem programar, o CrUX Vis mostra os dados da History API em gráficos.

Para saber se a cota basta, faça a conta. Um exemplo: 40 sites, cada um com a origem e mais 5 URLs importantes, consultados para celular e desktop, somam 480 consultas por dia, o que cabe em pouco mais de 3 minutos no limite de 150 por minuto.

Três limitações pesam no monitoramento:

1. A janela de 28 dias suaviza tudo. Uma regressão publicada hoje entra aos poucos na média e só aparece por inteiro semanas depois. Isso serve para relatório de tendência, não para alerta de deploy (web.dev).

2. Nem todo site ou URL tem dados. Só entram páginas e origens que podem ser descobertas publicamente e têm visitas suficientes; o mínimo não é divulgado. Sites pequenos da carteira podem não ter dado de URL, ou nem de origem (metodologia do CrUX).

3. Só entram usuários do Chrome no desktop e no Android que atendem aos critérios de coleta. Visitas de outros navegadores não aparecem (metodologia do CrUX).

RUM próprio: dados do dia e com a causa

RUM (real user monitoring) é a coleta feita por um script no próprio site, que envia as métricas de cada visita para um servidor seu ou de um serviço. A web.dev recomenda montar esse conjunto próprio de dados e usar o CrUX como comparação (web.dev). Uma base pronta é a biblioteca web-vitals, do time do Chrome, que mede LCP, INP, CLS, FCP e TTFB do mesmo jeito que o Chrome mede para as ferramentas do Google. Ela tem cerca de 3 KB comprimida com brotli; a versão com atribuição acrescenta cerca de 1,5 KB e informa o elemento ou a interação que causou cada valor (web-vitals).

Alguns cuidados de implementação, segundo a documentação da biblioteca e a web.dev:

• Envie os dados quando a página fica oculta (evento visibilitychange), com navigator.sendBeacon(), e não no unload ou beforeunload (web-vitals).

• Mande junto a informação de diagnóstico: o elemento do LCP, o alvo e o tipo da interação do INP, o elemento do maior deslocamento do CLS. Agregando esses alvos entre todos os visitantes, aparecem os elementos que mais pesam no p75 (web.dev, depurar performance em campo).

• Os valores de LCP, INP, FCP e TTFB funcionam no Chrome, no Firefox e no Safari; o CLS, por enquanto, só nos navegadores Chromium (web-vitals). Ao comparar RUM com CrUX, filtre o Chrome para comparar a mesma população.

• O script coleta dados de visitantes. Não envie no beacon nada que identifique a pessoa, como e-mail ou parâmetros de URL com dados pessoais, e confira com quem cuida da privacidade do cliente se o script precisa constar na política do site.

Com RUM é possível comparar o p75 de antes e depois de um deploy em um ou dois dias, desde que a página tenha visitas suficientes para a amostra fazer sentido.

Testes de laboratório agendados sem se enganar com a variação

Rodar o Lighthouse uma vez por dia em cada site e alertar quando a nota cair tende a gerar alarme falso. A documentação do Lighthouse lista as fontes de variação entre execuções: conteúdo da página que muda (testes A/B, anúncios), rede local, hardware da máquina de teste, disputa de CPU com outros processos, servidor web e o próprio navegador. A recomendação é rodar várias vezes e olhar valores agregados, como a mediana, em vez de um resultado isolado. Segundo o mesmo documento, a mediana de 5 execuções é duas vezes mais estável que uma execução (Lighthouse, variabilidade).

Para testes agendados de muitos sites, o mesmo documento recomenda:

1. Usar máquinas dedicadas, com pelo menos 2 núcleos (4 recomendados) e 2 GB de memória (4 a 8 GB recomendados), evitando instâncias compartilhadas ou com CPU intermitente.

2. Não rodar vários Lighthouse ao mesmo tempo na mesma máquina. Numa carteira grande, isso significa fila, não paralelismo na mesma instância.

3. Manter a configuração igual em todas as execuções: mesmo perfil de dispositivo, mesma limitação de rede e CPU e mesmo local de teste. A limitação simulada reduz a variação causada pela rede.

4. Isolar o que der: desativar extensões e antivírus na máquina de teste e, se possível, testar uma versão da página sem anúncios ou testes A/B rodando.

O laboratório não mede INP, porque não há visitante clicando. O substituto no Lighthouse é o TBT (Total Blocking Time), o tempo em que a thread principal ficou bloqueada durante o carregamento (web.dev). Uma alta no TBT é um bom sinal de que o INP de campo pode piorar, mas não é o INP.

Orçamentos de performance por tipo de página

Um orçamento de performance é um conjunto de limites para métricas que afetam a performance do site. A web.dev descreve três tipos: limites de quantidade (peso de imagens e scripts, número de fontes, scripts de terceiros), limites de tempo em métricas centradas no usuário e limites de nota em ferramentas como o Lighthouse. A recomendação é combinar quantidade com métricas de usuário, definir limites por tipo de página e aplicá-los no processo de build; quando um limite estoura, as saídas são otimizar, remover ou não adicionar o recurso novo (web.dev, orçamentos de performance). O Lighthouse CI, projeto de código aberto do Google, roda o Lighthouse a cada commit e verifica orçamentos de scripts e imagens (Lighthouse CI).

O artigo da web.dev sobre orçamentos é de 2018 e cita métricas anteriores às Core Web Vitals. Uma forma atual de aplicar a mesma ideia, e aqui é recomendação, não regra do Google:

• Para métricas de tempo, use os limites de "bom" das Core Web Vitals (LCP até 2,5 s, CLS até 0,1) no laboratório e no RUM, e o TBT como sinal para o INP.

• Para quantidade, parta do que cada modelo de página tem hoje e defina um teto um pouco acima, para que um script ou imagem nova não passe sem alguém notar.

• Defina por modelo de página. Uma página de produto e um artigo de blog têm pesos e elementos de LCP diferentes; um orçamento único para o site inteiro ou fica frouxo demais ou dispara o tempo todo.

Orçamento de quantidade não se aplica bem a sites em que o cliente publica conteúdo pesado com frequência sem passar pela equipe; nesse caso, o limite vira motivo de conversa sobre o processo editorial, e o alerta de campo pesa mais.

Alertas de regressão depois de um deploy

Um alerta útil liga a mudança na métrica a um evento: deploy, atualização de plugin, nova tag de marketing. Um processo possível com as fontes acima:

1. Registre cada deploy com data, hora, site e versão. Sem isso, a investigação começa pela pergunta "o que mudou?".

2. Antes de publicar, rode o laboratório (5 execuções, mediana) nas URLs representativas de cada modelo de página afetado, em ambiente de homologação se houver.

3. Depois de publicar, rode de novo em produção, com a mesma configuração, e compare as medianas. Alerte quando a mediana passar do orçamento ou cruzar a faixa de "bom", e não por qualquer oscilação de nota.

4. No RUM, compare o p75 da janela depois do deploy com o da janela anterior, por modelo de página e por dispositivo, assim que houver amostra suficiente.

5. Acompanhe o CrUX nas semanas seguintes para confirmar que a melhora ou a piora chegou aos dados que o Google usa.

Os critérios dos passos 3 e 4 são recomendação. O Google não define o que conta como regressão; o ponto é evitar que uma variação normal entre execuções vire alerta.

Segmentar por modelo de página e por dispositivo

Páginas do mesmo modelo (template) compartilham código: todas as páginas de produto usam o mesmo componente de galeria, todos os posts carregam o mesmo bloco de anúncio. Por isso um problema de performance tende a se repetir no modelo inteiro. O próprio Search Console trabalha assim: o relatório Core Web Vitals agrupa URLs com experiência parecida, dá a cada grupo um status separado para celular e desktop e usa a pior métrica como status do grupo (ajuda do Search Console).

Na prática, para cada site da carteira:

• Liste os modelos de página que geram tráfego ou receita (início, categoria, produto, artigo, checkout) e escolha uma ou duas URLs representativas de cada um para o laboratório.

• No RUM, envie o nome do modelo junto com cada métrica, para agregar por modelo em vez de por URL.

• Separe sempre celular e desktop. Telas diferentes mostram elementos diferentes, então o elemento do LCP e a origem do CLS podem mudar de um para o outro (web.dev).

Relatório para o cliente

Uma estrutura possível para o relatório mensal:

• O p75 de LCP, INP e CLS em celular e desktop, com a faixa (bom, precisa melhorar, ruim) e a fonte do dado.

• A tendência das últimas semanas, que a CrUX History API e o CrUX Vis fornecem para até 40 semanas.

• O que mudou no período (deploys, tags novas, correções) e o efeito observado no RUM.

• O que fica para o próximo ciclo, com a métrica e o modelo de página afetados.

Dois cuidados. Primeiro, não use a nota do Lighthouse como número principal: a web.dev recomenda priorizar as Core Web Vitals de campo em vez de notas do Lighthouse (web.dev), e a nota varia entre execuções. Segundo, não prometa ganho de posição no Google. A documentação do Google diz que as Core Web Vitals são usadas pelos sistemas de ranking, mas que bons resultados não garantem o topo e que a busca prioriza o conteúdo mais relevante (Google Search Central).

Como fazer isso com o WebVyze

Nos planos pagos do WebVyze, cada site da carteira tem auditorias e relatórios agendados e alertas por e-mail, push, Slack, Teams, Google Chat, WhatsApp ou Telegram. O script de visitantes reais (cerca de 10 KB, baseado na biblioteca web-vitals) registra LCP, INP e CLS de cada visita com a causa. Cada problema vira uma issue com evidência e guia de correção, e só é marcada como resolvida depois que o WebVyze verifica de novo. A partir do plano Growth, o portal do cliente dá acesso aos resultados para quem contratou a agência. Para uma consulta rápida sem cadastro, o teste de Core Web Vitals mostra os dados do CrUX de até 10 URLs, em celular e desktop. O WebVyze só lê páginas públicas e não altera os sites.