Empreinte de fréquence d'images : affichage et vidéo

Ce guide traite de la fréquence d'affichage que révèle requestAnimationFrame et de la cadence des éléments vidéo. BotBrowser règle le rythme d'affichage avec --bot-fps et la cadence vidéo avec --bot-video-fps ; il ne peut pas donner à des matériels différents des performances identiques ni changer la façon dont un site interprète ces intervalles.

Résumé rapide

--bot-fps fixe le rythme d'affichage en mode profil, fixe ou réel, et --bot-video-fps réduit la cadence visuelle de la vidéo sans toucher à ce rythme. Notez séparément l'intervalle de requestAnimationFrame et la cadence de la vidéo dans chaque mode.

Sommaire de la guide

• Comment requestAnimationFrame révèle la fréquence d'affichage
• Pourquoi la fréquence d'affichage est un signal matériel
• Pourquoi les surcouches et les extensions laissent des failles
• Régler le rythme d'images de l'affichage
• Cadence de lecture vidéo et CPU
• Choisir les valeurs et vérifier le résultat

Comment requestAnimationFrame révèle la fréquence d'affichage

Lorsqu'une page appelle requestAnimationFrame(callback), le navigateur exécute le rappel avant le prochain affichage et lui transmet un DOMHighResTimeStamp qui marque le début de l'image. La référence MDN décrit ce contrat et précise que les rappels correspondent normalement à la fréquence de rafraîchissement de l'écran. En soustrayant des horodatages consécutifs, on obtient l'intervalle entre images, et en divisant une seconde par cet intervalle, on obtient la fréquence.

Une estimation fiable ne demande qu'un court échantillon. Rassembler quelques dizaines d'horodatages consécutifs et en moyenner les intervalles lisse les images lentes isolées, et toute la mesure se termine en une fraction de seconde sans que le visiteur remarque quoi que ce soit. Elle doit s'exécuter dans un onglet visible, car les navigateurs mettent généralement en pause ou ralentissent requestAnimationFrame pour les pages en arrière-plan.

Les mesures réelles sont bruitées. Une page chargée perd de temps en temps une image, ce qui apparaît comme un intervalle long parmi beaucoup d'intervalles réguliers, et un échantillon isolé peut tomber sur cette valeur aberrante. Prendre la médiane ou la moyenne sur une série plus longue donne un chiffre stable, qui se situe en général près d'une valeur connue comme 60, 90, 120 ou 144 Hz. Cette stabilité est ce qui rend le nombre utile pour un site qui veut reconnaître un appareil de retour.

Les animations et transitions CSS avancent sur le même cycle d'affichage. Une animation @keyframes d'une seconde produit à peu près une image par rafraîchissement, donc elle progresse par pas plus fins sur un écran de 144 Hz que sur un écran de 60 Hz. La spécification CSS ne promet pas une exactitude image par image, mais le rythme auquel une animation progresse suit toujours l'écran. Cela compte plus loin, car une page peut lire la fréquence depuis requestAnimationFrame et depuis une animation, et attendre que les deux lectures concordent.

La fréquence de rafraîchissement variable ajoute une autre dimension. Les écrans avec G-Sync, FreeSync ou ProMotion peuvent changer de fréquence selon le contenu, par exemple en descendant vers une fréquence plus basse quand presque rien ne bouge à l'écran. Une page qui observe assez longtemps voit non seulement une fréquence de base, mais aussi la manière dont elle varie, et ce motif diffère du rythme constant d'une dalle à fréquence fixe.

Les configurations à plusieurs moniteurs ajoutent un dernier détail. Quand une fenêtre passe d'un moniteur de 60 Hz à un moniteur de 144 Hz, les intervalles de rappel changent à cet instant. Une page qui suit les intervalles pendant une session peut remarquer ce déplacement, ce qui en dit long sur la disposition matérielle derrière la fenêtre du navigateur.

Pourquoi la fréquence d'affichage est un signal matériel

La fréquence de rafraîchissement appartient à l'écran physique et au compositeur qui le pilote. Elle ne change pas quand vous effacez les cookies, ouvrez une fenêtre privée ou changez de réseau. Un visiteur sur la même machine peut indiquer une cadence similaire, mais la charge, la fréquence variable et les changements d'écran peuvent déplacer les intervalles observés d'une session à l'autre.

