Monitoramento de Core Web Vitals em milhares de páginas de telecom: guia prático

Como garantir que milhares de páginas de ofertas de banda larga, mapas de cobertura e portais de autoatendimento mantenham Core Web Vitals saudáveis sem afogar a equipe de engenharia em alertas falsos?

Provedores de telecom operam em escala: cada cidade tem sua landing page, cada plano tem sua ficha técnica, cada região tem seu mapa de fibra. O desafio não é medir uma página — é medir 50 mil URLs, entender quais templates regressaram e priorizar correções que movem a agulha de receita.

Por que monitoramento em escala exige estratégia diferente

O monitoramento pontual funciona para e-commerces com centenas de SKUs. Em telecom, a arquitetura baseada em templates (uma página de oferta replicada para 500 municípios) significa que um regresso no componente “Hero do Plano” afeta 500 URLs simultaneamente. Agrupar por template, não por URL, é a única forma de triagem viável.

O CrUX (Chrome User Experience Report) agrega dados por origem e por URL, mas sua granularidade de 28 dias mascara regressões recentes. Equipes maduras combinam três fontes: CrUX para visão histórica e comparação competitiva, Lighthouse CI para gate de qualidade no deploy, e RUM próprio para visibilidade em tempo real segmentada por dispositivo, conexão e região.

Arquitetura de coleta: CrUX BigQuery + Lighthouse CI + RUM leve

A base está no projeto chrome-ux-report no BigQuery. Uma query diária extrai LCP, CLS, INP e TTFB por origem e por URL, particionada por data. Para telecom, filtre por device = 'phone' (maioria do tráfego de contratação) e effective_connection_type = '4g' (cenário realista).

SELECT
  origin,
  yyyymmdd,
  device,
  effective_connection_type,
  APPROX_QUANTILES(lcp, 100)[OFFSET(75)] AS lcp_p75,
  APPROX_QUANTILES(cls, 100)[OFFSET(75)] AS cls_p75,
  APPROX_QUANTILES(inp, 100)[OFFSET(75)] AS inp_p75
FROM `chrome-ux-report.all.2024*`
WHERE origin IN ('https://provedor.exemplo.br', 'https://cobertura.provedor.exemplo.br')
  AND device = 'phone'
  AND effective_connection_type = '4g'
GROUP BY origin, yyyymmdd, device, effective_connection_type
ORDER BY yyyymmdd DESC

O Lighthouse CI roda no GitHub Actions/GitLab CI a cada PR. Defina budgets por template: lcp: 2500, cls: 0.1, total-blocking-time: 300. Falha no budget bloqueia o merge. Use lighthouse-ci com configuração dedicada por pasta de templates.

Para RUM, a biblioteca web-vitals (1KB gzipped) envia métricas para endpoint próprio (Cloud Functions, Lambda, ou worker). Capture navigation, resource e long-task entries. Envie amostragem de 10% em mobile, 100% em desktop para controlar custos.

Dashboards e alertas que a equipe realmente usa

Dashboards bonitos que ninguém abre servem para apresentação, não para operação. Três painéis essenciais:

1. Visão executiva: % de origens com LCP p75 < 2.5s, CLS p75 < 0.1, INP p75 < 200ms — tendência 90 dias.
2. Por template: tabela com template, URLs afetadas, LCP p75 atual vs 7 dias atrás, delta CLS, status (verde/amarelo/vermelho).
3. Drill-down RUM: percentis por dispositivo, conexão, UF, horário — para diagnosticar “LCP alto só no Nordeste à noite”.

Alertas no Grafana/Alertmanager: dispare quando mais de 10% das URLs de um template excederem threshold por 2 dias consecutivos. Evita ruído de flutuação estatística. Roteie para canal #perf-alerts no Slack com link direto para drill-down do template.

Priorização: o que corrigir primeiro quando tudo está vermelho

Nem todo regresso merece sprint. Use matriz de impacto:

Templates de “Oferta de Plano” e “Mapa de Cobertura” costumam liderar. Um preload da hero image, font-display: swap na fonte da marca, ou remoção de script de chat terceirizado no critical path resolvem 60% dos casos.

Integração com SEO programático e deploy contínuo

Times de SEO programático geram páginas em massa. O contrato entre SEO e Engenharia: toda nova variação de template passa por Lighthouse CI antes de ir para produção. Use feature flags para lançar novo template em 5% do tráfego, monitorar RUM por 48h, então expandir.

A agência Pagi atua nessa ponte, validando se a geração em massa preserva budgets de performance. O fluxo ideal: PR com novo template → Lighthouse CI gate → canary deploy com RUM → validação CrUX 28 dias depois → rollout total.

Processo semanal de triagem e retrospectiva de performance

Toda segunda-feira, 30 minutos:

1. Revisar alertas disparados na semana (falsos positivos? regressões reais?)
2. Top 5 templates com pior delta LCP/CLS vs semana anterior
3. Definir owner e prazo para cada item (máx. 2 sprints)
4. Registrar no changelog de performance: “Template Oferta v3.2: LCP 3.2s → 2.1s via preload + WebP”
5. Validar no CrUX após 28 dias: a melhoria apareceu no p75?

Esse loop fecha o ciclo entre código, deploy, métrica real e decisão de negócio.

Conclusão prática

Monitorar Core Web Vitals em milhares de páginas de telecom não é sobre ter mais dashboards — é sobre agrupar por template, combinar CrUX + Lighthouse CI + RUM leve, e criar um ritual semanal de 30 minutos que transforma dados em correções priorizadas por receita. Comece mapeando seus 5 templates mais acessados, configure a query BigQuery hoje e o Lighthouse CI no próximo sprint. O resto é iteração disciplinada.

Checklist prático

Perguntas frequentes