Speculation Rules और Prerendering: Prefetched पेजों के बारे में Analytics क्या गलत समझता है

वह पेज जो क्लिक से पहले लोड हो गया

Speculation Rules API, जो अब Chromium ब्राउज़रों में व्यापक रूप से उपलब्ध है, किसी साइट को यह घोषित करने देता है कि नेविगेशन से पहले ब्राउज़र को कौन-से URLs prefetch या पूरी तरह prerender करने चाहिए। जब कोई उपयोगकर्ता hover करता है या इरादा दिखाता है, तो गंतव्य पेज पहले से ही एक छिपे हुए टैब में रेंडर हो सकता है, फिर तुरंत स्वैप कर दिया जाता है। इसका लाभ यह है कि activation पर लगभग शून्य Largest Contentful Paint मिलता है। मापन के लिहाज़ से समस्या यह है कि एक prerendered पेज आपकी scripts को किसी के इसे विज़िट करने का फैसला लेने से पहले ही चला देता है।

अगर आपका analytics load पर एक pageview भेजता है, तो prerendering आपकी गिनती को ऐसी विज़िट्स से फुला देता है जो कभी हुई ही नहीं। इससे भी बुरा, यह प्रदर्शन डेटा को विकृत करता है: पृष्ठभूमि में prerender किया गया पेज ऐसे timings रिकॉर्ड करता है जिनका किसी वास्तविक उपयोगकर्ता के अनुभव से कोई संबंध नहीं होता।

prerender के दौरान वास्तव में क्या होता है

एक prerendered document सामान्य रूप से निष्पादित होता है, लेकिन एक विशेष lifecycle स्थिति में। document.prerendering का मान true होता है, और पेज अभी तक दृश्यमान टैब में activate नहीं हुआ होता। prerenderingchange event तब — और केवल तभी — fire होता है जब उपयोगकर्ता वास्तव में उस पर नेविगेट करता है। कई prerenders कभी activate होते ही नहीं; ब्राउज़र उन्हें त्याग सकता है।

यह दो कारणों से मायने रखता है:

1. गिनती। DOMContentLoaded पर एक भोला-भाला sendBeacon ऐसे document के लिए pageview रिपोर्ट कर देगा जो शायद कभी देखा ही न जाए।
2. प्रदर्शन आरोपण (attribution)। Core Web Vitals को उपयोगकर्ता द्वारा अनुभव किए गए लोडिंग के सापेक्ष परिभाषित किया गया है। web-vitals लाइब्रेरी और अंतर्निहित Paint Timing तथा Event Timing specs prerender का हिसाब activation बिंदु से मापकर रखते हैं, न कि मूल navigation start से। इस जागरूकता के बिना एकत्रित किया गया कोई भी metric बस गलत होता है।

सही पैटर्न

वेब प्लेटफ़ॉर्म आपको साफ़ signals देता है। किसी भी मापन को तब तक स्थगित करें जब तक पेज वास्तव में किसी व्यक्ति को दिखाई न दे:

if (document.prerendering) {
  document.addEventListener('prerenderingchange', recordPageview, { once: true });
} else {
  recordPageview();
}

timing के लिए, PerformanceNavigationTiming.activationStart navigation start और activation के बीच का offset देता है। किसी भी paint या interaction टाइमस्टैम्प को उस मान के सापेक्ष मापा जाना चाहिए, ऋणात्मक मानों को शून्य पर clamp करते हुए। Google की web-vitals लाइब्रेरी आंतरिक रूप से ठीक यही करती है, इसलिए अगर आप LCP या INP स्वयं गणना करते हैं, तो उसी तर्क का अनुसरण करें।

