Core/Dash Dimension: 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 móvil y escritorio son entornos informáticos fundamentalmente diferentes. Diferentes CPUs, diferentes condiciones de red, diferentes tamaños de viewport, diferentes motores de navegador.

Si estás mirando los Core Web Vitals agregados 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 móvil constantemente rinde por debajo del escritorio. Según el 2025 Web Almanac, solo el 48% de los orígenes móviles pasan las tres Core Web Vitals en comparación con el 56% en escritorio. Eso es una brecha de 8 puntos porcentuales.

La brecha existe porque los dispositivos móviles enfrentan tres restricciones que los escritorios no tienen:

• Limitación de CPU: Un teléfono Android de gama media tiene aproximadamente 3-5 veces menos potencia de procesamiento que un escritorio. JavaScript que se ejecuta en 50ms en escritorio puede tardar 200ms en móvil, empujando el INP más allá del umbral "bueno".
• Latencia de red: Las conexiones móviles (4G/5G) tienen tiempos de ida y vuelta más altos y más variabilidad que las conexiones por cable. Esto infla el TTFB y el LCP Load Delay.
• Tamaño del viewport: Las pantallas más pequeñas cambian qué elemento se convierte en el LCP. Tu imagen hero de escritorio puede reducirse por debajo de un bloque de texto en móvil, cambiando completamente el objetivo de optimización.

Distribución de Device Type en CoreDash

En los proyectos de CoreDash, la distribución típica de tráfico es 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 ven una distribución 50/50 o incluso dominio del escritorio.

La brecha de rendimiento en los datos de CoreDash refleja la tendencia global. El LCP p75 en móvil promedia 2.8s comparado con 1.9s en escritorio. Para INP, la brecha es aún mayor: el p75 en móvil se sitúa alrededor de 220ms mientras que el escritorio ronda los 120ms.

Análisis específico por métrica

Largest Contentful Paint (LCP)

El LCP en móvil es casi siempre peor que en escritorio. La causa principal es el Load Delay: los navegadores móviles descubren la imagen LCP más tarde porque el HTML tarda más en llegar (TTFB más alto) y el escáner de precarga compite con más contención de recursos en una CPU más lenta. Si tu LCP de escritorio está por debajo de 2.0s pero el móvil supera los 3.0s, el problema rara vez es el archivo de imagen en sí. Es el pipeline de entrega.

Interaction to Next Paint (INP)

Aquí es donde la brecha de dispositivos golpea más fuerte. Los manejadores de eventos JavaScript que se sienten instantáneos en un escritorio i7 pueden bloquear el hilo principal durante más de 300ms en un Snapdragon 665. Filtra por móvil, ordena por impacto de INP, y encontrarás las interacciones exactas que fallan en teléfonos reales. Veo esto constantemente: los desarrolladores prueban en MacBook Pros y publican interacciones que son inutilizables en los dispositivos que el 65% de sus usuarios realmente llevan.

Cumulative Layout Shift (CLS)

Las diferencias de CLS entre tipos de dispositivo generalmente se remontan al diseño responsivo. Los espacios publicitarios que reservan espacio en escritorio pueden colapsar o redimensionarse en móvil. Las métricas de fuentes de respaldo que se alinean en escritorio causan cambios visibles en viewports más pequeños. Las fuentes web se renderizan de manera diferente entre navegadores móviles y de escritorio, y la densidad física de píxeles afecta el 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 2.5s, podrías encontrar escritorio en 1.8s y móvil en 3.1s. El "problema" es exclusivamente móvil.
2. Compara distribuciones, no solo el p75: Revisa la distribución bueno/necesita mejora/pobre para cada tipo de dispositivo. Un escritorio con 85% bueno y un móvil con 45% bueno cuenta una historia completamente diferente que solo el p75.
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 está concentrada en regiones con redes más lentas. Device Type + Navigation Type muestra si las navegaciones back-forward en móvil están correctamente en caché.

Regla práctica de ingeniería

• LCP móvil por debajo de 2.5s: Este es el umbral que Google utiliza para "bueno". Si tu escritorio pasa pero el móvil falla, concéntrate en reducir el Load Delay (fetchpriority, preload) y el TTFB (caché en el edge, CDN).
• INP móvil por debajo de 200ms: Prueba cada funcionalidad interactiva en un dispositivo Android real de gama media. La limitación de CPU de Chrome DevTools (4x) lo aproxima, pero las pruebas en dispositivos reales son mejores.
• Nunca optimices solo para escritorio: Si tu tráfico móvil supera el 50% (y casi con certeza lo hace), el rendimiento móvil es tu señal de ranking en búsquedas. Google utiliza datos CrUX de móvil para el ranking.

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