Dimensão Core/Dash: Navegador

Dimensão: Navegador (browser)

A dimensão Navegador agrupa dados de desempenho baseados na string de User Agent enviada pelo cliente. Isso permite que você audite o desempenho dos Core Web Vitals através da lente 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 no mecanismo de renderização (Blink, Gecko, WebKit) e compatibilidade de scripts de terceiros.

RUM vs. CrUX

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

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

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

Diagnósticos Específicos de Métricas

Diferentes mecanismos 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 mecanismo.

Interaction to Next Paint (INP)

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

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

Largest Contentful Paint (LCP)

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

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

Cumulative Layout Shift (CLS)

Os mecanismos de renderização calculam a geometria de pixels usando lógicas sub-pixel distintas.

• Renderização de Fontes (Gecko vs. Blink): Firefox (Gecko) e Chrome (Blink) renderizam as linhas de base das fontes e o rastreamento de forma ligeiramente diferente. Se você não corresponder perfeitamente as métricas da sua fonte de fallback, o bloco de texto será redimensionado quando a fonte da web carregar, causando uma mudança 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 os navegadores macOS as sobrepõem. Esta disparidade frequentemente causa mudanças de layout baseadas em largura que são invisíveis durante o desenvolvimento em um Mac, mas proeminentes para usuários do Windows.

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

O principal caso de uso para esta dimensão é "Validação do Mecanismo".

• Identifique o Ponto Fora da Curva: Classifique 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: Confirme 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).
• Depuração: Se o Edge é lento mas o Chrome é rápido (ambos usam Blink), investigue extensões de terceiros ou software de segurança corporativo comum a usuários do Edge que injetam scripts no DOM.Se o Firefox é lento, audite seu CSS em busca de propriedades não padronizadas ou thrashing de layout que o Gecko penaliza mais severamente do que o Blink.

Navegadores Legados e Embutidos

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

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

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