navigator.cpuPerformance en Chrome 152: nueva señal de detección para anti-detección y scraping

El 25 de agosto de 2026, Chrome 152 llegó al canal estable en Windows, Mac, Linux, ChromeOS y Android, y trajo la propiedad navigator.cpuPerformance. Un número del 0 al 4 que el sitio lee de manera sincrónica, sin permisos y sin un solo ciclo de cálculo. Está diseñado como una pista para videollamadas y transmisiones: a un dispositivo débil se le asigna 240p sin desenfoque de fondo, a uno potente, 1080p con efectos. Dos semanas después del lanzamiento, la industria del scraping discute otra cosa: los sistemas anti-bot tienen una señal barata y estable sobre el hardware en el que se ejecuta tu navegador.

Qué exactamente entrega el navegador

La propiedad no devuelve gigahercios ni el modelo del procesador, sino una "canasta" de rendimiento. Según la nota explicativa de WICG, hay cuatro niveles más cero:

• 0 — no se pudo clasificar el dispositivo;
• 1 — prácticamente inutilizable para tareas pesadas;
• 2 — débil, pero funcional;
• 3 — cómodo para escenarios normales;
• 4 — potente, con margen para multitarea.

La especificación prohíbe explícitamente revelar el vendedor, el nombre del modelo y la cantidad de núcleos, exige HTTPS y establece un objetivo de privacidad: cada canasta debe cubrir una parte significativa de los dispositivos en Internet — alrededor de cientos de modelos diferentes de CPU, para que el valor no reduzca la audiencia a unas pocas unidades.

La implementación real en Chromium resultó ser más simple que la especificación. En el análisis de Zyte se muestra que la clasificación se basa principalmente en el número de núcleos lógicos y en una tabla incorporada de aumentos y disminuciones: la frecuencia no se considera en absoluto, aunque la especificación lo permite. Obtienen un aumento los AMD Ryzen, los núcleos Intel Gracemont, Apple silicon e Intel Core Ultra; la disminución se aplica a Intel Atom y procesadores de la era Core 2. La clasificación básica se ve así: las máquinas de un solo núcleo y muy débiles caen en el primer nivel, dos a cuatro núcleos dan el segundo, cuatro a diez núcleos o chips modernos de eficiencia energética — el tercero, y ocho o más núcleos en Core Ultra, Apple M-series y todo lo que tenga diez núcleos o más — el cuarto.

Por qué esta es una señal de detección, y no solo otro byte de entropía

El valor en sí es débil: cinco opciones son alrededor de 2.3 bits de entropía, menos de lo que da el idioma de la interfaz. El peligro radica en otras tres propiedades.

Es gratuito. Para medir la velocidad real de ejecución de JS, el script de detección necesita ocupar el procesador durante decenas de milisegundos, y esto es notable en el perfilador. Aquí — la lectura sincrónica de la propiedad, cero costos, cero huellas.

Es estable. El valor no depende de la carga de la máquina en el momento de la verificación: es una clase de hardware, no la utilización actual. Entre sesiones, reinicios y cambios de IP, permanece igual — es decir, es adecuado como parte de un identificador de perfil de larga duración.

Se verifica por coherencia. Esto es lo principal. Los motores anti-bot modernos rara vez prohíben por un solo campo — buscan contradicciones internas en el conjunto. Un dispositivo que declara el cuarto nivel debe confirmarlo con un navigator.hardwareConcurrency creíble, un navigator.deviceMemory razonable, una línea moderna de GPU-renderer y una velocidad de ejecución de JS correspondiente. Un perfil que entrega el nivel 4 y al mismo tiempo ejecuta un benchmark como una máquina virtual de dos núcleos es atrapado por una verificación cruzada trivial.

