navigator.cpuPerformance: el navegador ya sabe cuánta CPU tiene tu dispositivo (y eso cambia cómo servimos video)

Chrome 152 introduce la CPU Performance API, y es la primera señal confiable que tiene un sitio web para saber si el dispositivo del usuario es un flagship o un gama de entrada: navigator.cpuPerformance devuelve un nivel del 1 al 4 (0 si es desconocido). En Mintec ya la estamos usando para decidir qué calidad de video, qué efectos y qué cargas de WebGPU le servimos a cada visitante — y este artículo es el framework de cuatro niveles que aplicamos en nuestros sitios multimedia.

Llevamos años adaptando contenido por red: srcset, formatos AVIF, bitrate adaptativo. Pero la red nunca fue el único cuello de botella. Un teléfono de gama de entrada con fibra óptica descarga un video 4K en segundos… y luego se atraganta decodificándolo. El navegador sabía cuántos núcleos tenías (navigator.hardwareConcurrency), pero ese dato es tan fino que se convirtió en una herramienta de fingerprinting — inutilizable para decidir en producción.

La CPU Performance API resuelve exactamente ese dilema: expone un nivel de rendimiento grueso (1 a 4, 0 = desconocido) diseñado explícitamente para no aumentar la entropía de identificación. La anunció el equipo de Chrome en la beta de Chrome 152, con estable programado para el 25 de agosto de 2026. Y no es una API decorativa: el propio explainer de la propuesta WICG la ilustra con un preset de video — calidad, framerate y efectos por nivel.

Ese es el punto de intersección que nos interesa en Mintec: la web finalmente tiene una palanca legítima para decirle a un sitio multimedia "este usuario no puede con tu WebGPU shader, dale algo más liviano". Eso no existía antes de agosto de 2026.

Por qué la adaptación por red ya no basta

En nuestros proyectos video-first (landing pages con hero en autoplay, portafolios de video IA, catálogos con demos de producto) siempre llegamos al mismo punto: el presupuesto de rendimiento se rompe no por el peso de descarga, sino por el costo de procesamiento en el cliente. Un frame 1080p decodificado ocupa ~6MB en memoria; un reproductor con efectos (blur, overlays animados, WebGPU) multiplica el trabajo por frame. El problema: hasta ahora no teníamos forma confiable de saber si el cliente podía pagar esa cuenta. Las opciones eran malas:

• navigator.hardwareConcurrency: correlaciona con el hardware, pero combinado con deviceMemory añade 4-5 bits de entropía — suficiente para preocupar a los equipos de privacidad y a los ad-blockers. No lo usamos en producción.
• User-Agent / Client Hints: la era de los UA strings confiables terminó; el Sec-CH-UA-Mobile es útil pero no dice nada de la potencia de cómputo.
• Micro-benchmarks: medir performance.now() con tareas sintéticas en el cliente. Funciona, pero cuesta 50-100ms de JS en el peor momento posible — justo el que arruina el INP.

La CPU Performance API ataca el problema de frente: Chrome clasifica el dispositivo internamente (por hardware conocido, no por benchmarks en tu página) y expone un nivel del 1 al 4. Nada más. Sin modelo de CPU, sin núcleos, sin reloj. Y con dos válvulas de escape: el usuario puede sobreescribir el valor en Ajustes → Rendimiento, y las organizaciones pueden forzarlo con la política empresarial CpuPerformanceTierOverride.

El framework de cuatro niveles que usamos en Mintec

Cuando la API aterrizó en la beta, nuestro equipo de media armó una tabla de decisión por nivel. La compartimos tal cual la usamos:

La regla 0 es la más importante: desconocido se trata como nivel 2, no como nivel 4. El entusiasmo por una API nueva no debe traducirse en asumir lo mejor — se asume lo seguro. Si la API no está disponible (Firefox, Safari, o Chrome anterior a 152), el comportamiento por defecto del sitio no cambia: es la misma experiencia que tenías antes, con la mejora progresiva encendida solo donde existe.

Cómo lo implementamos (con Astro y sin romper el INP)

En nuestro stack — Astro + Cloudflare, con contenido multimedia pesado — el patrón se ve así:

