Dimensión Core/Dash: Navegador

Dimensión: Navegador (browser)

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

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

RUM vs. CrUX

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

• CrUX (Chrome User Experience Report): Este conjunto de datos recopila información exclusivamente de usuarios de Chrome (y algunos derivados de Chromium) que han dado su consentimiento. Excluye a ciegas el tráfico de Firefox (motor Gecko) y Safari (motor WebKit).
• CoreDash RUM: Recopila datos de todos los navegadores que ejecutan el fragmento de JavaScript.

Para muchos sitios web, los navegadores distintos a Chrome representan entre el 30% y el 50% del tráfico. Depender únicamente de CrUX crea un punto ciego: estás optimizando para el motor V8 de Google mientras descuidas los motores SpiderMonkey (Firefox) y JavaScriptCore (Safari) utilizados por un segmento masivo de tu audiencia.

Diagnósticos Específicos por Métrica

Los diferentes motores de navegación gestionan recursos, compilan JavaScript y calculan la geometría del diseño de manera distinta. Utiliza esta dimensión para localizar fallos específicos del motor.

Interaction to Next Paint (INP)

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

• Firefox (SpiderMonkey): Firefox maneja la priorización de tareas de forma diferente a Chrome. Un event listener pesado que pasa la prueba en Chrome podría causar un input delay 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 los "toques" (tap) en móviles. La lógica de hidratación que se siente instantánea en Android (Chrome) puede provocar retrasos en iOS debido a distintos modelos de propagación de eventos.

Largest Contentful Paint (LCP)

Las discrepancias de LCP normalmente indican una falta de paridad de funciones o de soporte para APIs modernas de optimización.

• Negociación de Formatos: Si Chrome reporta un LCP rápido pero Firefox se retrasa, verifica tu estrategia de formato de imágenes. Es posible que estés sirviendo AVIF a Chrome mientras usas un fallback a JPEGs más pesados para versiones antiguas de navegadores que no tienen soporte.
• Priority Hints: Chrome respeta de manera agresiva 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 de red corporativos o restringidos, lo que impacta el componente TTFB del LCP.

Cumulative Layout Shift (CLS)

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

• Renderizado de Fuentes (Gecko vs. Blink): Firefox (Gecko) y Chrome (Blink) renderizan las líneas base y el espaciado (tracking) de las fuentes de manera ligeramente diferente. Si no ajustas perfectamente las métricas de tu fuente fallback, el bloque de texto cambiará de tamaño cuando cargue la fuente web, causando un desplazamiento en un navegador pero no en el otro.
• Reserva de Barras de Desplazamiento: Los navegadores de Windows (Edge/Firefox/Chrome) reservan espacio físico para las barras de desplazamiento (scrollbars), 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 una 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".

• Identifica el Valor Atípico: Ordena tu tabla de Navegadores por Impacto o Volumen. Busca un navegador específico (por ejemplo, Firefox Mobile) que tenga una puntuación significativamente peor que la línea base (Chrome Mobile).
• Verifica el Entorno: Comprueba si el problema está estrictamente relacionado con el navegador o con una combinación de navegador y sistema operativo (por ejemplo, Edge en Android frente a Edge en Windows).
• Depuración: Si Edge es lento pero Chrome es rápido (ambos usan Blink), investiga las extensiones de terceros o el software de seguridad empresarial común para los usuarios de Edge que inyectan scripts en el DOM.Si Firefox es lento, audita tu CSS en busca de propiedades no estándar o un "layout thrashing" que Gecko penaliza con mayor severidad que Blink.

Navegadores Antiguos e Integrados

Utiliza la dimensión Navegador para identificar los lastres de rendimiento del "Long Tail" (larga cola).

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

Versiones Antiguas: Es posible que encuentres tráfico de versiones de navegadores desactualizadas. Si estas generan un alto INP, configura tus herramientas de construcción (Babel/PostCSS) para servir los polyfills necesarios o, si el volumen es insignificante, toma la decisión estratégica de dejar de darles soporte para reducir el tamaño del bundle para los usuarios modernos.