Le W3C actualise High Resolution Time : bien mesurer les performances JavaScript

Le groupe de travail Web Performance du W3C a publié un nouveau brouillon de travail High Resolution Time  (en anglais) le 6 novembre 2026. Ce document décrit comment les applications web obtiennent une origine temporelle stable et mesurent des durées avec l’API performance, notamment entre plusieurs contextes du navigateur et avec des protections qui limitent la précision des horloges.

Il s’agit d’un Working Draft, pas d’une nouvelle version de navigateur ni d’une recommandation finale du W3C. Sa publication ne signifie pas que tous les navigateurs ont reçu une nouvelle fonction de mesure le 6 novembre. Elle donne surtout l’occasion de revenir sur une erreur courante : utiliser l’heure civile pour chronométrer de très petites opérations JavaScript.

Pourquoi performance.now() diffère de Date.now()

Date.now() fournit un horodatage fondé sur l’horloge système. C’est utile pour afficher la date et l’heure, mais moins adapté au calcul de durées : l’heure du système peut être corrigée. Plusieurs lectures successives peuvent donc donner des résultats faussés.

performance.now() mesure le temps écoulé depuis une origine temporelle, à partir d’une horloge monotone. Il convient mieux pour mesurer une opération comme le rendu d’un composant, une transformation de texte locale ou l’exécution d’un algorithme. Le brouillon définit aussi performance.timeOrigin, qui permet de rapprocher les mesures issues de différents contextes d’exécution.

Pour un premier essai dans les outils de développement du navigateur :

const start = performance.now();
const result = JSON.stringify({ name: 'example', values: [1, 2, 3] });
const elapsed = performance.now() - start;
console.log({ codeUnits: result.length, elapsedMs: elapsed });

La valeur codeUnits est la longueur de la chaîne JavaScript, pas sa taille encodée en octets. Cette opération minuscule sert uniquement d’illustration. Le bruit de mesure, la compilation JIT, le ramasse-miettes, l’ordonnancement du navigateur et la granularité de l’horloge peuvent dominer le résultat. Répétez des charges représentatives et comparez les distributions plutôt qu’une seule valeur aux nombreuses décimales.

Davantage de chiffres ne garantit pas davantage de précision

Le brouillon du W3C décrit la réduction de précision des horodatages, ou coarsening, ainsi que les choix de résolution et de variation aléatoire laissés aux implémentations. Les navigateurs peuvent réduire cette précision pour protéger la vie privée et limiter certaines attaques par canal auxiliaire facilitées par des horloges très fines.

L’algorithme décrit une résolution de base de 100 microsecondes et une valeur de 5 microsecondes dans les contextes isolés entre origines, tout en autorisant les implémentations à fournir une précision moindre. Ces valeurs définissent l’algorithme ; elles ne garantissent pas l’exactitude réelle sur chaque navigateur et appareil. Les nombreuses décimales d’un nombre JavaScript ne prouvent pas que l’horloge est aussi précise.

Cette distinction compte pour les outils de comparaison de performances et de profilage. Un écart de quelques microsecondes peut être sans signification si l’horodatage est volontairement arrondi ou si la tâche s’exécute dans un onglet déjà très occupé.

Attention aux horloges de la page et des workers

Une application peut mesurer du travail sur son fil principal et dans un Web Worker. La durée écoulée dans chaque contexte est utile, mais il ne faut pas soustraire directement des horodatages qui ont des origines différentes. Le brouillon explique comment performance.timeOrigin permet de les ramener à une même chronologie lorsque les contextes peuvent communiquer.

Un worker peut par exemple transmettre un horodatage approximativement relatif à l’époque Unix avec performance.timeOrigin + performance.now(). La page peut ensuite le convertir en une valeur relative à sa propre origine temporelle. C’est utile pour une visualisation, à condition de tenir compte du délai de communication, de la réduction de précision et des limites entre sessions du navigateur.

Pour examiner une interaction, le panneau Performance du navigateur donne une vue plus complète des tâches longues, du rendu et de l’occupation du fil principal. Si vous documentez les échanges avec un worker, l’éditeur de diagrammes Mermaid permet d’illustrer l’envoi, le traitement et la réception d’un message.

Que mesurer dès maintenant ?

Partez d’une question précise. Si une transformation HTML paraît lente, mesurez-la séparément du rendu et du téléchargement du fichier. Si une API semble lente, distinguez la réponse HTTP du serveur de son analyse et du rendu côté client. Notre guide d’inspection des requêtes réseau explique où consulter les requêtes et les réponses dans les principaux navigateurs.

Pour des vérifications limitées à HTTP, le générateur de commandes cURL aide à préparer une requête reproductible. cURL ne mesure pas l’exécution de JavaScript dans le navigateur : il fournit un point de vue complémentaire sur les requêtes, sans remplacer le profilage dans le navigateur.

Pour optimiser le balisage d’une page, le minificateur HTML compare la taille avant et après transformation. Notre annonce du minificateur HTML distingue les octets économisés dans la source des transferts compressés. Mesurez aussi le comportement réel de la page : une source plus courte ne garantit pas un JavaScript plus rapide ni une meilleure expérience.

Une évolution du standard, sans échéance de migration

Ce brouillon n’impose aucune migration immédiate. Continuez à utiliser les API Performance prises en charge, mesurez des charges représentatives et ne déduisez pas une précision inférieure à la milliseconde de la seule présence de décimales. Suivez la spécification du W3C  (en anglais) et les informations de compatibilité des navigateurs pour les évolutions suivantes.