यही अनुशासन prefetch पर भी लागू होता है, जो prerender का हल्का चचेरा भाई है। Prefetch केवल response लाता है; यह scripts निष्पादित नहीं करता, इसलिए यह शायद ही कभी analytics को सीधे प्रदूषित करता है। लेकिन यह bandwidth ज़रूर खपत करता है और server-side request logs को विकृत कर सकता है — एक याद दिलाने वाली बात कि raw log गिनती और वास्तविक विज़िट्स पहले से कहीं ज़्यादा अलग होती जा रही हैं।

बिना cookies या client state के यह क्यों आसान है

Speculation-चालित prerender stateful trackers के लिए सिरदर्द है। एक prerendered document जो identifiers सेट करता है, किसी session को hydrate करता है, या storage में लिखता है, वह ऐसा अटकल के आधार पर करता है — एक ऐसी विज़िट के लिए जो त्याग दी जा सकती है। उसे साफ़ करना, अंततः होने वाले वास्तविक activation के विरुद्ध deduplicate करना, और cross-page पहचान का मिलान करना त्रुटि तथा गोपनीयता जोखिम का एक असली स्रोत बन जाता है।

Monoid पूरी समस्या-श्रेणी को ही किनारे कर देता है। हम डिवाइस पर कुछ भी संग्रहित नहीं करते — न cookies, न localStorage, न fingerprint। बनाने और बाद में मिटाने के लिए कोई speculative session होता ही नहीं। मापन एक अकेला, stateless signal है जिसे हम केवल तभी उत्सर्जित करते हैं जब पेज वास्तविक हो। चूँकि collection Cloudflare edge पर चलता है, aggregation ऐसे डेटा पर होता है जो पहले से ही वास्तविक, activate की गई navigations को दर्शाता है, न कि किसी ब्राउज़र के आशावादी अनुमानों को।

यह data minimisation है जो आपके पक्ष में काम कर रहा है। जब आप ऐसा कुछ भी एकत्र नहीं करते जिसे साफ़ करने की ज़रूरत हो, तो speculative rendering अनाथ पहचान रिकॉर्ड या डुप्लिकेट प्रोफ़ाइल नहीं बनाता। इसका बस इतना मतलब है कि आप गिनने से पहले prerenderingchange की प्रतीक्षा करते हैं।

prerender-सुरक्षित analytics के लिए एक चेकलिस्ट

• pageview उत्सर्जन को document.prerendering और prerenderingchange event पर gate करें।
• LCP, FCP, और INP को activationStart के सापेक्ष गणना करें, या ऐसी लाइब्रेरी का उपयोग करें जो पहले से यह करती है।
• server request logs को वास्तविक विज़िट्स का एक superset मानें, उनका proxy नहीं।
• पुष्टि करें कि आपकी Content-Security-Policy आपके मापन endpoint तक एक activate किए गए document से पहुँचने की अनुमति देती है; Chrome DevTools के prerender pane में परीक्षण करें।
• डिवाइस storage में किसी भी speculative लेखन से बचें — prerender-सही होने का सबसे साफ़ तरीका यह है कि कोई client state रखें ही नहीं।

व्यापक बात

हर नया प्रदर्शन primitive — bfcache, soft navigations, और अब speculation rules — चुपचाप उस पुरानी धारणा को तोड़ता है कि एक page load एक मानव विज़िट के बराबर होता है। जो analytics cookies और stateful sessions पर टिका है, उसे और भी ज़्यादा reconciliation तर्क जोड़ना पड़ता है। जो analytics वास्तविक दृश्यता के क्षण पर एक stateless event मापता है, उसे बस प्लेटफ़ॉर्म के lifecycle events का सम्मान करना होता है। तेज़ पेज और ईमानदार आँकड़े आपस में टकराव में नहीं हैं; आपको बस सही क्षण पर गिनना होता है।

Sources

• Speculation Rules API — MDN Web Docs
• Prerender pages in Chrome for instant page navigations — Chrome for Developers
• PerformanceNavigationTiming.activationStart — MDN Web Docs
• web-vitals library: prerender and bfcache handling — GitHub