Compute Pressure API : charges adaptatives et vie privée

Compute Pressure API expose une vue grossière de la pression qui affecte une charge du navigateur. Elle peut aider à choisir un rendu plus léger, différer un travail facultatif ou rétablir la qualité après une transition. Ce n’est ni un compteur de CPU, ni une empreinte de machine, ni un diagnostic de l’hôte. Les contextes contrôlés de BotBrowser peuvent exécuter un fixture autorisé qui détecte PressureObserver et enregistre les résultats visibles lorsque le runtime expose l’API ; BotBrowser ne peut pas fabriquer une source de pression, forcer la prise en charge ou garantir des transitions identiques sur tous les hôtes. Pour les signaux voisins, consultez Device Memory et performances web, concurrence matérielle et workers et PerformanceObserver pour la santé applicative.

TL;DR

• Considérez PressureObserver comme un signal facultatif et grossier pour une décision réversible.
• Le composant propriétaire garde l’observateur, le nettoyage du callback et l’état d’adaptation.
• Ne transformez pas nominal, fair, serious ou critical en étiquette de machine, de personne ou de compte.
• Gardez une voie de base utile si l’API manque, est refusée ou n’est pas disponible dans un worker.
• Enregistrez un résultat borné comme reduced, restored ou unavailable, jamais un historique durable.

Contents

• Lire la pression comme un signal grossier
• Choisir une politique réversible
• Garder la propriété et la vie privée
• Vérifier les transitions avec un fixture borné
• Conclusion pratique

Lire la pression comme un signal grossier

La spécification Compute Pressure définit un modèle d’observation du navigateur, pas une promesse sur un processeur physique. L’application crée PressureObserver, fournit un callback et observe une source comme cpu. Le callback reçoit des valeurs PressureRecord avec un état et un temps. Le vocabulaire est volontairement grossier : nominal, fair, serious et critical sont des bandes, pas un pourcentage comparable entre systèmes.

La référence MDN Compute Pressure API décrit l’interface et sa disponibilité. Détectez le constructeur et les méthodes utilisées. L’absence de PressureObserver signifie que ce runtime n’offre pas ce signal facultatif par cette voie ; elle ne prouve pas que l’hôte est libre, saturé, rapide ou défaillant. Une politique de permissions, une version du navigateur, un type de worker ou un choix de confidentialité de la plateforme peuvent expliquer cette absence.

La présentation Chrome Compute Pressure montre l’adaptation comme un moyen de préserver la réactivité. Prenez-la comme modèle de décision visible, pas comme promesse de compatibilité pour chaque webview. La source et la version du navigateur déterminent les états exposés. La voie de base doit fonctionner avant toute observation enrichie.

Ne confondez pas la pression avec navigator.hardwareConcurrency, navigator.deviceMemory ou une entrée de performance. Le navigateur peut regrouper ou retarder les changements, et deux pages peuvent voir des états différents sur le même hôte. L’état n’identifie pas non plus l’onglet, le processus ou la condition thermique responsable. Gardez ces questions hors du registre applicatif.

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

Choisir une politique réversible

L’adaptation doit modifier le travail facultatif en conservant la tâche principale. Un état sérieux peut suspendre un aperçu, réduire les particules ou différer un index. Il ne doit pas supprimer une édition, retirer un contrôle accessible ou abaisser une vérification nécessaire. La politique décide ; l’observateur ne fournit qu’un indice.

Résultat observé	Action de charge	Contrat visible	Récupération
unavailable	Garder le budget de base et ignorer l’observation facultative	La tâche principale reste utilisable	Réévaluer après un changement de runtime déclaré
nominal	Autoriser le budget facultatif normal	Qualité et contrôles conservés	Garder les limites de base
fair	Différer le travail non essentiel et borner la concurrence	Indiquer qu’un aperçu est retardé	Restaurer depuis un état observé plus récent
serious	Suspendre le travail de fond et choisir une voie légère	Conserver entrée, focus et annulation	Reprendre depuis un nouveau record
critical	Arrêter le travail facultatif et conserver le résultat validé	Expliquer la pause facultative	Exiger un état frais et un budget sûr

