Compute Pressure API: cargas adaptativas y privacidad

Compute Pressure API expone una vista aproximada de la presión que afecta a una carga del navegador. Puede ayudar a elegir un camino de renderizado más ligero, aplazar trabajo opcional o restaurar calidad después de una transición. No es un medidor de CPU, una huella del dispositivo ni un diagnóstico del equipo. Los contextos controlados de BotBrowser pueden ejecutar un fixture autorizado que detecta PressureObserver y registra resultados visibles cuando el runtime expone la API; BotBrowser no puede fabricar una fuente de presión, forzar el soporte ni garantizar transiciones idénticas en todos los hosts. Para señales cercanas, consulta Device Memory y rendimiento web, concurrencia de hardware y workers y PerformanceObserver para la salud de una aplicación.

TL;DR

• Trata PressureObserver como una señal opcional y aproximada para una decisión reversible.
• Mantén propiedad, limpieza del callback y estado de adaptación dentro del componente que posee el trabajo.
• No conviertas nominal, fair, serious o critical en etiqueta de dispositivo, persona o cuenta.
• Conserva un camino base útil cuando la API falte, sea rechazada o no esté disponible en un worker.
• Registra un resultado acotado como reduced, restored o unavailable, no un historial prolongado.

Contents

• Leer la presión como señal aproximada
• Elegir una política reversible
• Controlar observación y privacidad
• Verificar transiciones con un fixture acotado
• Conclusión práctica

Leer la presión como señal aproximada

La especificación Compute Pressure define un modelo de observación del navegador, no una promesa sobre un procesador físico. La aplicación crea PressureObserver, entrega un callback y observa una fuente como cpu. El callback recibe valores PressureRecord con estado y marca temporal. El vocabulario es deliberadamente aproximado: nominal, fair, serious y critical describen bandas, no un porcentaje comparable entre sistemas.

La referencia MDN Compute Pressure API documenta la superficie y su disponibilidad. Detecta el constructor y los métodos que uses. La ausencia de PressureObserver significa que ese runtime no ofrece la señal opcional por esa ruta; no demuestra que el host esté libre, saturado, rápido o inseguro. Una política de permisos, una versión del navegador, el tipo de worker o una decisión de privacidad de la plataforma pueden explicar la ausencia.

La guía de Chrome Compute Pressure presenta la adaptación como una forma de conservar la capacidad de respuesta. Úsala como modelo de decisión visible, no como promesa de compatibilidad para cada webview. La fuente y la versión del navegador determinan qué estados se exponen. La experiencia base debe funcionar antes de pedir una observación más rica.

No confundas presión con navigator.hardwareConcurrency, navigator.deviceMemory ni una entrada de rendimiento. El navegador puede agrupar o retrasar cambios, y dos páginas pueden ver estados distintos en el mismo host. El estado tampoco identifica qué pestaña, proceso, extensión o condición térmica contribuyó. Mantén esas preguntas fuera del registro de aplicación.

const pressureState = {
  source: 'cpu',
  state: 'unavailable',
  policy: 'baseline',
  sequence: 0,
};

Elegir una política reversible

La adaptación debe cambiar trabajo opcional y conservar la tarea principal. Un estado serio puede pausar una vista previa, reducir partículas o aplazar un índice. No debe borrar una edición, quitar un control accesible ni rebajar una comprobación necesaria. La política toma la decisión; el observador solo aporta una pista.

Resultado observado	Acción de carga	Contrato visible	Recuperación
unavailable	Mantener presupuesto base y omitir observación opcional	La tarea principal sigue utilizable	Reevaluar tras un cambio de runtime declarado
nominal	Permitir presupuesto opcional normal	Calidad y controles disponibles	Mantener los límites del camino base
fair	Aplazar trabajo no esencial y limitar concurrencia	Indicar si una vista previa se retrasa	Restaurar tras un estado posterior observado
serious	Pausar trabajo de fondo y usar camino ligero	Conservar entrada, foco y cancelación	Reanudar solo desde un registro nuevo
critical	Detener trabajo opcional y conservar resultado confirmado	Explicar la pausa opcional	Requerir estado nuevo y presupuesto seguro

Estos valores son resultados de política, no utilización de CPU. Un límite copiado de otro runtime puede causar oscilación. Exige un registro nuevo antes de restaurar trabajo opcional y permite que una acción explícita del usuario reintente una vista previa.