Le signal porte aussi plus d'information qu'avant. Il n'y a pas si longtemps, presque tous les moniteurs grand public tournaient à 60 Hz, et le nombre n'apprenait presque rien à un site. Aujourd'hui, les dalles existent en 60, 75, 90, 120, 144, 165, 240 et 360 Hz, et les téléphones et portables à fréquence adaptative comme ProMotion ajoutent de la variété. Un visiteur avec un moniteur de 165 Hz appartient à un groupe bien plus petit qu'un visiteur à 60 Hz, de sorte que la valeur aide à restreindre les appareils dont une visite peut provenir. Les navigateurs mobiles se comportent de la même façon : des écrans de 60, 90 et 120 Hz existent, et beaucoup de téléphones récents changent de fréquence en fonctionnement.

La fréquence de rafraîchissement est un signal lié au matériel parmi plusieurs signaux d'affichage, et elle ne prouve pas l'identité à elle seule. Son poids vient de la combinaison. Avec la taille d'écran, la profondeur de couleur, le rapport de pixels de l'appareil et la sortie du GPU, elle contribue à une description matérielle bien plus précise que n'importe quelle valeur isolée. Le guide sur l'empreinte de l'écran et de la fenêtre couvre les signaux d'affichage voisins.

Plusieurs fonctions du navigateur exposent des signaux d'affichage liés. Les intervalles de requestAnimationFrame et la progression des animations CSS suivent le rythme d'affichage, tandis que les propriétés signalées décrivent l'état de la fenêtre et de l'écran. Une mesure de confidentialité qui n'en change qu'une seule peut laisser les autres pointer vers un autre contexte matériel.

Le même principe compte pour les équipes qui exécutent des navigateurs sur du matériel hétérogène. Les hôtes sans interface n'ont pas d'écran physique, et les machines virtuelles et les conteneurs signalent souvent des rythmes dictés par la charge de l'hôte plutôt que par un moniteur réel. Un profil décrit un appareil avec une fréquence de rafraîchissement précise, et un rythme visible par la page qui ne correspond pas au profil est un écart entre l'appareil déclaré et son comportement observé. Un profil de téléphone à 120 Hz dont les rappels arrivent à un rythme de 60 Hz en est un exemple.

Pourquoi les surcouches et les extensions laissent des failles

La fréquence d'images est une propriété matérielle locale que le navigateur mesure dans son propre cycle d'affichage, donc les outils qui agissent ailleurs ne l'atteignent pas. Un VPN ou tout autre outil réseau change l'itinéraire des requêtes et n'a aucun effet sur les intervalles de rappel. La navigation privée change l'endroit où les données sont stockées, pas la façon dont l'écran se rafraîchit, de sorte qu'une mesure dans une fenêtre privée correspond à celle d'une fenêtre normale.

Les extensions et les scripts de page qui modifient requestAnimationFrame ont plus de marge, mais se heurtent à des limites. Trois schémas sont courants, et chacun laisse une faille visible.

• Limiter le rappel. Un script peut envelopper l'API et appeler le rappel d'origine à une fréquence cible plus basse. Les animations légitimes saccadent, et les animations CSS continuent de tourner à la fréquence réelle de l'écran, si bien que les deux sources de temps se contredisent.
• Réécrire les horodatages. Modifier le DOMHighResTimeStamp transmis aux rappels peut imiter une autre fréquence, mais performance.now(), Date.now() et le rythme des transitions CSS continuent d'indiquer la cadence d'origine.
• Bloquer l'API. Désactiver requestAnimationFrame casse les nombreuses applications web qui s'en servent pour dessiner.

Le point commun est que ces outils se situent dans la couche JavaScript alors que la fréquence d'écran apparaît à plusieurs endroits. Changer un endroit sans les autres produit une incohérence, et une incohérence contredit l'appareil que décrit le profil.

Les réglages de développement de certains navigateurs permettent de plafonner la fréquence d'images. Un plafond limite la vitesse de rendu, mais c'est une limite haute et non une cible choisie. Vous ne pouvez pas demander une fréquence précise par session, un plafond ne peut pas relever la fréquence au-dessus de ce que fournit l'écran de l'hôte, et le bridage peut se manifester par des artefacts visibles. Un profil qui déclare 120 Hz ne peut pas être reproduit ainsi depuis un hôte de 60 Hz.

Régler le rythme d'images de l'affichage

BotBrowser prend en charge le rythme d'images de l'affichage avec --bot-fps, qui accepte profile, real ou un nombre. Ce paramètre est un contrôle ENT Tier2 et demande donc un profil avec l'activation ENT Tier2. Une fois défini, le rythme de requestAnimationFrame suit la fréquence choisie au lieu de celle que l'écran de l'hôte a par hasard.

