Dimensão Core/Dash: Navegador

Dimensão: Página e Navegação: URLs (u)

A dimensão Navegador agrupa dados de performance com base na string de User Agent enviada pelo cliente. Isso permite auditar a performance das Core Web Vitals através da ótica do software específico que renderiza a sua aplicação (ex: Chrome, Firefox, Safari, Edge, Samsung Internet).

A dimensão Navegador isola restrições de software, diferenças de motores de renderização (Blink, Gecko, WebKit) e compatibilidade de scripts de terceiros.

RUM vs. CrUX

Entender a fonte dos seus dados é importante para uma análise de engenharia precisa.

• CrUX (Chrome User Experience Report): Este conjunto de dados coleta dados exclusivamente de usuários opt-in no Chrome (e alguns derivados do Chromium). Ele exclui cegamente o tráfego do Firefox (motor Gecko) e Safari (motor WebKit).
• CoreDash RUM: Coleta dados de todo navegador que executa o snippet JavaScript.

Para muitos sites, navegadores não-Chrome representam 30-50% do tráfego. Depender apenas do CrUX cria um ponto cego: você está otimizando para o motor V8 do Google enquanto negligencia os motores SpiderMonkey (Firefox) e JavaScriptCore (Safari) usados por um segmento massivo da sua audiência.

Diagnósticos Específicos por Métrica

Diferentes motores de navegador gerenciam recursos, compilam JavaScript e calculam a geometria de layout de forma diferente. Use esta dimensão para identificar falhas específicas do motor.

Interaction to Next Paint (INP)

Problemas de INP correlacionam-se diretamente com a eficiência do motor JavaScript do navegador e o agendamento da main-thread.

• Firefox (SpiderMonkey): O Firefox lida com a priorização de tarefas de forma diferente do Chrome. Um event listener pesado que passa no Chrome pode causar um atraso de entrada notável no Firefox devido a diferenças em como a main-thread realiza o yielding.
• Safari (JavaScriptCore): frequentemente exibe comportamentos distintos em relação à latência de "toque" em dispositivos móveis. A lógica de hidratação que parece instantânea no Android (Chrome) pode acionar atrasos no iOS devido a modelos distintos de propagação de eventos.

Largest Contentful Paint (LCP)

Discrepâncias de LCP geralmente sinalizam falta de paridade de recursos ou suporte para APIs modernas de otimização.

• Negociação de Formato: Se o Chrome relata um LCP rápido mas o Firefox fica para trás, verifique sua estratégia de formato de imagem. Você pode estar servindo AVIF para o Chrome enquanto faz fallback para JPEGs maiores para versões de navegador mais antigas que não possuem suporte.
• Priority Hints: O Chrome respeita agressivamente fetchpriority="high". Navegadores que ignoram este atributo tratam o recurso de LCP com prioridade padrão, inflando artificialmente o Load Delay.
• Protocolos de Conexão: Edge e Firefox podem negociar conexões HTTP/3 (QUIC) de forma diferente em ambientes corporativos ou de rede restrita, impactando o componente TTFB do LCP.

Cumulative Layout Shift (CLS)

Motores de renderização calculam a geometria de pixels usando lógica de sub-pixel distinta.

• Renderização de Fonte (Gecko vs. Blink): Firefox (Gecko) e Chrome (Blink) renderizam baselines de fonte e tracking de forma ligeiramente diferente. Se você não corresponder perfeitamente às métricas da sua fonte de fallback, o bloco de texto será redimensionado quando a web font carregar, causando um shift em um navegador mas não no outro.
• Reserva de Barra de Rolagem: Navegadores Windows (Edge/Firefox/Chrome) reservam espaço físico para barras de rolagem, enquanto navegadores macOS as sobrepõem. Essa disparidade frequentemente causa layout shifts baseados na largura que são invisíveis durante o desenvolvimento em um Mac, mas proeminentes para usuários Windows.

Fluxo de Trabalho: Isolando Regressões Específicas do Motor

O principal caso de uso para esta dimensão é a "Validação de Motor".

• Identifique o Outlier: Ordene sua tabela de Navegador por Impacto ou Volume. Procure por um navegador específico (ex: Firefox Mobile) que tenha uma pontuação significativamente pior que a linha de base (Chrome Mobile).
• Verifique o Ambiente: Cheque se o problema está estritamente relacionado ao navegador ou a uma combinação de navegador e SO (ex: Edge no Android vs. Edge no Windows).
• Debug: Se o Edge está lento mas o Chrome está rápido (ambos usam Blink), investigue extensões de terceiros ou software de segurança empresarial comum a usuários do Edge que injetam scripts no DOM. Se o Firefox está lento, audite seu CSS para propriedades não padrão ou layout thrashing que o Gecko penaliza mais pesadamente que o Blink.

Navegadores Legados e Embarcados

Use a dimensão Navegador para identificar arrastos de performance de "Cauda Longa".

Navegadores In-App: O tráfego do Instagram, LinkedIn ou Facebook frequentemente roda em WebViews restritas que se comportam de forma diferente do navegador móvel nativo.

Versões Legadas: Você pode encontrar tráfego de versões desatualizadas de navegadores. Se estas geram alto INP, configure suas ferramentas de build (Babel/PostCSS) para servir os polyfills necessários ou, se o volume for negligenciável, tome a decisão estratégica de remover o suporte para reduzir o tamanho do bundle para usuários modernos.