Timing-Allow-Origin : ce que l'analytique voit dans la Resource Timing API
L'en-tête Timing-Allow-Origin contrôle le niveau de détail des données de timing cross-origin qu'une page peut lire. Voici ce que cela implique pour une mesure de performance respectueuse de la vie privée.
L'en-tête que personne ne définit exprès
La plupart des équipes ne rencontrent Timing-Allow-Origin (TAO) que lorsqu'un graphique de leur outil de monitoring affiche des zéros suspects. Les ressources cross-origin — polices, images provenant d'un CDN, un script tiers — apparaissent dans la Resource Timing API, mais leurs sous-timings détaillés sont renvoyés à 0, sauf si le serveur qui répond y consent explicitement. Ce consentement, c'est l'en-tête TAO, et le comprendre est essentiel si vous voulez des données de performance honnêtes sans recourir à un suivi intrusif.
Le standard Resource Timing expose une entrée PerformanceResourceTiming pour chaque requête effectuée par une page. Pour les ressources same-origin, vous obtenez la décomposition complète : résolution DNS, connexion TCP, négociation TLS, début de la requête et timings de réponse. Pour les ressources cross-origin, la spécification restreint délibérément ce qu'un document peut lire, car ces timings très détaillés peuvent divulguer des informations sur l'état du réseau de l'utilisateur, le contenu de son cache ou le comportement interne d'une autre origine.
Ce qui est remis à zéro
Sans un en-tête TAO correspondant, les attributs suivants d'une entrée PerformanceResourceTiming cross-origin sont ramenés à zéro : redirectStart, redirectEnd, domainLookupStart, domainLookupEnd, connectStart, connectEnd, secureConnectionStart, requestStart, responseStart, transferSize, encodedBodySize et decodedBodySize. Vous disposez toujours de startTime, duration, responseEnd, ainsi que du name et de l'initiatorType de la ressource. En pratique, cela signifie que vous pouvez savoir qu'une ressource s'est chargée et combien de temps cela a pris globalement, mais pas où ce temps a été passé ni combien d'octets ont transité sur le réseau.
La vérification est définie par l'algorithme de timing allow check de la spécification Resource Timing. Une ressource passe le test si sa réponse contient Timing-Allow-Origin avec une valeur qui correspond soit à l'origine du document demandeur, soit au caractère générique *.
Timing-Allow-Origin: https://example.com
# ou, pour autoriser toute origine
Timing-Allow-Origin: *
Pourquoi c'est important pour une analytique respectueuse de la vie privée
Monoid mesure la performance sur le terrain — de vraies navigations par de vrais visiteurs — sans cookies, sans localStorage et sans fingerprinting. Les API Resource Timing et Navigation Timing sont la manière standardisée de le faire, et TAO est le mécanisme que la plateforme utilise pour garder confidentielles par défaut les données de timing cross-origin.
Ce comportement par défaut est une fonctionnalité de confidentialité, pas un obstacle. Le passage à zéro existe précisément pour empêcher une page de sonder des origines tierces à la recherche de canaux auxiliaires basés sur le timing. Lorsque nous vous recommandons de définir Timing-Allow-Origin sur vos propres ressources statiques et votre CDN, nous vous demandons de rendre visible votre propre infrastructure pour votre propre mesure — et non d'affaiblir la protection de qui que ce soit.
Les Core Web Vitals renforcent ce point. Le Largest Contentful Paint est fréquemment une image cross-origin ou une police web. Si ces réponses ne comportent pas d'en-tête TAO, vous pouvez toujours observer l'élément LCP via la Largest Contentful Paint API, mais vous perdez les sous-timings de requête et de réponse qui vous indiqueraient si le retard vient d'un DNS lent, d'une poignée de main TLS à froid ou d'un transfert volumineux. Ajouter l'en-tête aux origines de vos ressources transforme un chiffre opaque en un chiffre exploitable.
Le configurer correctement
Quelques remarques pratiques. Premièrement, un transferSize non nul vous permet aussi de distinguer un hit de cache (une petite taille de transfert) d'une récupération réseau, ce qui est précieux pour diagnostiquer la performance en vue répétée. Deuxièmement, si vous servez des polices en cross-origin, l'attribut CSS crossorigin et le CORS sont une problématique distincte de TAO — vous pourriez avoir besoin des deux. Troisièmement, préférez nommer des origines spécifiques plutôt que d'utiliser * lorsque c'est possible, afin que seuls les documents qui ont légitimement besoin des données les reçoivent.
Sur Cloudflare, vous pouvez ajouter l'en-tête à la périphérie avec une Transform Rule ou dans une réponse de Worker, en l'appliquant aux chemins de vos ressources. Comme Monoid s'exécute sur la même périphérie, les données de timing collectées par les navigateurs de vos visiteurs alimentent directement des métriques agrégées et sans identifiant — nul besoin d'un profil par utilisateur pour savoir que votre image hero passe 400 ms en TLS.
À retenir
Timing-Allow-Origin est un petit en-tête dont l'influence est démesurée sur ce que vous pouvez apprendre des données de performance sur le terrain. Le comportement par défaut du navigateur — remettre à zéro les sous-timings cross-origin — est une protection de la vie privée délibérée, et il s'accorde parfaitement avec la manière dont l'analytique respectueuse de la vie privée devrait fonctionner : mesurer des agrégats via des API standard, rendre explicitement visibles vos propres origines dans le détail, et ne jamais considérer l'empreinte réseau d'un utilisateur comme quelque chose à collecter. Définissez TAO sur vos ressources, et le débogage de vos Web Vitals gagne en précision sans le moindre suivi.
Comments
Loading comments…