O Chrome introduziu uma nova forma de medir como a publicidade afeta a experiência real de uma página web.
Em 15 de setembro de 2026, o Chrome adicionou quatro métricas experimentais de publicidade ao Chrome User Experience Report, ou CrUX:
- Ad Count;
- Ad Density;
- Ad Weight: Network;
- Ad Weight: CPU.
As métricas foram projetadas para quantificar algo que publishers e anunciantes historicamente descreveram de forma subjetiva:
sobrecarga de anúncios.
A mudança importa porque o CrUX já é um dos sistemas de dados de campo mais importantes da web.
As novas métricas dão a publishers, anunciantes e plataformas de ad-tech um conjunto de dados público compartilhado para medir o quão pesado um ambiente publicitário parece para usuários reais.
Ad Count mede o volume de anúncios visíveis
Ad Count mede o número médio de elementos de anúncio distintos visíveis no viewport conforme o usuário percorre uma página.
O Chrome faz amostragem do viewport ao longo da visita.
Isso é mais útil do que simplesmente contar cada slot de anúncio no DOM.
Uma página pode conter dez posicionamentos de anúncios, mas expor apenas um pequeno número por vez.
Ad Count se concentra na experiência que o usuário realmente vê.
Ad Density mede quanto do viewport é publicidade
Ad Density mede a proporção média da área visível do viewport ocupada por anúncios.
Conceitualmente:
`Ad Density = Visible Ad Area / Viewport Area`
Isso é importante porque duas páginas podem ter o mesmo número de anúncios e parecer muito diferentes.
Página A: três anúncios pequenos.
Página B: três anúncios ocupando metade da tela.
O Ad Count é idêntico.
O Ad Density, não.
A métrica dá aos publishers uma forma de quantificar a competição visual entre conteúdo editorial e monetização.
Network Weight mede os dados consumidos por anúncios
Ad Weight: Network mede os bytes comprimidos transferidos para recursos relacionados a anúncios.
Isso inclui:
- scripts;
- imagens;
- estilos;
- outros recursos de anúncios.
O Chrome reporta a métrica em kilobytes.
Para publishers, isso adiciona um custo de monetização que muitas vezes é invisível nos dashboards de receita.
Uma unidade de anúncio de alto pagamento também pode criar:
- mais largura de banda;
- carregamento mais lento;
- pior experiência móvel.
A otimização correta pode, portanto, ser receita por unidade de custo de recurso, e não simplesmente CPM.
CPU Weight mede o custo de processamento
Ad Weight: CPU mede o tempo de execução consumido por frames de anúncio e seus sub-recursos.
O Chrome reporta o tempo de CPU em milissegundos.
Isso é relevante porque a publicidade pode criar custo de desempenho depois que o recurso foi baixado.
Scripts pesados podem continuar a usar recursos do dispositivo.
Isso afeta:
- responsividade;
- bateria;
- dispositivos de baixo custo;
- qualidade de navegação.
A monetização de anúncios, portanto, tem peso tanto de rede quanto de computação.
As métricas usam dados de campo
O Chrome afirma que as métricas de anúncios do CrUX usam o mesmo pipeline de dados de campo subjacente que outros dados do CrUX.
Elas se baseiam em experiências de usuários reais.
O Chrome reporta as métricas usando uma janela móvel de 28 dias.
Os ambientes compatíveis incluem o Chrome em:
- Windows;
- macOS;
- Android;
- ChromeOS;
- Linux.
Chrome no iOS e no Android WebView estão excluídos, assim como outros navegadores baseados em Chromium.
Isso significa que as métricas são amplas, mas não uma representação completa de todos os usuários da web.
Estas métricas não são Core Web Vitals
Essa distinção é crítica.
O Chrome afirma que as novas métricas de anúncios:
- compartilham a infraestrutura do CrUX;
- são inspiradas nas Web Vitals;
- não fazem parte das Core Web Vitals;
- não têm limites de “bom”, “precisa melhorar” ou “ruim”.
Atualmente, não há benchmarks oficiais.
Isso significa que os publishers não devem interpretar uma densidade de anúncios de 15% como “ruim” só porque o número parece alto.
As métricas são experimentais.
O Chrome está explicitamente buscando feedback do ecossistema.
Os dados estão disponíveis publicamente
O Chrome afirma que as métricas estão disponíveis por meio de:
- CrUX API;
- CrUX History API;
- painel Ad do DevTools.
O Chrome também está trabalhando para adicionar os dados ao conjunto de dados CrUX BigQuery.
Isso torna as métricas mais do que um recurso de diagnóstico do navegador.
Elas podem se tornar parte de:
- dashboards de publishers;
- ferramentas de qualidade de mídia;
- análise de compradores;
- monitoramento de CI/CD.
A natureza aberta dos dados é estrategicamente importante.
Compradores e vendedores podem, teoricamente, inspecionar os mesmos sinais de experiência de página.
Por que os anunciantes devem se importar
Os anunciantes geralmente avaliam o inventário por meio de métricas como:
- viewability;
- fraude;
- segurança de marca;
- atenção;
- CPM.
As métricas de anúncios do CrUX introduzem outra dimensão:
a qualidade do ambiente ao redor do anúncio.
Um posicionamento pode ser tecnicamente visível e ainda assim estar dentro de uma página sobrecarregada de anúncios concorrentes.
Esse ambiente pode afetar:
- atenção;
- percepção de marca;
- desempenho.
Ad Count e Ad Density podem se tornar sinais contextuais de qualidade.
Por que os publishers devem se importar
Os publishers têm um problema de otimização.
Mais anúncios podem aumentar a receita de curto prazo.
Anúncios demais podem reduzir:
- satisfação do usuário;
- profundidade da sessão;
- visitas de retorno;
- conversão de assinaturas.
Até agora, a parte do “demais” tem sido difícil de quantificar de forma consistente.
As novas métricas fornecem uma camada de telemetria compartilhada.
Um publisher pode testar:
- menos anúncios;
- formatos mais leves;
- lazy loading;
- densidade de posicionamento diferente.
E então comparar:
- receita;
- métricas de anúncios do CrUX;
- desempenho da página;
- engajamento.
Isso cria um experimento de monetização melhor.
Nenhuma conclusão sobre fator de ranking deve ser feita
Como as Core Web Vitals posteriormente passaram a ser associadas a sinais de ranking de busca, os profissionais de marketing podem ser tentados a supor que as novas métricas se tornarão fatores de SEO.
Não há base para essa conclusão hoje.
O Chrome afirma explicitamente que as métricas são separadas das Core Web Vitals.
O AdExchanger também reportou que o Chrome não criou limites e considera as métricas experimentais.
Os operadores devem usá-las como telemetria de experiência, não como uma pontuação especulativa de SEO.
Como os publishers podem usar as métricas
Modelos de benchmark
Compare:
- páginas de artigo;
- galerias;
- homepage;
- páginas de categoria.
Monitore o mobile separadamente
A carga de anúncios pode parecer muito mais pesada em telas menores.
Compare fornecedores de monetização
Se um parceiro aumenta consideravelmente o peso de CPU ou de rede, inclua esse custo na avaliação do fornecedor.
Teste receita vs. experiência
Construa experimentos em torno de:
- densidade de anúncios;
- posicionamento;
- refresh;
- formatos.
Meça tanto a receita quanto os resultados do usuário.
Adicione alertas de regressão
A History API pode ajudar a identificar quando uma mudança de template cria um aumento sustentado na carga de anúncios.
Um scorecard útil para publishers
Considere combinar:
Monetização
- RPM;
- viewability;
- taxa de preenchimento.
Experiência
- Ad Count;
- Ad Density;
- Network Weight;
- CPU Weight.
Desempenho
- Core Web Vitals;
- carregamento da página.
Público
- páginas por sessão;
- taxa de retorno;
- conversão de assinatura.
Isso impede que a monetização otimize em função de uma única métrica de curto prazo.
A implicação estratégica
O Chrome está transformando a experiência de anúncios em infraestrutura observável.
Isso pode mudar os incentivos.
Se os anunciantes puderem comparar o quão poluído ou pesado é um ambiente, experiências melhores de publishers podem se tornar mais fáceis de valorizar.
Se os publishers puderem quantificar quanta carga cada decisão de monetização adiciona, eles podem otimizar a receita com informações melhores.
As métricas são recentes.
Não há limites.
Elas não são sinais de ranking.
Mas elas criam algo de que a web aberta carecia:
uma linguagem pública para medir a carga publicitária que os usuários realmente experimentam.
Adicione métricas de anúncios do CrUX a experimentos de monetização
A aplicação imediata mais útil é a experimentação.
Suponha que um publisher esteja testando um novo layout de anúncios.
Variante A: densidade de anúncios maior.
Variante B: menos posicionamentos.
A medição tradicional pode comparar:
- RPM;
- viewability;
- taxa de preenchimento.
Agora o publisher pode adicionar:
- Ad Count;
- Ad Density;
- Network Weight;
- CPU Weight.
E então conectar isso a:
- profundidade da sessão;
- visitas de retorno;
- desempenho da página;
- conversão de assinaturas.
Isso cria uma função objetivo mais completa.
A versão vencedora não é necessariamente a que tem o RPM mais alto.
Pode ser a que produz a melhor receita de longo prazo por usuário.
Compradores podem criar filtros de qualidade
Anunciantes e agências também podem experimentar com os dados.
Por exemplo:
- identificar domínios de publishers em uma campanha;
- recuperar as métricas de anúncios do CrUX disponíveis;
- segmentar domínios por carga de anúncios;
- comparar resultados de desempenho e atenção.
Não presuma que mais leve sempre significa melhor.
O ponto é testar se a qualidade do ambiente de anúncios se correlaciona com:
- conversão;
- atenção;
- brand lift;
- viewability.
Espere que as métricas evoluam
O Chrome classifica todas as quatro métricas como experimentais.
Isso significa:
- as definições podem mudar;
- a disponibilidade vai se expandir;
- os casos de uso no ecossistema ainda estão surgindo.
As equipes devem armazenar o nome bruto da métrica e a data de coleta em vez de construir regras de negócio irreversíveis imediatamente.
O desenvolvimento importante não é um limite específico.
É que a carga de anúncios se tornou mensurável por meio de dados de campo públicos.
Quando um custo se torna observável, os mercados podem começar a precificá-lo.
