navigator.cpuPerformance: niveles y privacidad

navigator.cpuPerformance es una clasificación aproximada del rendimiento de CPU, no un nombre de procesador, una lectura de utilización actual ni una comprobación de identidad. Chrome 152 incluye la API entre sus funciones publicadas. El borrador fijado de WICG define cuatro niveles positivos y un valor desconocido independiente, 0; que la propiedad esté ausente es otra observación. BotBrowser puede configurar su superficie documentada de número de núcleos, pero un ajuste --bot-cores por sí solo no puede confirmar cómo se informa esta propiedad distinta. Esa separación importa cuando un informe muestra niveles de CPU junto a núcleos, memoria y señales temporales.

Ver el vídeo

Este vídeo, con audio en inglés, recorre la misma pregunta que el artículo: el nivel que devuelve navigator.cpuPerformance es una clasificación estática y gruesa, no una lectura de carga en vivo. Separa la ausencia de la propiedad, el cero numérico que significa desconocido, un nivel positivo actual, un nivel futuro no reconocido y una lectura fallida; después muestra la correspondencia por número de núcleos del borrador, el ajuste de modelo definido por la implementación, la banda de diseño de privacidad, los reemplazos documentados de Chrome y una lectura grabada en Ubuntu Chrome desde un fixture controlado. No reconstruye el número exacto de núcleos, el modelo del procesador ni una puntuación de referencia. El audio está en inglés.

Resumen

• Mantén separados la ausencia de navigator.cpuPerformance, el valor numérico 0 y un nivel informado. La falta de información no clasifica el dispositivo como poco potente.
• El mapeo inicial del borrador usa núcleos informados por el sistema operativo, con ajustes por modelo de CPU definidos por la implementación. Un nivel no reconstruye el número exacto de núcleos ni el modelo.
• Un nivel estático no sigue la carga actual. Los ajustes de usuarios y administradores documentados por Chrome también impiden tratar cualquier valor como una medición de hardware sin modificar.
• La exposición especificada corresponde a un contexto Window seguro. La documentación de Chrome 152 no establece disponibilidad en todos los navegadores, entornos integrados o Workers.
• Los grupos amplios reducen el detalle, no la existencia de una señal de hardware. Un registro de soporte sobre niveles de CPU no necesita identificadores ajenos al problema.

Contenido

• Ver el vídeo

• Estados de retorno antes de concluir sobre el hardware

• La clasificación del borrador y sus límites

• Niveles estáticos, presión dinámica y tiempos

• Privacidad y registros mínimos de comparación

• Soporte de Chrome y límites de control de BotBrowser

• Conclusión práctica

Estados de retorno antes de concluir sobre el hardware

El borrador fijado de CPU Performance API amplía Navigator con una propiedad de solo lectura de tipo unsigned short. Su IDL declara SecureContext y Exposed=Window. Estos detalles describen dónde corresponde la interfaz; no constituyen una tabla de compatibilidad de todos los navegadores instalados. Un informe debe establecer el contexto de observación antes de atribuir significado al valor obtenido.

Observación	Significado respaldado por la fuente o el recolector	Significado no establecido
Contexto rechazado por isSecureContext	La función no continuó la recopilación en ese contexto	El dispositivo pertenece a un nivel bajo
Propiedad no expuesta	La propiedad está ausente del Navigator inspeccionado	La causa de ausencia, un producto de privacidad o un modelo de CPU
Valor numérico 0	La API comunica una clasificación desconocida	Cero núcleos, ausencia de CPU o fallo de lectura de JavaScript
Entero de 1 a 4	Un nivel positivo de rendimiento actual	Rendimiento exacto, identidad de hardware o utilización presente
Entero positivo superior a 4	Un nivel futuro no reconocido por este consumidor	Que el getter fijado lo devuelva actualmente
Error de lectura o tipo inesperado	La recopilación no produjo la forma de valor prevista	Una clasificación válida del hardware

