Dimensão Core/Dash: Navegador

Dimensão: Navegador (browser)

A dimensão Navegador agrupa dados de desempenho com base na string de User Agent enviada pelo cliente. Isso permite que você audite o desempenho do Core Web Vitals sob a perspectiva do software específico que renderiza 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 origem dos seus dados é importante para uma análise técnica precisa.

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

Para muitos sites, navegadores que não são o Chrome representam 30-50% do tráfego. Depender apenas do CrUX cria um ponto cego: você otimiza para o motor V8 do Google enquanto negligencia os motores SpiderMonkey (Firefox) e JavaScriptCore (Safari) usados por um segmento massivo do seu público.

Diagnósticos específicos por métrica

Diferentes motores de navegadores gerenciam recursos, compilam JavaScript e calculam a geometria de layout de formas distintas. Use esta dimensão para identificar falhas específicas de cada motor.

Interaction to Next Paint (INP)

Problemas de INP estão diretamente correlacionados com a eficiência do motor JavaScript do navegador e com o agendamento da main thread.

• Firefox (SpiderMonkey): O Firefox gerencia a priorização de tarefas de forma diferente do Chrome. Um event listener pesado que funciona bem no Chrome pode causar um atraso de entrada perceptível no Firefox devido a diferenças em como a main thread realiza o yielding.
• Safari (JavaScriptCore): costuma exibir comportamentos distintos em relação à latência de "tap" em dispositivos móveis. A lógica de hidratação que parece instantânea no Android (Chrome) pode causar 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 de 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 formatos de imagem. Você pode estar servindo AVIF para o Chrome enquanto usa um fallback de JPEGs maiores para versões mais antigas do navegador que não possuem suporte.
• Priority Hints: O Chrome respeita agressivamente o atributo fetchpriority="high". Navegadores que ignoram esse atributo tratam o recurso do LCP com prioridade padrão, inflando artificialmente o Load Delay.
• Protocolos de conexão: O Edge e o Firefox podem negociar conexões HTTP/3 (QUIC) de forma diferente em ambientes de rede corporativos ou restritos, afetando o componente TTFB do LCP.

Cumulative Layout Shift (CLS)

Motores de renderização calculam a geometria dos pixels usando lógicas de subpixel distintas.

• Renderização de fontes (Gecko vs. Blink): O Firefox (Gecko) e o Chrome (Blink) renderizam as linhas de base e o espaçamento (tracking) das fontes de forma ligeiramente diferente. Se você não alinhar perfeitamente as métricas da sua fonte de fallback, o bloco de texto mudará de tamanho quando a web font for carregada, causando uma mudança de layout em um navegador, mas não no outro.
• Reserva de barra de rolagem: Navegadores no Windows (Edge/Firefox/Chrome) reservam espaço físico para barras de rolagem, enquanto os navegadores no macOS as sobrepõem. Essa disparidade costuma causar mudanças de layout baseadas em largura que são invisíveis durante o desenvolvimento no Mac, mas proeminentes para usuários do 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 Browser por Impacto ou Volume. Procure por um navegador específico (ex: Firefox Mobile) que tenha uma pontuação significativamente pior do que a referência (Chrome Mobile).
• Verifique o ambiente: Verifique se o problema está estritamente relacionado ao navegador ou a uma combinação de navegador e sistema operacional (ex: Edge no Android vs. Edge no Windows).
• Depure: Se o Edge está lento mas o Chrome está rápido (ambos usam Blink), investigue extensões de terceiros ou softwares de segurança corporativa comuns em usuários do Edge que injetam scripts no DOM. Se o Firefox está lento, audite seu CSS em busca de propriedades não padrão ou layout thrashing que o Gecko penaliza com mais rigor do que o Blink.

Navegadores legados e embutidos

Use a dimensão Navegador para identificar gargalos de desempenho de "cauda longa" (long tail).

Navegadores in-app: O tráfego do Instagram, LinkedIn ou Facebook frequentemente roda em WebViews restritos 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 elas gerarem um INP alto, configure suas ferramentas de build (Babel/PostCSS) para servir os polyfills necessários ou, se o volume for desprezível, tome a decisão estratégica de descontinuar o suporte para reduzir o tamanho do bundle para usuários modernos.