Por separado, se obtiene casi un límite claro entre "centro de datos contra usuario real": una instancia típica en la nube con dos vCPU informa honestamente el primer nivel, mientras que las laptops y teléfonos de consumo viven en el tercer o cuarto. Para un scraper que se ejecuta en un VPS barato en modo headless y que se presenta como un Chrome normal en Windows, esta es una combinación incómoda.

Qué diferencia esto de hardwareConcurrency, que siempre ha estado

Una pregunta razonable: el número de núcleos el sitio ya lo leía a través de navigator.hardwareConcurrency, y la cantidad de memoria — a través de navigator.deviceMemory. ¿Qué ha cambiado?

Ha cambiado la conectividad. hardwareConcurrency es un número bruto, y se ha falsificado durante mucho tiempo y en todas partes: se pone ocho en lugar de treinta y dos, y el problema se cierra. cpuPerformance es una cantidad derivada, calculada por el propio navegador a partir de una tabla incorporada. Tan pronto como en el conjunto aparecen dos campos, uno de los cuales se calcula a partir del otro, cualquier modificación unilateral rompe la conexión entre ellos. Se establecieron cuatro núcleos, pero el nivel se mantuvo en cuatro — lógicamente, esta combinación requiere o Apple silicon, o Core Ultra, o diez núcleos; por lo tanto, o el número de núcleos miente, o la línea de GPU, y al detector le basta con notar la mera discrepancia, sin averiguar dónde está la mentira.

Precisamente por eso, las viejas listas de verificación de "qué campos falsificar en el perfil" se vuelven obsoletas no por un solo punto, sino por bloques enteros: la pregunta correcta ahora no es "qué falsificar", sino "qué configuración de hardware coherente obtenemos en total".

A quién afecta esto más

Solo Chromium — y esto no es un atenuante. WebKit ha tomado una posición "en contra" sobre esta API, Mozilla no ha declarado una posición pública, por lo que en Safari y Firefox, la propiedad probablemente no estará. Pero la gran mayoría de la automatización de producción — Playwright, Puppeteer, nodriver, Patchright, navegadores de agentes — se basa precisamente en Chromium. Es decir, la señal llega exactamente al nicho donde menos se espera.

La contradicción golpea más fuerte la emulación de perfiles móviles. Si un perfil anti-detección se presenta como un smartphone Android, y cpuPerformance bajo él responde "4", porque el navegador se ejecuta físicamente en un escritorio con Ryzen, — esto no es un pequeño error, sino una pareja de señales mutuamente excluyentes. Lo mismo ocurre con los escenarios de granja, donde decenas de perfiles con diferentes "dispositivos" viven en una sola máquina host y, por lo tanto, dan el mismo nivel.

Qué cambia esto para el stack de parsing

Algunas consecuencias prácticas para aquellos que ejecutan navegadores headless en lotes.

• Los contenedores heredan del host. El navegador en Docker ve los núcleos de la máquina host, no los límites de cgroup, — lo que significa que diez contenedores en un servidor robusto darán diez niveles máximos idénticos. La diversidad de perfiles que has estado dibujando cuidadosamente en el user-agent, a nivel de hardware, no existe.
• El VPS barato ahora es más notable. Dos vCPU — es el primer nivel, y el primer nivel en Chrome de escritorio bajo Windows no se encuentra a menudo en personas reales. Antes, un servidor débil era simplemente lento; ahora también está marcado.
• La señal es gratuita para el sitio. Comprobaciones pesadas como benchmarks de temporización los sitios las incluyen selectivamente, porque cuestan tiempo al usuario. La lectura de la propiedad no cuesta nada, por lo que se añadirá al conjunto básico incluso aquellos sitios que antes se limitaban a la reputación de IP y encabezados.
• Se combinará con Compute Pressure. En las notas de lanzamiento de Chrome se sugiere directamente combinar la nueva API con la API de Compute Pressure — es decir, la combinación "clase de hardware más carga observable" se pensó originalmente como un escenario estándar, y los anti-bots no tendrán que inventar nada.