La diferencia entre exposición y clasificación persiste aunque un panel prefiera una etiqueta compacta. Sustituir tanto undefined como 0 por «desconocido» elimina información sobre qué interfaz estaba disponible. Sustituirlos por el nivel 1 es más grave: inventa un juicio de rendimiento que el navegador no proporcionó. Estas transformaciones pueden falsear la comparación antes de cualquier inferencia sobre el hardware.

Una función ejecutada en Window puede conservar esa diferencia sin enviar solicitudes de red ni ejecutar una prueba de rendimiento. Las ramas siguientes son un ejemplo de política de recopilación, no la transcripción de una ejecución en un navegador. La condición de contexto seguro es un requisito previo deliberado: terminar ahí indica que se omitió la recopilación, no que se diagnosticó concluyentemente una API no disponible.

function readCpuTier() {
  if (!globalThis.isSecureContext) return { state: 'context-skipped' };
  if (!('cpuPerformance' in navigator)) return { state: 'not-exposed' };
  try {
    const tier = navigator.cpuPerformance;
    if (!Number.isInteger(tier) || tier < 0 || tier > 65535) {
      return { state: 'unexpected-value' };
    }
    if (tier === 0) return { state: 'unknown' };
    if (tier <= 4) return { state: 'tier', tier };
    return { state: 'future-tier', tier };
  } catch {
    return { state: 'read-error' };
  }
}

El borrador limita actualmente el getter al intervalo de 0 a 4, mientras que su apartado de niveles pide tolerar categorías adicionales en revisiones futuras. Conservar un entero positivo desconocido facilita la compatibilidad futura; no afirma que una implementación existente produzca el nivel 5. Una aplicación puede elegir una configuración conservadora para ese estado, pero su diagnóstico no debería convertirlo silenciosamente en un nivel conocido.

Las comprobaciones de propiedades tienen además un alcance menor que las de autenticidad. Encontrar cpuPerformance en el navegador de una página no establece que su entorno JavaScript sea fiable, y una lectura correcta no autentica un dispositivo. La presencia de una función sirve para gestionar capacidades. No debe transformarse en una condición de acceso a cuentas ni en una afirmación de que un informe demuestra quién maneja la máquina.

La clasificación del borrador y sus límites

El borrador parte del número de núcleos informado por el sistema operativo. Define un núcleo como una unidad física o lógica de ejecución según lo que comunique el sistema. Esa entrada no se especifica como el número devuelto a JavaScript por navigator.hardwareConcurrency. El análisis del número de núcleos informado distingue ese dato visible en la página del paralelismo subyacente. Consultar la tabla con el valor de la página no reproduce la clasificación del navegador basada en datos del sistema operativo.

Entrada inicial del sistema operativo en el borrador	Nivel inicial
Sin número de núcleos, o 0	0
1 núcleo	1
De 2 a 4 núcleos	2
De 5 a 10 núcleos	3
Más de 10 núcleos	4

El mismo apartado permite ajustes cuando un modelo conocido rinde considerablemente mejor o peor que otros dispositivos con un número similar de núcleos. Estos ajustes suelen desplazar la clasificación como máximo un nivel, requieren información fiable del modelo facilitada por el sistema y emplean un conjunto de modelos definido por la implementación. «Suelen» es una limitación de la fuente, no una promesa de que todas las implementaciones usen una lista de ajustes idéntica.

La relación inversa no tiene una solución única. El nivel 3 puede partir del grupo de 5 a 10 núcleos, pero los ajustes de modelo también pueden afectar a la clasificación. Incluso antes de esos ajustes, un grupo con varios valores no revela un número exacto de núcleos. Después, deducir un procesador único del entero final resulta aún menos justificable. El grupo devuelto contiene menos información que las entradas internas que ayudaron a seleccionarlo.

La implementación de referencia y la demostración enlazadas por WICG se declaran expresamente no normativas. Su clasificación ilustra un algoritmo, pero no prueba que un navegador instalado haya usado los mismos datos de modelos. Reconstruir un resultado de referencia con una entrada hipotética tampoco es una observación medida del navegador. Revisión de la fuente, decisiones de la implementación distribuida y valores realmente devueltos son categorías de evidencia diferentes.

