Dimensión de Core/Dash: Device Type

Dimensión: Device Type (d)

La dimensión Device Type divide tus datos de Real User Monitoring en dos categorías: mobile y desktop. Este es el primer filtro más importante en cualquier investigación de rendimiento porque los entornos móvil y de escritorio son entornos de computación fundamentalmente diferentes. Diferentes CPU, diferentes condiciones de red, diferentes tamaños de viewport, diferentes motores de navegador.

Si analizas datos agregados de Core Web Vitals sin filtrar por tipo de dispositivo, estás promediando dos poblaciones que no tienen casi nada en común. Ese promedio es engañoso en el mejor de los casos.

La brecha de rendimiento móvil

Los dispositivos móviles representan aproximadamente el 62% del tráfico web global según Statista (2025). Sin embargo, el rendimiento móvil es sistemáticamente inferior al de escritorio. Según el 2025 Web Almanac, solo el 48% de los orígenes móviles superan los tres Core Web Vitals, en comparación con el 56% en escritorio. Esa es una brecha de 8 puntos porcentuales.

La brecha existe porque los dispositivos móviles se enfrentan a tres limitaciones que los de escritorio no tienen:

• Limitación de CPU: un teléfono Android de gama media tiene aproximadamente entre 3 y 5 veces menos potencia de procesamiento que uno de escritorio. El JavaScript que se ejecuta en 50 ms en escritorio puede tardar 200 ms en móvil, lo que empuja el INP más allá del umbral "bueno".
• Latencia de red: las conexiones móviles (4G/5G) tienen mayores tiempos de ida y vuelta y más variación que las conexiones por cable. Esto infla el TTFB y el retraso de carga del LCP.
• Tamaño del viewport: las pantallas más pequeñas cambian qué elemento se convierte en el LCP. Tu imagen principal en escritorio puede reducirse y quedar debajo de un bloque de texto en móvil, cambiando por completo el objetivo de optimización.

Distribución de Device Type en CoreDash

En los proyectos de CoreDash, la distribución típica del tráfico es de 65% móvil y 35% escritorio. Los sitios de comercio electrónico se inclinan más hacia el móvil (70-75%), mientras que los productos SaaS B2B a menudo muestran una división de 50/50 o incluso un predominio de escritorio.

La brecha de rendimiento en los datos de CoreDash refleja la tendencia global. El p75 del LCP móvil promedia 2,8 s en comparación con los 1,9 s en escritorio. Para el INP, la brecha es aún mayor: el p75 móvil se sitúa en torno a los 220 ms, mientras que el de escritorio ronda los 120 ms.

Análisis específico por métrica

Largest Contentful Paint (LCP)

El LCP móvil casi siempre es peor que el de escritorio. La causa principal es el retraso de carga: los navegadores móviles descubren la imagen del LCP más tarde porque el HTML tarda más en llegar (TTFB más alto) y el escáner de precarga compite con una mayor contención de recursos en una CPU más lenta. Si tu LCP en escritorio es inferior a 2,0 s pero en móvil supera los 3,0 s, el problema rara vez es el archivo de imagen en sí. Es el flujo de entrega.

Interaction to Next Paint (INP)

Aquí es donde la brecha de dispositivos golpea con más fuerza. Los manejadores de eventos de JavaScript que se sienten instantáneos en un i7 de escritorio pueden bloquear el main thread durante más de 300 ms en un Snapdragon 665. Filtra por móvil, ordena por impacto en el INP y encontrarás las interacciones exactas que fallan en teléfonos reales. Lo veo constantemente: los desarrolladores hacen pruebas en MacBook Pros y despliegan interacciones que son inutilizables en los dispositivos que realmente lleva el 65% de sus usuarios.

Cumulative Layout Shift (CLS)

Las diferencias de CLS entre tipos de dispositivos suelen tener su origen en el diseño responsivo. Los espacios publicitarios que reservan espacio en escritorio pueden colapsar o cambiar de tamaño en móvil. Las métricas del fallback de fuentes que se alinean en escritorio provocan cambios de diseño visibles en viewports más pequeños. Las fuentes web se renderizan de manera diferente en los navegadores de móviles y de escritorio, y la densidad física de píxeles afecta al redondeo de subpíxeles.

Flujo de trabajo de depuración

1. Comienza cada investigación con el filtro de dispositivo: antes de mirar cualquier otra dimensión, divide por Device Type. Si tu LCP agregado es de 2,5 s, podrías encontrar el de escritorio en 1,8 s y el móvil en 3,1 s. El "problema" es exclusivamente móvil.
2. Compara distribuciones, no solo el p75: revisa la distribución de bueno/necesita mejorar/pobre para cada tipo de dispositivo. Un escritorio con un 85% de bueno y un móvil con un 45% de bueno cuentan una historia completamente diferente a la del p75 por sí solo.
3. Combina con otras dimensiones: una vez que hayas aislado el tipo de dispositivo, añade un segundo filtro. Device Type + Country revela si la brecha móvil es global o se concentra en regiones con redes más lentas. Device Type + Navigation Type muestra si las navegaciones hacia atrás y adelante (back-forward) en móviles se guardan correctamente en caché.

Regla general de ingeniería

• LCP móvil inferior a 2,5 s: este es el umbral que utiliza Google para "bueno". Si tu escritorio pasa pero el móvil falla, enfócate en reducir el retraso de carga (fetchpriority, preload) y el TTFB (edge caching, CDN).
• INP móvil inferior a 200 ms: prueba cada función interactiva en un dispositivo Android de gama media real. La limitación de CPU de Chrome DevTools (4x) se aproxima a esto, pero probar en dispositivos reales es mejor.
• Nunca optimices solo para escritorio: si tu tráfico móvil supera el 50% (y es casi seguro que así es), el rendimiento móvil es tu señal de ranking de búsqueda. Google utiliza los datos de CrUX móvil para el ranking.

Device Type no es un filtro opcional. Es la primera pregunta que debes hacerte: "¿Es este un problema de móvil o de escritorio?". Cada decisión de optimización se deriva de esa respuesta.