Timing-Allow-Origin: Resource Timing API में Analytics को क्या दिखता है

वह हेडर जिसे कोई जानबूझकर सेट नहीं करता

अधिकांश टीमें Timing-Allow-Origin (TAO) से तभी रूबरू होती हैं जब उनके मॉनिटरिंग टूल का कोई चार्ट संदिग्ध शून्य दिखाता है। क्रॉस-ऑरिजिन रिसोर्सेज़ — फ़ॉन्ट्स, किसी CDN से आने वाली इमेजेज़, कोई थर्ड-पार्टी स्क्रिप्ट — Resource Timing API में दिखते हैं, पर उनकी विस्तृत सब-टाइमिंग्स 0 के रूप में पढ़ी जाती हैं, जब तक कि रिस्पॉन्स देने वाला सर्वर स्पष्ट रूप से इसकी अनुमति न दे। वह अनुमति ही TAO हेडर है, और यदि आप बिना किसी घुसपैठिया ट्रैकिंग के ईमानदार परफ़ॉर्मेंस डेटा चाहते हैं तो इसे समझना ज़रूरी है।

Resource Timing मानक हर उस फ़ेच के लिए एक PerformanceResourceTiming एंट्री उजागर करता है जो कोई पेज करता है। सेम-ऑरिजिन रिसोर्सेज़ के लिए आपको पूरा विवरण मिलता है: DNS लुकअप, TCP कनेक्ट, TLS नेगोशिएशन, रिक्वेस्ट स्टार्ट, और रिस्पॉन्स टाइमिंग्स। क्रॉस-ऑरिजिन रिसोर्सेज़ के लिए विनिर्देश जानबूझकर सीमित करता है कि कोई डॉक्यूमेंट क्या पढ़ सकता है, क्योंकि वे बारीक टाइमिंग्स किसी उपयोगकर्ता की नेटवर्क स्थिति, कैश सामग्री, या किसी दूसरे ऑरिजिन के आंतरिक व्यवहार के बारे में जानकारी लीक कर सकती हैं।

क्या शून्य कर दिया जाता है

मिलान करने वाले TAO हेडर के बिना, किसी क्रॉस-ऑरिजिन PerformanceResourceTiming एंट्री पर निम्नलिखित एट्रिब्यूट्स शून्य पर सीमित कर दिए जाते हैं: redirectStart, redirectEnd, domainLookupStart, domainLookupEnd, connectStart, connectEnd, secureConnectionStart, requestStart, responseStart, transferSize, encodedBodySize, और decodedBodySize। आपको फिर भी startTime, duration, responseEnd, और रिसोर्स का name तथा initiatorType मिलता है। व्यवहार में इसका अर्थ है कि आप बता सकते हैं कि कोई रिसोर्स लोड हुआ और कुल कितना समय लगा, पर यह नहीं कि समय कहाँ गया या कितने बाइट्स तार पर से गुज़रे।

यह जाँच Resource Timing विनिर्देश में timing allow check एल्गोरिदम द्वारा परिभाषित है। कोई रिसोर्स तब पास होता है जब उसके रिस्पॉन्स में Timing-Allow-Origin ऐसा मान लेकर आता है जो या तो रिक्वेस्ट करने वाले डॉक्यूमेंट के ऑरिजिन के बराबर हो या वाइल्डकार्ड * हो।

Timing-Allow-Origin: https://example.com
# or, to allow any origin
Timing-Allow-Origin: *

प्राइवेसी-फर्स्ट analytics के लिए यह क्यों मायने रखता है

Monoid परफ़ॉर्मेंस को फ़ील्ड से मापता है — असली विज़िटर्स द्वारा किए गए असली नेविगेशन्स — बिना कुकीज़, बिना localStorage, और बिना फ़िंगरप्रिंटिंग के। Resource Timing और Navigation Timing APIs इसे करने का मानक-आधारित तरीका हैं, और TAO वह तंत्र है जिसका उपयोग यह प्लेटफ़ॉर्म क्रॉस-ऑरिजिन टाइमिंग डेटा को डिफ़ॉल्ट रूप से गोपनीय रखने के लिए करता है।