El borrador pide que los ajustes reflejen rendimiento medido en condiciones ideales con pruebas relevantes. Es orientación para clasificar implementaciones; no convierte el entero de una página en una puntuación de rendimiento. Un nivel no tiene una unidad publicada de segundos, operaciones por segundo ni porcentaje de utilización. Dividir dos niveles no produce una relación de velocidad válida: el nivel 4 no debe describirse como el doble de rápido que el nivel 2.

Del mismo modo, el ejemplo de videoconferencia asocia niveles con configuraciones de resolución y efectos, pero declara esa interpretación específica de la aplicación. Otra carga puede depender de la GPU, la presión de memoria, la latencia de red o una ruta de instrucciones particular. Usar el nivel para elegir una configuración inicial moderada puede ser razonable; afirmar que garantiza vídeo fluido, inferencia de modelos o una frecuencia de cuadros fija excede lo que establece el valor.

Niveles estáticos, presión dinámica y tiempos

La reproducibilidad es una regla de diseño explícita: el mismo dispositivo debería informar del mismo nivel, sin cambiar según la carga o utilización actual. El borrador también distingue corregir errores de clasificación de redefinir niveles antiguos cada vez que aparecen equipos más rápidos. Esa distinción conserva el significado de la escala y permite corregir errores. Estático no significa que todo valor deba permanecer idéntico entre todas las versiones y configuraciones administrativas para siempre.

Superficie	Pregunta que aborda	Sustitución inválida
navigator.cpuPerformance	¿Qué clase estática aproximada se informa?	Un medidor de carga actual de CPU
navigator.hardwareConcurrency	¿Cuántos procesadores lógicos se comunican a la página?	La entrada exacta del sistema para el nivel o la identidad del modelo
navigator.deviceMemory	¿Qué categoría aproximada de memoria se comunica?	Una clasificación de CPU
Compute Pressure	¿Qué información dinámica de presión expone esa API?	Un nivel estable del hardware
performance.now()	¿Qué marcas temporales están disponibles para medir?	Una lectura directa de la clase de rendimiento de CPU

La diferencia con la presión dinámica afecta al diagnóstico. Una pestaña puede volverse lenta y conservar su nivel de CPU. Esa combinación no es una contradicción automática: una categoría estática y una carga cambiante describen cosas distintas. El análisis de cargas con Compute Pressure trata la información dinámica y los límites de esa API; responde a la adaptación a presión cambiante, no a la interpretación de una clasificación.

Los tiempos requieren otra separación. Medir cuánto tarda una tarea observa una ruta concreta de ejecución en determinadas condiciones. El resultado incluye efectos que el nivel no pretende informar continuamente. El análisis de privacidad de la medición temporal distingue la precisión de las marcas y las observaciones temporales de las etiquetas de hardware. Una duración corta no puede insertarse en la tabla de niveles como si ambas superficies compartieran escala.

Supón que una aplicación activa un efecto visual opcional costoso según el nivel y después responde mal. La primera pregunta es qué decisión usó el dato: una configuración inicial, una autorización persistente o una opción recalculada periódicamente. Si solo seleccionó el ajuste inicial, la mala respuesta no demuestra por sí sola una clasificación errónea. La carga puede necesitar un mecanismo independiente de adaptación, y la aplicación debería poder reducir el efecto sin reescribir su registro del hardware.

Leer repetidamente la propiedad tampoco sustituye observar la carga relevante. La independencia respecto a la utilización implica que un bucle de consultas no debería revelar la saturación actual. Guardar el mismo entero cada segundo añade almacenamiento y actividad sin aclarar si un cuadro, cálculo o solicitud incumple su plazo. La pregunta a medir debe derivarse del fallo de la aplicación, no de la comodidad de un campo disponible en navigator.

Privacidad y registros mínimos de comparación

