Dimensión Core/Dash: Navegador

Dimensión: Navegador (browser)

La dimensión Navegador agrupa los datos de rendimiento en función de la cadena del 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 (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 los scripts de terceros.

RUM vs. CrUX

Comprender el origen de sus 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 que han dado su consentimiento (y algunos derivados de Chromium). Excluye ciegamente 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 que no son Chrome representan entre el 30 y el 50 % del tráfico. Depender únicamente de CrUX crea un punto ciego: está optimizando para el motor V8 de Google mientras descuida los motores SpiderMonkey (Firefox) y JavaScriptCore (Safari) que utiliza un segmento masivo de su audiencia.

Diagnósticos específicos de métricas

Los distintos motores de navegador gestionan los recursos, compilan JavaScript y calculan la geometría del diseño de forma diferente. Utilice esta dimensión para identificar los 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 manera diferente a Chrome. Un event listener pesado que pasa la prueba 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" (tap) en dispositivos móviles. La lógica de hidratación que parece 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 en el LCP suelen indicar una falta de paridad de funciones o de compatibilidad con las API de optimización modernas.

• Negociación de formato: Si Chrome informa un LCP rápido pero Firefox se queda atrás, verifique su estrategia de formato de imagen. Es posible que esté sirviendo AVIF a Chrome mientras utiliza JPEGs más grandes como fallback para versiones de navegadores 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 las conexiones HTTP/3 (QUIC) de manera diferente en entornos corporativos o de red restringidos, lo que afecta 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 de subpíxeles distinta.

• Renderizado de fuentes (Gecko vs. Blink): Firefox (Gecko) y Chrome (Blink) renderizan las líneas base de las fuentes y el tracking de manera ligeramente diferente. Si no ajusta perfectamente las métricas de su fuente fallback, el bloque de texto cambiará de tamaño cuando se cargue la fuente web, provocando un desplazamiento en un navegador pero no en el otro.
• Reserva de la 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 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".

• Identificar el valor atípico: Ordene su tabla de Navegadores por Impacto o Volumen. Busque un navegador específico (por ejemplo, Firefox Mobile) que tenga una puntuación significativamente peor que la línea base (Chrome Mobile).
• Verificar el entorno: Compruebe si el problema está estrictamente relacionado con el navegador o si es una combinación de navegador y sistema operativo (por ejemplo, Edge en Android frente a Edge en Windows).
• Depurar: 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 con mayor severidad que Blink.

Navegadores heredados e integrados

Utilice la dimensión Navegador para identificar los lastres de rendimiento de "larga cola".

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

Versiones heredadas: Es posible que encuentre tráfico de versiones de navegadores obsoletas. Si estas generan un alto INP, configure sus herramientas de compilación (Babel/PostCSS) para que sirvan los polyfills necesarios o, si el volumen es insignificante, tome la decisión estratégica de dejar de darles soporte para reducir el tamaño del paquete para los usuarios modernos.