Por separado, vale la pena revisar la suposición de que es suficiente recopilar una vez un perfil "bueno" y reutilizarlo durante años. Los navegadores añaden tales propiedades sin anuncios para los usuarios finales: entre el lanzamiento de Chrome 152 y los primeros análisis públicos pasaron semanas, durante las cuales los perfiles entregaban tranquilamente el nuevo campo, sin sospechar nada. Tiene sentido verificar el conjunto de campos una vez por ciclo de lanzamientos, y no una vez al año.

Qué hacer prácticamente

1. Obtén el valor actual. En la consola del perfil: navigator.cpuPerformance, navigator.hardwareConcurrency, navigator.deviceMemory y la línea del renderizador WebGL. Registra los cuatro, y no uno por uno — te verificarán precisamente en conjunto.
2. Compara el nivel con la leyenda del perfil. La leyenda móvil — primer a tercer nivel, laptop económica — segundo a tercer, desktop insignia — cuarto. Un nivel 4 bajo la apariencia de un viejo Android o un nivel 1 bajo la apariencia de un MacBook en la serie M son igualmente sospechosos.
3. No modifiques la propiedad directamente. La sustitución a través de Object.defineProperty se detecta por las huellas de la redefinición del getter y por la discrepancia con la velocidad real de ejecución. Si vas a cambiar, hazlo a nivel de construcción del navegador o a través de mecanismos integrados.
4. Recuerda el override legal. Chrome da al usuario una opción en la configuración (Rendimiento → Velocidad → Anular el nivel de rendimiento de la CPU), y a los administradores — una política corporativa. Es útil saber esto desde ambos lados: el valor puede ser no solo "real", sino también establecido manualmente, y un override masivo idéntico en un grupo de perfiles se convierte en una etiqueta por sí mismo.
5. Distribuye los perfiles en diferentes hardware. Si todos tus perfiles están en un solo servidor, tendrán el mismo nivel — independientemente de qué dispositivos estén representando. Este es el caso en el que un parque de varias máquinas de diferentes configuraciones resuelve el problema honestamente, mientras que un parche no.

Más detalles sobre la señal vecina de la misma familia — en el análisis de huella digital por volumen de memoria del dispositivo, y sobre los navegadores stealth que funcionan con tales propiedades de forma nativa, hay benchmark de nodriver, Camoufox y Patchright.

Dónde encajan los proxies

Digámoslo claramente: un proxy no repara la huella del navegador. cpuPerformance se calcula del lado del cliente, y ninguna IP lo cambiará. Pero el anti-bot toma decisiones en función de la suma de capas, y es precisamente en la intersección de capas donde suele ocurrir el fallo.

La cadena típica por la que caen las configuraciones baratas es la siguiente: IP de una red de hosting conocida, primer nivel de procesador, signos de headless en JS — tres señales independientes, cada una de las cuales es tolerable por separado, pero juntas se suman a un veredicto inequívoco. Eliminar la capa de red de esta suma es más barato y confiable que luchar con los campos del navegador: con una IP residencial, la solicitud parece tráfico de un proveedor de Internet doméstico normal, y la hipótesis de "centro de datos" se descarta por sí sola. Para las leyendas móviles, la lógica es la misma — un proxy móvil debe respaldar el perfil móvil, de lo contrario, la contradicción simplemente se traslada del procesador a la red.

En resumen

Chrome 152 no añadió tanto una nueva huella, sino una nueva línea en la tabla de verificaciones cruzadas. Dos bits y poco más en sí mismos no revelan a nadie — lo que revela es la incoherencia: el dispositivo declarado debe coincidir con la clase del procesador, la cantidad de memoria, la tarjeta gráfica, la velocidad de ejecución y la red desde la que llegó la solicitud. La auditoría de perfiles esta semana debe comenzar con una línea en la consola y la pregunta "¿existe realmente tal hardware para quien nos hacemos pasar?".