Separa presupuestos de primer plano, fondo y datos retenidos. Limita tareas pendientes, cancela trabajo obsoleto y marca si cada worker confirmó, fue sustituido o se canceló. La política debe ser reversible: conserva el último resultado visible mientras el trabajo opcional se recupera y no lo reemplaces por un espacio vacío.

La accesibilidad también forma parte de la transición. Anuncia un cambio significativo sin repetir cada callback, conserva el foco, ofrece alternativa textual y muestra una acción de reintento. Un modo ligero puede cambiar cálculo, no la capacidad de entender y controlar la tarea.

Controlar observación y privacidad

El componente que crea PressureObserver posee el observador, callback, política y limpieza. Desconecta cuando cambia la ruta, termina el worker o se desactiva la función. El callback debe copiar solo estado y secuencia local; no hagas solicitudes de red ni serializaciones grandes allí.

El navegador puede entregar registros con una cadencia que protege la privacidad. No infieras una línea temporal de alta resolución. La marca temporal solo ordena registros del componente; no prueba una acción de usuario, cantidad de núcleos o evento térmico. Redondea u omite tiempos en telemetría y reténlos solo el plazo necesario.

No unas estados de presión con cuenta, URL, locale o dispositivo. Incluso campos inocuos pueden crear una señal persistente. Prefiere un agregado como policy=paused durante una sesión limitada. Si necesitas salud de flota, agrega después de retirar identificadores y documenta muestreo y retención.

Un worker puede observar su fuente, pero la página decide si el resultado sigue perteneciendo a la ruta actual. Envía workload-reduced y una secuencia local, no el historial completo. Valida origen y esquema al cruzar documentos. La ausencia de la API debe producir unavailable, no una etiqueta de baja capacidad en el perfil.

BotBrowser puede ejecutar una página autorizada y comparar resultados visibles en un contexto controlado cuando el runtime expone PressureObserver. No puede crear presión, controlar otra pestaña, identificar una causa del host ni certificar la misma cadencia en producción.

Verificar transiciones con un fixture acotado

Usa una página sintética con una carga opcional y un resultado confirmado. El fixture detecta capacidad, instala un observador, aplica una transición acotada y desconecta. No recoge datos de cuenta ni guarda historial. Una ejecución sin API produce una fila unavailable.

const record = { source: 'cpu', state: 'unavailable', policy: 'baseline', sequence: 0 };
let observer;

if ('PressureObserver' in globalThis) {
  observer = new PressureObserver(records => {
    const latest = records.at(-1);
    record.sequence += 1;
    record.state = latest?.state ?? 'unavailable';
    record.policy = record.state === 'serious' || record.state === 'critical' ? 'reduced' : 'normal';
  });
  await observer.observe('cpu');
}

try {
  await runBoundedFixture({ limit: 8, signal });
} finally {
  observer?.disconnect();
}

El fixture registra lo que el runtime hace visible; no fuerza un estado. Un unavailable sintético sigue verificando que el camino base y la limpieza funcionan.

Caso del fixture	Registro esperado	Demuestra	No demuestra
Falta el constructor	unavailable, baseline	Detección y alternativa segura	Que el host esté libre
Se conecta el observador	Estado visible y política normal o reduced	Propiedad de un registro acotado	Porcentaje físico de CPU
Llega estado serio o crítico	reduced con sequence nueva	Pausa sin perder resultado	Que todas las pestañas compartan estado
Se desmonta ruta o worker	No hay commit posterior a disconnect()	Limpieza contra callbacks viejos	Que nunca exista una cola previa
Usuario restaura trabajo	Tarea nueva con entradas actuales	Recuperación reversible	Que la presión global desapareció

Registra solo browserVersion, runtimePath, source, state, policy, sequence, fixtureId y outcome con valores sintéticos. Clasifica unsupported-source por separado de unavailable. Repite después de cambios de navegador, worker, carga o política y compara el primer campo distinto.

Public sources

• Compute Pressure specification
• MDN: Compute Pressure API
• Chrome for Developers: Compute Pressure API
• BotBrowser: Advanced features

Conclusión práctica

Detecta PressureObserver, conserva la experiencia base y deja que una política acotada pause o restaure trabajo opcional. Asigna un único propietario al observador y su limpieza, mantén registros aproximados y breves, y conserva resultados confirmados. Repite el fixture tras cambios del navegador, worker, carga o política y decide desde el primer estado observable que cambió.