El apartado de privacidad de WICG describe una divulgación deliberadamente pequeña mediante un entero. Busca que cada nivel incluya muchos dispositivos y modelos, con la intención expresa de cubrir al menos el 10% de los modelos existentes y el 10% de los dispositivos por nivel. Son intenciones de diseño de una especificación, no mediciones poblacionales entregadas con cada respuesta. La propiedad no incluye el denominador ni una auditoría que pruebe que un despliegue cumple actualmente esos objetivos.

Esto importa al interpretar huellas. Una categoría amplia sigue siendo observable y el diseño busca reproducibilidad en el mismo dispositivo. Un informe puede mostrarla junto con plataforma, memoria y otras observaciones del hardware. Combinar categorías cambia potencialmente la información del recolector, pero el pequeño espacio de salida no establece cuán distintiva resulta la combinación en una población real. Enumerar los valores posibles no permite deducir un porcentaje de singularidad.

La ausencia puede reflejar también un límite de observación, no una función deliberada de privacidad. Son relevantes la exposición a Window seguro, la implementación del producto y el contexto inspeccionado. Atribuir un campo ausente a una herramienta concreta sin pruebas añade otra inferencia no respaldada. El resultado de soporte más prudente es el estado concreto recopilado y el contexto necesario para reproducir ese problema específico.

Campo del registro de soporte	Finalidad	Límite de recopilación
Producto y versión pertinentes del navegador	Relacionar el resultado con disponibilidad documentada	No sustituir una versión suficiente por un volcado completo de cabeceras identificativas
Contexto Window y decisión de contexto seguro	Explicar dónde continuó o se detuvo la recopilación	Un contexto rechazado no prueba ausencia de hardware
Estado del recolector y nivel cuando existe	Conservar la forma real del resultado	No convertir 0 o ausencia en el nivel 1
Ajuste conocido del usuario o empresa	Explicar una diferencia verificada de configuración	Dejarlo desconocido si no se verificó
Fecha y revisión pertinente de la fuente	Separar un caso actual de documentación antigua	No adjuntar historial de navegación ni identificadores de cuenta ajenos

Una comparación útil no necesita exportar una huella completa. Si el problema es una exposición inesperada del nivel, el estado y la versión pueden bastar para identificar la siguiente cuestión de compatibilidad. Los resultados brutos de Canvas, el renderizador WebGL, las fuentes instaladas y los identificadores entre sitios no ayudan automáticamente. Añadirlos porque otro informe los muestra amplía la recopilación sin demostrar su necesidad.

La retención también debería seguir la tarea de soporte. Explicar la disponibilidad de una función no exige una clave de identidad permanente que una visitas futuras. Si cambia la versión o la aplicación adopta una nueva revisión de la especificación, una comparación fechada puede documentarlo directamente. Reutilizar un nivel antiguo como etiqueta inmutable del dispositivo oculta las diferencias de fuente y configuración que conviene conservar.

Separar configuración declarada y observación también evita comparaciones engañosas de productos. Un ajuste conocido demuestra configuración; leer la propiedad demuestra el estado visible en la página. Ninguno debería reemplazar silenciosamente al otro. Cuando el valor difiere de un ajuste o una heurística de referencia, conserva ambos hechos y sus fuentes en vez de inventar una conclusión sobre el hardware o la intención de una persona.

Soporte de Chrome y límites de control de BotBrowser

Las notas de Chrome 152 incluyen CPU Performance API e indican que usuarios y administradores pueden modificar el nivel informado mediante ajustes de Chrome y políticas empresariales. Es una afirmación específica de Chrome. El algoritmo del borrador WICG no documenta por sí mismo esos mismos ajustes en cualquier otro navegador o aplicación integrada.

Por tanto, un nivel informado no siempre representa una clasificación del sistema operativo sin modificar. Un ajuste conocido de Chrome es una entrada alternativa concreta al resultado visible. Si la investigación no conoce ese estado, la conclusión adecuada es que no se verificó el ajuste. No es correcto suponer su ausencia solo porque una página no pueda inspeccionar la política del administrador.