वह डिफ़ॉल्ट एक प्राइवेसी फ़ीचर है, कोई बाधा नहीं। यह सीमितकरण ठीक इसीलिए मौजूद है ताकि कोई पेज टाइमिंग साइड चैनल्स के लिए थर्ड-पार्टी ऑरिजिन्स की जाँच न कर सके। जब हम अनुशंसा करते हैं कि आप अपनी स्टैटिक एसेट्स और CDN पर Timing-Allow-Origin सेट करें, तो हम आपसे आपके अपने बुनियादी ढाँचे को आपके अपने मापन के लिए दृश्यता में शामिल करने को कह रहे हैं — किसी की सुरक्षा को कमज़ोर करने को नहीं।

Core Web Vitals इस बात को और पुख्ता करते हैं। Largest Contentful Paint अक्सर एक क्रॉस-ऑरिजिन इमेज या वेब फ़ॉन्ट होता है। यदि उन रिस्पॉन्सेज़ में TAO हेडर नहीं है, तो आप Largest Contentful Paint API के ज़रिए LCP एलिमेंट को फिर भी देख सकते हैं, पर आप वे रिक्वेस्ट और रिस्पॉन्स सब-टाइमिंग्स खो देते हैं जो आपको बतातीं कि देरी धीमे DNS, ठंडे TLS हैंडशेक, या बड़े ट्रांसफ़र के कारण हुई। अपने एसेट ऑरिजिन्स में यह हेडर जोड़ने से एक अपारदर्शी संख्या एक कार्रवाई-योग्य संख्या में बदल जाती है।

इसे सही तरीके से सेट करना

कुछ व्यावहारिक बातें। पहला, transferSize का शून्य न होना आपको एक कैश हिट (छोटा ट्रांसफ़र साइज़) को नेटवर्क फ़ेच से अलग पहचानने भी देता है, जो रिपीट-व्यू परफ़ॉर्मेंस का निदान करते समय अमूल्य है। दूसरा, यदि आप फ़ॉन्ट्स क्रॉस-ऑरिजिन सर्व करते हैं, तो CSS crossorigin एट्रिब्यूट और CORS, TAO से एक अलग चिंता हैं — आपको दोनों की ज़रूरत पड़ सकती है। तीसरा, जहाँ संभव हो * के बजाय विशिष्ट ऑरिजिन्स नाम देना पसंद करें, ताकि केवल वे डॉक्यूमेंट्स जिन्हें वैध रूप से डेटा की ज़रूरत है, उसे प्राप्त करें।

Cloudflare पर, आप एज पर इस हेडर को एक Transform Rule से या किसी Worker रिस्पॉन्स में जोड़ सकते हैं, इसे अपने एसेट पाथ्स पर लागू करते हुए। चूँकि Monoid उसी एज पर चलता है, आपके विज़िटर्स के ब्राउज़र जो टाइमिंग डेटा एकत्र करते हैं वह सीधे एग्रीगेट, पहचानकर्ता-रहित मेट्रिक्स में बहता है — यह जानने के लिए कि आपकी हीरो इमेज TLS में 400ms बिताती है, किसी प्रति-उपयोगकर्ता प्रोफ़ाइल की ज़रूरत नहीं।

निष्कर्ष

Timing-Allow-Origin एक छोटा हेडर है जिसका इस बात पर असामान्य रूप से बड़ा प्रभाव है कि आप फ़ील्ड परफ़ॉर्मेंस डेटा से कितना सीख सकते हैं। ब्राउज़र का डिफ़ॉल्ट — क्रॉस-ऑरिजिन सब-टाइमिंग्स को शून्य करना — एक जानबूझकर बनाया गया प्राइवेसी सुरक्षा उपाय है, और यह इस बात से बड़े करीने से मेल खाता है कि प्राइवेसी-फर्स्ट analytics को कैसे काम करना चाहिए: मानक APIs से एग्रीगेट्स मापें, अपने ही ऑरिजिन्स को स्पष्ट रूप से विवरण में शामिल करें, और किसी उपयोगकर्ता के नेटवर्क फ़िंगरप्रिंट को कभी भी बटोरने लायक चीज़ न समझें। अपनी एसेट्स पर TAO सेट करें, और आपकी Web Vitals डीबगिंग बिना किसी ट्रैकिंग के तीक्ष्ण हो जाएगी।

Sources

• Resource Timing (W3C Working Draft) — Timing Allow Check
• MDN — Timing-Allow-Origin header
• MDN — PerformanceResourceTiming
• web.dev — Largest Contentful Paint (LCP)