Mode profil

En mode profile, qui est le mode par défaut, BotBrowser lit la fréquence de rafraîchissement enregistrée dans le profil chargé et aligne le rythme de requestAnimationFrame dessus.

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-fps=profile

Un profil décrit un appareil cible. Un profil capturé sur du matériel de 60 Hz indique une cadence de 60 Hz, et un profil capturé sur un appareil de 120 Hz ou 144 Hz indique la cadence plus rapide, quelle que soit la fréquence de l'écran de l'hôte. Pour la plupart des usages, c'est le bon choix, car la fréquence de rafraîchissement reste liée au reste de la description de l'appareil et n'exige aucune décision à chaque exécution.

Valeur fixe

Un nombre fixe une fréquence exacte, et le rythme des images et les intervalles de rendu la suivent sur n'importe quel matériel hôte.

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-fps=60

Utilisez-la lorsqu'un parc mélange des moniteurs à haute fréquence et des hôtes sans interface dont le rythme natif est irrégulier, et que vous voulez une même cadence partout. Choisissez des valeurs qui existent sur de vrais écrans, comme 60, 75, 90, 120, 144, 165 ou 240. Une valeur comme 73 ou 137 ne correspond à aucun moniteur qu'un visiteur possède vraisemblablement, donc elle contredirait l'écran que décrit le profil.

Mode réel

La valeur real utilise la fréquence native de l'écran de l'hôte.

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-fps=real

Elle convient lorsque le matériel de l'hôte correspond déjà à la cible du profil. C'est aussi un diagnostic pratique. Exécuter la même page avec real puis avec profile montre si l'instabilité vient de la charge de rendu de l'hôte ou des réglages du profil.

Le paramètre --bot-fps ne gouverne que le rythme d'affichage et d'exécution. La lecture vidéo a son propre contrôle, décrit ensuite, de sorte qu'une page peut conserver une cadence d'affichage de 60 Hz pendant que ses éléments vidéo se mettent à jour moins souvent.

Cadence de lecture vidéo et CPU

Les éléments vidéo continuent de décoder et d'afficher des images même lorsque le flux de travail ne lit que du texte, des réponses réseau, l'état du DOM ou une capture occasionnelle. Sur une page de surveillance, un tableau de files d'attente ou un catalogue riche en médias, ce décodage peut être le plus gros coût unitaire par onglet, et il augmente avec le nombre d'onglets.

BotBrowser prend en charge --bot-video-fps=<actual>[:<reported>] pour ce cas. C'est un contrôle ENT Tier2 qui fonctionne sur les profils dont Video FPS Control est activé. Les profils qui ne l'ont pas ignorent le paramètre.

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-video-fps=1:30

Le paramètre prend trois formes.

• --bot-video-fps=1 décode et affiche la vidéo près de 1 FPS et annonce 1 FPS.
• --bot-video-fps=1:30 affiche la vidéo près de 1 FPS pendant que l'annonce du média utilise 30 FPS.
• --bot-video-fps=1:real affiche la vidéo près de 1 FPS et annonce la cadence que le média déclare lui-même, lorsqu'elle est disponible.

La première valeur est la cadence visuelle réelle, qui détermine à quelle fréquence les images vidéo se mettent à jour. La seconde valeur est la politique d'annonce du média, et si elle est omise, la valeur réelle est annoncée. Le réglage real aligne les valeurs annoncées sur la cadence que déclare le média, et non sur la cadence réelle réduite.

La sortie en pixels suit la cadence réelle, et c'est la seule limite à prévoir. Un flux de travail qui échantillonne les pixels de la vidéo image par image, ou qui prend des captures devant montrer un contenu vidéo récent, voit la cadence réduite. Pour ces flux, choisissez une valeur réelle plus élevée, comme 5:30 ou 10:30, ou n'utilisez pas le paramètre. Une capture qui montre la vidéo à la cadence plus basse correspond au comportement configuré, pas à un défaut.

Le même raisonnement vaut pour toute vérification qui juge la qualité de lecture. Un test qui compte les images perdues, vérifie la fluidité de lecture ou compare des images vidéo consécutives mesure la cadence réelle, donc il a besoin de la fréquence complète et doit s'exécuter sans --bot-video-fps. Le paramètre convient au cas inverse, où la vidéo est un contenu d'arrière-plan et où le travail se passe dans le DOM, le réseau ou le texte de la page.