La evidencia de versión tiene un límite parecido. Que una función figure en Chrome 152 documenta esa versión, no prueba que el navegador integrado de una aplicación móvil tenga la misma configuración. Una cadena de versión de Chromium no determina por sí sola las decisiones del producto que lo incorpora. La detección en el contexto real de la página debe acompañar la comprobación documental, no ser reemplazada por una suposición de marca o versión.

Las comparaciones con Workers requieren especial cuidado: el IDL fijado expone la propiedad a Window y amplía Navigator, no WorkerNavigator. Leer el dato en la ventana principal y enviarlo a un Worker crea allí un valor suministrado por la aplicación; no demuestra una propiedad nativa del Worker. El registro debe conservar qué contexto hizo la lectura original, en lugar de afirmar igualdad entre contextos a partir de un mensaje reenviado.

La referencia de escalado de núcleos de BotBrowser documenta navigator.hardwareConcurrency, las opciones --bot-cores y los límites de afinidad de Workers. Linux y Windows tienen soporte documentado de afinidad; macOS sigue informando del número configurado sin ese mecanismo. Esas afirmaciones describen una superficie y una restricción de ejecución específicas. No documentan que un perfil o una opción de núcleos reescriba navigator.cpuPerformance.

La referencia de almacenamiento y memoria describe otras superficies de memoria. Una categoría de memoria no establece un nivel de CPU, y un ajuste de almacenamiento o del heap tampoco demuestra control sobre esta propiedad. La documentación del producto debe nombrar una superficie antes de atribuir su control a una opción. Una observación directa puede respaldar después el resultado limitado a su entorno registrado, no una garantía universal de protección.

Preguntas frecuentes

¿Un nivel desconocido debe desactivar todas las funciones opcionales?

La aplicación puede elegir una configuración conservadora para 0, pero el ejemplo de WICG muestra otra elección específica de una aplicación. El valor desconocido no codifica un único ajuste obligatorio. Separa la observación de la política de la aplicación y permite cambiar funciones costosas cuando la respuesta real es mala. La política puede evolucionar sin fingir que la propiedad proporcionó una clasificación más precisa.

¿Puede usarse el nivel como credencial de autorización?

La API devuelve una categoría pequeña de rendimiento, no una declaración firmada de autorización. Chrome documenta además ajustes de usuarios y administradores. Decidir si una operación está permitida requiere evidencia apropiada; una categoría del hardware no la aporta. Usarla como credencial de acceso atribuiría una confianza que ni el tipo de propiedad ni la documentación citada definen.

¿Qué ocurre si una especificación posterior añade otro nivel?

Conserva el entero positivo sin confundirlo con un valor conocido de 1 a 4 y elige deliberadamente una alternativa para la aplicación. El borrador prevé niveles superiores aunque su getter actual limite el intervalo existente. Un consumidor preparado para futuras versiones no debería convertir una categoría desconocida en error de recopilación solo porque sus etiquetas todavía no estén actualizadas.

¿Un nivel estable elimina la necesidad de fechar una comparación?

La observación sigue perteneciendo a una versión, una configuración y una revisión de la fuente. El borrador permite corregir clasificaciones y Chrome documenta ajustes. Una fecha y una versión explican por qué dos registros se obtuvieron con supuestos distintos. Deben conservarse como procedencia del problema de soporte, no para crear un registro de identidad duradero.

Fuentes

• Borrador fijado de WICG CPU Performance API
• Cuestionario fijado de seguridad y privacidad de WICG
• Notas de Chrome 152 sobre CPU Performance API
• Referencia de escalado de núcleos de CPU de BotBrowser
• Referencia de cuotas de almacenamiento y memoria de BotBrowser

Conclusión práctica

Registra la exposición antes de interpretar navigator.cpuPerformance. Usa un nivel positivo como entrada inicial aproximada, conserva 0 separado de la propiedad ausente y retén valores futuros sin inventar su significado. La compatibilidad depende del producto y del contexto Window reales. Un ajuste de núcleos, una heurística de referencia o un nivel poco detallado no prueban identidad de CPU, control del producto sobre esta superficie ni el resultado de una decisión de otro servicio.