Dimensión Core/Dash: Navegador

Dimensión: Página y Navegación: URLs (u)

La dimensión Navegador agrupa los datos de rendimiento basándose en la cadena User Agent enviada por el cliente. Esto le permite auditar el rendimiento de las Core Web Vitals a través de la lente del software específico que renderiza su aplicación (p. ej., Chrome, Firefox, Safari, Edge, Samsung Internet).

La dimensión Navegador aísla las restricciones de software, las diferencias del motor de renderizado (Blink, Gecko, WebKit) y la compatibilidad de scripts de terceros.

RUM vs. CrUX

Comprender la fuente de sus datos es importante para un análisis de ingeniería preciso.

• CrUX (Chrome User Experience Report): Este conjunto de datos recopila datos exclusivamente de usuarios que han dado su consentimiento en Chrome (y algunos derivados de Chromium). Excluye ciegamente el tráfico de Firefox (motor Gecko) y Safari (motor WebKit).
• CoreDash RUM: Recopila datos de cada navegador que ejecuta el fragmento de JavaScript.

Para muchos sitios web, los navegadores que no son Chrome representan entre el 30% y el 50% del tráfico. Confiar únicamente en CrUX crea un punto ciego: está optimizando para el motor V8 de Google mientras descuida los motores SpiderMonkey (Firefox) y JavaScriptCore (Safari) utilizados por un segmento masivo de su audiencia.

Diagnósticos específicos de métricas

Diferentes motores de navegador gestionan recursos, compilan JavaScript y calculan la geometría del diseño de manera diferente. Utilice esta dimensión para identificar fallos específicos del motor.

Interaction to Next Paint (INP)

Los problemas de INP se correlacionan directamente con la eficiencia del motor JavaScript del navegador y la programación del hilo principal.

• Firefox (SpiderMonkey): Firefox maneja la priorización de tareas de manera diferente a Chrome. Un event listener pesado que pasa en Chrome podría causar un retraso de entrada notable en Firefox debido a las diferencias en cómo el hilo principal realiza el yield.
• Safari (JavaScriptCore): a menudo exhibe comportamientos distintos con respecto a la latencia de "toque" en móviles. La lógica de hidratación que se siente instantánea en Android (Chrome) puede desencadenar retrasos en iOS debido a distintos modelos de propagación de eventos.

Largest Contentful Paint (LCP)

Las discrepancias de LCP generalmente señalan una falta de paridad de características o soporte para APIs de optimización modernas.

• Negociación de formato: Si Chrome reporta un LCP rápido pero Firefox se retrasa, verifique su estrategia de formato de imagen. Puede estar sirviendo AVIF a Chrome mientras recurre al fallback de JPEGs más grandes para versiones de navegador más antiguas que carecen de soporte.
• Priority Hints: Chrome respeta agresivamente fetchpriority="high". Los navegadores que ignoran este atributo tratan el recurso LCP con prioridad estándar, inflando artificialmente el Load Delay.
• Protocolos de conexión: Edge y Firefox pueden negociar conexiones HTTP/3 (QUIC) de manera diferente en entornos corporativos o de red restringida, impactando el componente TTFB del LCP.

Cumulative Layout Shift (CLS)

Los motores de renderizado calculan la geometría de píxeles utilizando una lógica de subpíxeles distinta.

• Renderizado de fuentes (Gecko vs. Blink): Firefox (Gecko) y Chrome (Blink) renderizan las líneas base y el tracking de las fuentes de manera ligeramente diferente. Si no hace coincidir perfectamente las métricas de su fuente de fallback, el bloque de texto cambiará de tamaño cuando se cargue la fuente web, causando un cambio en un navegador pero no en el otro.
• Reserva de barra de desplazamiento: Los navegadores de Windows (Edge/Firefox/Chrome) reservan espacio físico para las barras de desplazamiento, mientras que los navegadores de macOS las superponen. Esta disparidad a menudo causa cambios de diseño basados en el ancho que son invisibles durante el desarrollo en un Mac pero prominentes para los usuarios de Windows.

Flujo de trabajo: Aislamiento de regresiones específicas del motor

El caso de uso principal para esta dimensión es la "Validación del motor".

• Identifique el valor atípico: Ordene su tabla de Navegador por Impacto o Volumen. Busque un navegador específico (p. ej., Firefox Mobile) que tenga una puntuación significativamente peor que la línea base (Chrome Mobile).
• Verifique el entorno: Compruebe si el problema está estrictamente relacionado con el navegador o una combinación de navegador y sistema operativo (p. ej., Edge en Android vs. Edge en Windows).
• Depuración: Si Edge es lento pero Chrome es rápido (ambos usan Blink), investigue las extensiones de terceros o el software de seguridad empresarial común a los usuarios de Edge que inyectan scripts en el DOM. Si Firefox es lento, audite su CSS en busca de propiedades no estándar o layout thrashing que Gecko penaliza más fuertemente que Blink.

Navegadores heredados e integrados

Utilice la dimensión Navegador para identificar lastres de rendimiento del "Long Tail".

Navegadores In-App: El tráfico de Instagram, LinkedIn o Facebook a menudo se ejecuta en WebViews restringidas que se comportan de manera diferente al navegador móvil nativo.

Versiones heredadas: Puede encontrar tráfico de versiones de navegador obsoletas. Si estas generan un INP alto, configure sus herramientas de compilación (Babel/PostCSS) para servir los polyfills necesarios o, si el volumen es insignificante, tome la decisión estratégica de eliminar el soporte para reducir el tamaño del bundle para los usuarios modernos.