Le test de référence public de BotBrowser mesure l'effet sur une charge riche en vidéo. Le test a utilisé une build officielle Linux x64 en mode sans interface, avec de la vidéo AVC locale de 640 par 360 pixels et 30 FPS dans chaque élément, 10 secondes de préchauffage, une fenêtre d'échantillonnage de 30 secondes et 3 répétitions par réglage. La politique de base 30:30 a été comparée à 1:30.

Vidéos simultanées	CPU moyen de base	CPU moyen avec 1:30	Réduction
8	33,96 %	9,70 %	71,43 %
16	61,20 %	12,10 %	80,24 %
24	76,49 %	13,81 %	81,95 %

Ces chiffres décrivent une charge sur une plateforme. L'usage du CPU varie selon l'hôte, le pilote, le codec et le contenu de la page, donc lisez la plage de 71 à 82 % comme une référence issue d'un test riche en vidéo où une cadence visuelle plus basse était acceptable, et non comme une économie à attendre partout. Le test de référence de Video FPS Control détaille la configuration complète.

Lorsque les deux contrôles sont utilisés ensemble, l'exécution de l'affichage garde sa cadence de 60 Hz pendant que les éléments vidéo se mettent à jour moins souvent.

chromium-browser \
  --bot-profile="path/to/profile.enc" \
  --bot-fps=60 \
  --bot-video-fps=1:30

Choisir les valeurs et vérifier le résultat

Traitez les FPS d'affichage et les FPS vidéo comme deux décisions qui ont des responsables différents. Les FPS d'affichage font partie de la description de l'appareil, ils doivent donc correspondre au profil chargé, sauf si vous testez volontairement une autre classe d'écran. Un profil de portable de bureau à 60 Hz, un profil mobile à 120 Hz et un profil de poste fixe à haute fréquence ne doivent pas être mélangés à la légère, car le rythme des images se trouve à côté de la taille d'écran, du rapport de pixels de l'appareil, de la sortie du GPU et du rythme des animations. Le guide de gestion des profils couvre la façon dont les profils sont stockés et renouvelés.

Les FPS vidéo sont un choix opérationnel. Commencez par une valeur prudente : 1:30 lorsque des mises à jour visuelles occasionnelles suffisent, et une cadence réelle plus élevée lorsque les captures demandent des images plus récentes. La comparaison des pixels vidéo image par image est le cas qui exclut les valeurs très basses.

Pour les parcs, consignez la politique par charge de travail. Gardez une politique pour les pages qui demandent une lecture visuelle complète, une pour les pages d'arrière-plan qui portent des médias et une pour les flux de captures. Une politique écrite facilite la relecture ultérieure des changements de performance et sépare le réglage de la charge des décisions de cohérence du profil.

Pour vérifier le résultat, mesurez dans un onglet visible. Rassemblez les horodatages d'environ soixante rappels consécutifs de requestAnimationFrame, faites la moyenne des intervalles et comparez la fréquence obtenue avec celle qui est configurée. Comparez-la ensuite avec une lecture prise depuis une animation CSS. Pour la vidéo, comparez l'usage du CPU et la cadence visible avec et sans --bot-video-fps. Les exécutions sans interface et avec interface peuvent différer sous charge, donc validez les deux avec le même profil et les mêmes paramètres. Le guide sur la cohérence entre mode sans interface et mode avec interface couvre ces différences.

Transformer les échantillons de temps en contrôle d'échec

Cet échantillonneur enregistre 120 intervalles de rappels d'animation consécutifs. Exécutez-le dans la console DevTools de la page pendant que l'onglet reste visible ; la médiane estime la cadence habituelle, tandis que le 95e percentile révèle une queue d'images retardées qu'une moyenne peut masquer.

const intervals = [];
let previous;
let valid = document.visibilityState === 'visible';
if (!valid) console.log('sample invalid: open the page in a visible tab');
document.addEventListener('visibilitychange', () => {
  if (document.visibilityState !== 'visible') {
    valid = false;
    console.log('sample invalid: tab became hidden');
  }
});
function sample(timestamp) {
  if (!valid) return;
  if (previous !== undefined) intervals.push(timestamp - previous);
  previous = timestamp;
  if (intervals.length < 120) {
    requestAnimationFrame(sample);
    return;
  }
  const sorted = [...intervals].sort((a, b) => a - b);
  const middle = sorted.length / 2;
  const medianIntervalMs = (sorted[middle - 1] + sorted[middle]) / 2;
  const p95IntervalMs = sorted[Math.ceil(sorted.length * 0.95) - 1];
  console.log(
    JSON.stringify({
      visible: valid && document.visibilityState === 'visible',
      intervalCount: intervals.length,
      medianIntervalMs: Number(medianIntervalMs.toFixed(2)),
      p95IntervalMs: Number(p95IntervalMs.toFixed(2)),
      estimatedHz: Number((1000 / medianIntervalMs).toFixed(1)),
    })
  );
}
if (valid) requestAnimationFrame(sample);

