Core/Dash Dimension: Capacidad del Dispositivo y del Cliente

Qué miden estas dimensiones

CoreDash expone dos dimensiones bajo la categoría Capacidad del Dispositivo y del Cliente. Responden a diferentes preguntas pero se complementan directamente.

Memoria del Dispositivo (código de grupo m) reporta el segmento de RAM que el navegador devuelve desde navigator.deviceMemory. La especificación redondea deliberadamente hacia abajo a la potencia de dos más cercana y limita el resultado, por lo que verá valores de 0.25, 0.5, 1, 2, 4 o 8+ GB en lugar de cifras exactas. Este redondeo es intencional: limita la precisión disponible para los scripts de fingerprinting mientras sigue brindando a los desarrolladores una señal útil.

El Client Capability Score (código de grupo ccs) es un compuesto calculado por CoreDash a partir de tres señales expuestas por el navegador: la memoria del dispositivo, navigator.hardwareConcurrency (núcleos lógicos de CPU) y el tipo de conexión efectiva de la Network Information API. El resultado es uno de los seis segmentos:

La puntuación compuesta es más útil que cualquier señal individual por sí sola. Un dispositivo con 4 GB de RAM en una conexión 2G se comporta de manera muy diferente al mismo dispositivo en Wi-Fi. Combinar la memoria, los núcleos y el tipo de conexión en una escala ordinal le permite filtrar y comparar datos de rendimiento sin tener que ejecutar un desglose por separado para cada variable.

Soporte de navegadores y cobertura de datos

navigator.deviceMemory es una API exclusiva de Chromium. Firefox y Safari no la exponen, lo que significa que esos navegadores siempre reportan Desconocido (CCS 0) para el componente de memoria. En la práctica, Chrome y los navegadores basados en Chrome representan la mayoría del tráfico de Android, y es en los dispositivos Android donde se concentran las condiciones de poca memoria. Así que la señal está disponible de manera más amplia precisamente donde más importa.

El encabezado HTTP Device Memory (Device-Memory) es un mecanismo separado que permite que un servidor lea el mismo valor desde una solicitud negociada a través de Accept-CH. CoreDash utiliza la API de JavaScript recopilada al momento de la carga de la página, por lo que el valor viaja con el beacon de RUM en lugar de requerir la configuración de encabezados del lado del servidor.

Por qué la capacidad del dispositivo importa para las Core Web Vitals

El LCP es principalmente un problema de red y renderizado. El INP es principalmente un problema de CPU y memoria. Esa distinción es la razón por la que la dimensión CCS se muestra más claramente en los datos de INP.

Las tareas largas en el hilo principal bloquean la respuesta a la entrada. En un dispositivo con 1 GB de RAM, el navegador ya se encuentra bajo presión de memoria incluso antes de que se ejecute su JavaScript: una recolección de basura más agresiva, descartes de pestañas más frecuentes y un menor margen de maniobra para la compilación JIT se traducen directamente en duraciones de tareas más largas. Un sitio que aprueba el INP en un teléfono moderno a 180 ms puede fácilmente situarse en 400 ms en un dispositivo Restringido.

El capítulo de Rendimiento del Web Almanac 2025 confirma la tendencia: las tasas de aprobación del INP móvil alcanzan el 77% en general, pero la brecha entre los dispositivos de alta potencia y los de gama baja en esa cifra es amplia. Aproximadamente el 29% de los usuarios de la web móvil se encuentran en dispositivos tres veces menos potentes que un modelo insignia actual. Esos usuarios no son valores atípicos en la mayoría de los mercados globales; son el visitante promedio.

Cómo usar el CCS y la Memoria del Dispositivo en CoreDash

El flujo de trabajo más productivo es comenzar con el CCS como filtro y luego usar la Memoria del Dispositivo para confirmar su hipótesis.

Primero, abra su desglose de INP por CCS. Si su INP en el percentil 75 es bueno para los visitantes Muy Capaces (CCS 1) y Capaces (CCS 2) pero falla para los Limitados (CCS 3) y posteriores, tiene un cuello de botella de CPU o memoria en lugar de un cuello de botella de red. Eso descarta toda una categoría de soluciones (precarga, connection hints, optimización de CDN) y centra su atención en el tiempo de ejecución de JavaScript: tareas largas, peso del manejador de entrada y scripts de terceros que se ejecutan en cada interacción.

Luego, filtre por Memoria del Dispositivo para ver qué segmentos de RAM generan los peores resultados. Si los dispositivos de 1 GB representan una parte desproporcionada de puntajes de INP deficientes, usted ya conoce el umbral. Los scripts que son aceptables a 4 GB pueden ser candidatos para ser aplazados o eliminados basándose únicamente en esos datos.

Para los sitios con audiencias globales, combine el CCS con la dimensión de País. Los mercados del sur y sudeste asiático, el África subsahariana y partes de América Latina tienen altas concentraciones de dispositivos Restringidos y Muy Limitados. Un desglose de CCS filtrado por país le mostrará dónde es mayor la brecha y le ayudará a priorizar qué mercado abordar primero.

El segmento Desconocido (CCS 0) cubre todo el tráfico de Firefox y Safari, además de cualquier sesión en la que las API no devolvieron ningún valor. No lo ignore. En sitios con una cuota significativa de Firefox o Safari, el segmento Desconocido puede representar una cuarta parte o más de todas las sesiones. Esto no significa que esos usuarios tengan dispositivos deficientes; significa que la señal no estaba disponible. Trate el segmento Desconocido como un segmento separado en lugar de integrarlo en su línea base.

Qué hacer con los datos

Si los visitantes de CCS 3, 4 o 5 representan más del 15% de su tráfico y su INP está consistentemente por encima de los 200 ms, el conjunto de soluciones es específico:

• Analice sus tareas más largas en un dispositivo ralentizado (throttled) usando Chrome DevTools. La Atribución de Tareas en el panel de Rendimiento mostrará qué scripts son responsables.
• Mueva los scripts de terceros no críticos detrás de un disparador de interacción o visibilidad para que no compitan por el hilo principal durante la ventana de carga inicial.
• Reduzca el tamaño del bundle de JavaScript en las rutas críticas. Cada kilobyte analizado en un dispositivo de poca memoria cuesta más que en un modelo insignia porque el compilador JIT tiene menos espacio para cachear el código compilado.
• Use scheduler.yield() o setTimeout(0) para dividir las tareas largas y darle al navegador la oportunidad de procesar eventos de entrada entre los fragmentos.

CoreDash muestra las dimensiones CCS y Memoria del Dispositivo junto a cada métrica de las Core Web Vitals para que pueda confirmar si una solución que mejoró el INP en dispositivos de gama alta también movió los números para sus visitantes Restringidos, y no solo para los usuarios en el mejor de los escenarios.