Ces valeurs sont des résultats de politique, pas une utilisation du CPU. Une limite copiée d’un autre runtime peut provoquer des oscillations. Exigez un nouveau record avant de restaurer le travail et laissez une action explicite de l’utilisateur relancer un aperçu.

Séparez les budgets du premier plan, du fond et des données retenues. Limitez les tâches en attente, annulez le travail obsolète et indiquez si chaque worker a validé, a été remplacé ou a été annulé. Conservez le dernier résultat visible pendant la récupération ; une zone vide ferait croire à une perte de données.

L’accessibilité appartient aussi au contrat de transition. Annoncez un changement significatif sans répéter chaque callback, gardez le focus, proposez une alternative textuelle et affichez une action de reprise. Un mode léger peut changer le calcul, pas la capacité à comprendre et contrôler la tâche.

Garder la propriété et la vie privée

Le composant qui crée PressureObserver possède l’observateur, le callback, la politique et le nettoyage. Déconnectez-le lors d’une navigation, de la fermeture d’un worker ou de la désactivation de la fonction. Le callback ne doit copier que l’état et une séquence locale ; aucune requête réseau ni grande sérialisation ne doit y entrer.

Le navigateur peut livrer les records à une cadence protectrice de la vie privée. N’en déduisez pas une chronologie haute résolution. Un temps ordonne les records du composant ; il ne prouve ni action utilisateur, ni nombre de cœurs, ni événement thermique. Arrondissez ou omettez ces temps dans la télémétrie et gardez-les le moins longtemps possible.

N’associez pas les états à un compte, une URL, une locale ou une machine. Même des champs anodins peuvent former un signal persistant. Préférez un agrégat comme policy=paused pour une session bornée et retirez les identifiants avant une agrégation de flotte.

Un worker peut observer sa source, mais la page décide si le résultat correspond encore à sa route. Envoyez workload-reduced et une séquence locale plutôt que l’historique. Validez l’origine et le schéma aux frontières de documents. L’absence de l’API produit unavailable, pas une étiquette de faible capacité.

BotBrowser peut exécuter une page autorisée et comparer les résultats visibles dans un contexte contrôlé lorsque le runtime expose PressureObserver. Il ne peut pas créer la pression, contrôler un autre onglet, identifier la cause de l’hôte ni certifier la même cadence en production.

Vérifier les transitions avec un fixture borné

Utilisez une page synthétique avec un travail facultatif et un résultat validé. Le fixture détecte la capacité, installe un observateur, applique une transition bornée et se déconnecte. Il ne collecte aucune donnée de compte et ne conserve pas d’historique. Une exécution sans API produit une ligne 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();
}

Le fixture enregistre ce que le runtime rend visible ; il ne force pas un état. Un essai synthétique unavailable vérifie tout de même la voie de base et le nettoyage.

Cas du fixture	Record attendu	Ce que cela prouve	Ce que cela ne prouve pas
Constructeur absent	unavailable, baseline	Détection et voie de repli sûre	Que l’hôte est libre
Observateur attaché	État visible et politique normal ou reduced	Propriété d’un record borné	Pourcentage physique du CPU
Nouvel état sérieux ou critique	reduced avec une nouvelle sequence	Pause sans perte du résultat	Que tous les onglets partagent l’état
Route ou worker fermé	Aucun commit après disconnect()	Nettoyage des callbacks périmés	Qu’aucun callback antérieur n’est en file
L’utilisateur restaure le travail	Nouvelle tâche avec entrées actuelles	Récupération réversible	Disparition de la pression globale

Enregistrez seulement browserVersion, runtimePath, source, state, policy, sequence, fixtureId et outcome avec des valeurs synthétiques. Séparez unsupported-source de unavailable. Rejouez après un changement de navigateur, worker, charge ou politique et comparez le premier champ différent.

Public sources

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

Conclusion pratique

Détectez PressureObserver, gardez la voie de base utilisable et laissez une politique bornée suspendre ou restaurer le travail facultatif. Attribuez un seul propriétaire à l’observateur et son nettoyage, gardez les records grossiers et courts, et conservez les résultats validés. Rejouez le fixture après chaque changement et décidez à partir du premier état observable qui a changé.