Lisez l'échantillon comme un contrôle de branche, pas comme un verdict sur l'appareil :

Observation	Ce que cela établit	Prochaine vérification
L'onglet devient caché avant la fin des 120 intervalles	La limitation en arrière-plan a invalidé l'échantillon	Gardez l'onglet visible et refaites la même capture
La médiane est proche de la fréquence choisie mais le p95 est bien plus long	La cadence régulière existe, avec des images retardées dans la queue	Recommencez sur un hôte inactif et inspectez CPU/GPU avant de changer le profil
La médiane suit real mais pas la fréquence déclarée par le profil	Le rythme de l'hôte et celui du profil divergent	Confirmez l'argument --bot-fps actif et la fréquence d'affichage du profil
requestAnimationFrame correspond alors que la vidéo avance lentement sous 1:30	La cadence d'affichage et la cadence vidéo sont séparées comme prévu	Retirez la limite vidéo pour les pixels image par image ou les contrôles de lecture

La liste de dépannage existante couvre la dérive et la vidéo lente. Ces lignes ajoutent une méthode reproductible pour distinguer un échantillon invalide en arrière-plan, une queue de jitter, une divergence hôte-profil et une limite vidéo volontaire avant de modifier l'un ou l'autre contrôle.

La plupart des problèmes entrent dans quelques schémas.

• La fréquence mesurée s'écarte de la valeur configurée : vérifiez si le CPU et le GPU de l'hôte sont saturés, car une forte charge de rendu peut ajouter de l'instabilité autour de la fréquence cible.
• Le profil indique 120 Hz mais la mesure donne près de 60 : confirmez que --bot-fps n'est pas figé à 60 et vérifiez les arguments de lancement du processus en cours.
• La vidéo annonce 30 FPS mais semble lente : c'est attendu avec --bot-video-fps=1:30, car les FPS annoncés et la cadence visuelle sont séparés par conception.
• Le réglage vidéo reste inactif si le profil ne propose pas Video FPS Control ; vérifiez cette capacité avant de modifier --bot-video-fps.

Le rythme d'images n'est qu'une partie des temps d'exécution qu'une page peut observer. Le guide sur les temps de performance couvre les signaux de temps qui l'accompagnent.

BotBrowser prend en charge le réglage du rythme d'images de l'affichage avec --bot-fps (profile, real ou une valeur fixe) et de la cadence de lecture vidéo avec --bot-video-fps sur les profils dont Video FPS Control est activé, de sorte que le rythme de requestAnimationFrame suit le profil choisi et que les pages riches en vidéo peuvent consommer moins de CPU. Pour vous, cela signifie une fréquence de rafraîchissement conforme à l'appareil que vous avez choisi et une consommation de CPU plus faible sur des pages pleines de vidéo, avec les FPS d'affichage et les FPS vidéo décidés séparément. BotBrowser n'active pas ces contrôles sans l'activation ENT Tier2 du profil, n'applique pas --bot-video-fps sur les profils sans Video FPS Control, ne peut pas garantir la même économie de CPU en dehors de la charge testée et ne remplace pas le choix d'un profil dont les signaux d'affichage, de GPU et de temps sont cohérents.

Ce que cette page ajoute à la référence

La page de référence décrit les contrôles d'affichage. La comparaison ajoutée consigne séparément les intervalles de requestAnimationFrame et la cadence vidéo en modes profil, fixe et réel. Si l'animation est stable mais la vidéo ne l'est pas, examinez le pipeline média et la charge de l'hôte.

Sources publiques

• MDN : Window.requestAnimationFrame() : rythme des rappels et argument DOMHighResTimeStamp.
• MDN : Using CSS animations : progression des animations CSS.
• BotBrowser FPS Control : modes de --bot-fps et comportement de --bot-video-fps.
• Test de référence BotBrowser : mesures CPU de Video FPS Control.

Conclusion pratique

Commencez par une valeur prudente, comme 1:30 quand des mises à jour visuelles occasionnelles suffisent, et augmentez la cadence réelle si les captures exigent des images récentes.