1. Leer el nivel antes de hidratar. Un script inline en el <head> lee navigator.cpuPerformance, escribe data-cpu-tier en <html> y guarda el valor en sessionStorage. Sin bloquear el render: la lectura es síncrona y trivial, y el CSS ya tiene los defaults por nivel.

2. Decidir en CSS y en la capa de datos. Las reglas html[data-cpu-tier="1"] video { ... } controlan lo declarativo (poster, autoplay desactivado, preload diferido). Para lo imperativo — qué componentes de efectos se registran — usamos el valor en la inicialización del reproductor. El resultado: el tier 1 ni siquiera carga el código del efecto, no solo lo desactiva.

3. Combinar con la Compute Pressure API. El nivel responde "¿qué tan potente es?"; la presión responde "¿está saturado ahora?". Un flagship con 40 pestañas puede reportar presión alta aunque sea nivel 4. Nuestro reproductor degrada el bitrate o suspende efectos cuando la presión sube, y se recupera cuando baja.

Este enfoque no sustituye al trabajo que ya documentamos en presupuesto de rendimiento para sitios multimedia ni a la depuración de INP con LoAF: los complementa. El presupuesto define el techo, la CPU Performance API define el piso por dispositivo.

Qué cambia para la producción de video y WebGPU

Esto importa doblemente para los equipos que ya producen video generado por IA o que empujan procesamiento de video al navegador con WebGPU. El argumento histórico era: "el cliente final tiene GPU, corramos el post-procesado en su máquina y ahorramos servidor". La CPU Performance API te deja hacer eso con responsabilidad: el pipeline de WebGPU solo se activa en niveles 3-4, y en niveles 1-2 se sirve el video ya procesado desde CDN.

En un portafolio multimedia reciente para un estudio de motion graphics, este gate redujo el JS cargado en gama de entrada de 412KB a 96KB, y el INP en esos dispositivos pasó de ~340ms a ~180ms. Sin tocar un solo frame: solo dejamos de pedirle al teléfono barato que hiciera trabajo de desktop.

Por qué esta API es diferente (y por qué confiamos en ella)

Hay que decirlo claro: cualquier API nueva de hardware despierta sospechas, y con razón — hardwareConcurrency se usa en casi todos los fingerprinting scripts del mercado. Pero la CPU Performance API fue diseñada para no repetir ese error: solo expone 4 niveles + desconocido, el usuario puede sobreescribir el valor en Ajustes, y las empresas pueden fijarlo por política (CpuPerformanceTierOverride).

Nuestra lectura en Mintec: esta es de las pocas APIs recientes que mejora la experiencia y la privacidad al mismo tiempo. La alternativa anterior — benchmarks de CPU en el cliente — era más invasiva, costaba INP y además era imprecisa.

Lo que haríamos si estás empezando hoy

Si tu sitio tiene video, efectos o WebGPU y quieres adoptar esto sin sobre-ingeniería:

1. Empieza por el tier 1. Activa el gate solo para el nivel más bajo: poster en lugar de autoplay, preload diferido, efectos desactivados. Es el cambio con mayor impacto y menor riesgo. Ya cubrimos la base en nuestra guía de video adaptativo con Astro — ahora el criterio de adaptación puede incluir CPU, no solo red.
2. Trata 0 como 2. Desconocido = conservador. Siempre.
3. No uses el nivel para ocultar contenido. Es una palanca de rendimiento, no de decisión de negocio. Si un usuario de tier 1 no ve un demo de producto porque "su teléfono no puede", perdiste un lead — dale una versión ligera, no se la niegues.
4. Mide después del rollout. El impacto real se ve en los percentiles p75-p95 de INP y en el time-to-interactive de gama de entrada. Si tu analytics segmenta por data-cpu-tier, podrás demostrar el efecto con datos propios.

La CPU Performance API no es la respuesta a todos los problemas de rendimiento. Pero es la primera vez que el navegador nos dice, de forma legítima y respetuosa con la privacidad, qué tan duro podemos exigirle al hardware del usuario. Para sitios multimedia, eso cambia las reglas del juego — y en Mintec ya la usamos en producción.