Dimensión de Core/Dash: Capacidad del dispositivo y del cliente

Qué miden estas dimensiones

CoreDash expone dos dimensiones bajo la categoría de capacidad del dispositivo y del cliente. Responden a preguntas diferentes pero se complementan directamente.

Device Memory (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 u 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.

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 la 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 de forma aislada. Un dispositivo con 4 GB de RAM en una conexión 2G se comporta de manera muy diferente al mismo dispositivo con Wi-Fi. Combinar la memoria, los núcleos y el tipo de conexión en una sola escala ordinal le permite filtrar y comparar datos de rendimiento sin 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 la memoria como Desconocida (CCS 0). En la práctica, Chrome y los navegadores basados en Chrome representan la mayoría del tráfico de Android, y los dispositivos Android son donde se concentran las condiciones de poca memoria. Por lo tanto, la señal está más disponible precisamente donde más importa.

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

Por qué la capacidad del dispositivo es importante 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 refleja más claramente en los datos de INP.

Las tareas largas en el hilo principal bloquean la respuesta de entrada. En un dispositivo con 1 GB de RAM, el navegador ya se encuentra bajo presión de memoria antes de que su JavaScript se ejecute: una recolección de basura más agresiva, descartes de pestañas más frecuentes y menos margen para la compilación JIT se traducen directamente en duraciones de tarea 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 utilizan dispositivos tres veces menos potentes que un buque insignia actual. Esos usuarios no son valores atípicos en la mayoría de los mercados globales; son el visitante promedio.

El CLS es menos sensible a la clase de hardware que el INP, pero los dispositivos con CPU lentas aún pueden producir cambios de diseño cuando las fuentes o las imágenes de carga tardía provocan reflujos que se completan después de que el navegador ya haya confirmado un frame.

Cómo usar CCS y Device Memory en CoreDash

El flujo de trabajo más productivo es comenzar con CCS como filtro y luego usar Device Memory para confirmar su hipótesis.

Primero, abra su desglose de INP por CCS. Si su INP del 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 (preloading, sugerencias de conexión, 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 Device Memory para ver qué segmentos de RAM generan los peores resultados. Si los dispositivos con 1 GB representan una proporción desproporcionada de puntuaciones deficientes de INP, ya conoce el umbral. Los scripts que son aceptables a 4 GB pueden ser candidatos para aplazarse o eliminarse basándose únicamente en esos datos.

Para sitios con audiencias globales, combine CCS con la dimensión País. Los mercados del sur y sudeste de Asia, 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. No significa que esos usuarios tengan dispositivos malos; significa que la señal no estaba disponible. Trate el segmento Desconocido como un segmento separado en lugar de incorporarlo a 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á constantemente por encima de los 200 ms, el conjunto de soluciones es específico:

• Analice sus tareas más largas en un dispositivo con throttling en las 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 con poca memoria cuesta más que en un buque insignia porque el compilador JIT tiene menos espacio para almacenar en caché el código compilado.
• Utilice scheduler.yield() o setTimeout(0) para dividir las tareas largas y darle al navegador la oportunidad de procesar los eventos de entrada entre los fragmentos.

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