INP भारी एनालिटिक्स को दंडित करता है: आपका ट्रैकर मेन थ्रेड पर क्यों है
Interaction to Next Paint वह Core Web Vital है जिसमें सबसे ज़्यादा साइटें फेल होती हैं, और फ़ील्ड डेटा दिखाता है कि बिहेवियर-ट्रैकिंग स्क्रिप्ट एक प्रमुख कारण हैं। समाधान है मेन थ्रेड पर कम काम भेजना।
Interaction to Next Paint (INP) वह Core Web Vital है जिसमें डेवलपर सबसे अधिक फेल होते हैं, और इसका कारण आपके <head> के भीतर बैठा है। INP 2024 में एक स्थिर Core Web Vital बन गया, जिसने First Input Delay की जगह ली, और यह वह चीज़ मापता है जो FID कभी नहीं माप सका: एक पेज अपने पूरे जीवनकाल में हर क्लिक, टैप और कीप्रेस के प्रति कितना उत्तरदायी बना रहता है।
यह मेट्रिक उस तरह के JavaScript के प्रति निर्मम है जो सर्विलांस एनालिटिक्स भेजती है। यदि आपका ट्रैकर मेन थ्रेड पर सार्थक काम करता है, तो आपके उपयोगकर्ता का हर इंटरैक्शन उस लागत को विरासत में पाता है।
INP वास्तव में क्या मापता है
INP किसी पेज पर सभी क्लिक, टैप और कीप्रेस के 75वें पर्सेंटाइल पर इंटरैक्शन की लेटेंसी रिपोर्ट करता है। 200 ms या उससे कम "अच्छा" है; 200 से 500 ms "सुधार चाहिए"; 500 ms से ऊपर "खराब" है।
हर इंटरैक्शन तीन चरणों में बँटता है:
- इनपुट डिले (input delay) — वह समय जब तक आपके इवेंट हैंडलर शुरू भी नहीं हो पाते, क्योंकि मेन थ्रेड व्यस्त है।
- प्रोसेसिंग अवधि — आपके इवेंट हैंडलर के कॉलबैक को चलने में लगने वाला समय।
- प्रेज़ेंटेशन डिले (presentation delay) — कॉलबैक समाप्त होने से लेकर ब्राउज़र द्वारा अगला फ़्रेम पेंट करने तक का समय।
भारी एनालिटिक्स तीनों चरणों को नुकसान पहुँचाती है। एक ट्रैकर जो बड़े bundle को पार्स करता है, कंसेंट लॉजिक का मूल्यांकन करता है, tag manager की कतार को बैच करता है, या फ़िंगरप्रिंट बनाने के लिए लेआउट पढ़ता है, ठीक उसी समय मेन थ्रेड पर कब्ज़ा कर लेता है जब उपयोगकर्ता इंटरैक्ट करने की कोशिश कर रहा होता है।
लॉन्ग टास्क ही तंत्र हैं
जब कोई टास्क चल रहा हो तब ब्राउज़र किसी इंटरैक्शन को प्रोसेस नहीं कर सकता। 50 ms से अधिक चलने वाला कोई भी टास्क एक लॉन्ग टास्क है, और 50 ms से अधिक का हिस्सा मृत समय है जिसके दौरान क्लिक कतार में जमा होते रहते हैं।
एक tag manager जो दर्जनों वेंडर स्क्रिप्ट को सिंक्रोनस रूप से लोड और एक्ज़ीक्यूट करता है, लॉन्ग टास्क का एक झरना पैदा करता है। उपयोगकर्ता क्लिक करता है, कुछ नहीं होता, फिर क्लिक करता है — और जब मेन थ्रेड आखिरकार खाली होता है, कतार में जमा इनपुट एक साथ सब फ़ायर हो जाते हैं।
यह सैद्धांतिक नहीं है। HTTP Archive के 2024 Web Almanac ने पाया कि यूज़र-बिहेवियर स्क्रिप्ट — session replay, हीटमैप, बिहेवियरल एनालिटिक्स — वाले पेज मोबाइल पर केवल 37% बार अच्छा INP प्राप्त कर सके, जबकि डेस्कटॉप पर 60%। कंसेंट-मैनेजमेंट स्क्रिप्ट — वे बैनर जो ये टूल माँगते हैं — मोबाइल के केवल 53% पेजों पर INP पास कर पाए। जो इंस्ट्रूमेंटेशन "उपयोगकर्ताओं को समझने" के लिए है, वह सक्रिय रूप से उनके अनुभव को बिगाड़ रहा है।
वह आर्किटेक्चर जो इससे बचता है
समाधान संरचनात्मक है, कोई टॉगल किया जाने वाला फ़्लैग नहीं। कम कोड भेजें, और उसे क्रिटिकल पाथ से बाहर रखें।
एक privacy-first ट्रैकर इतना छोटा हो सकता है कि उसका पार्सिंग और एक्ज़ीक्यूशन कभी लॉन्ग टास्क के रूप में दर्ज ही न हो। Monoid का ट्रैकर लगभग 2 KB का है, इसकी कोई dependency नहीं, कोई कुकी सेट नहीं करता, और कोई लेआउट नहीं पढ़ता — इसलिए फ़िंगरप्रिंट करने को कुछ नहीं और चलाने को कुछ भारी नहीं। यह एक ही keepalive अनुरोध से एक पेजव्यू दर्ज करता है और बाकी समय निष्क्रिय रहता है:
fetch('/collect', {
method: 'POST',
keepalive: true,
body: JSON.stringify({ site_id, path: location.pathname })
})
keepalive: true अनुरोध को मेन थ्रेड रोके बिना पेज के बाद भी जीवित रहने देता है, इसलिए नेविगेशन और unload कभी किसी beacon के इंतज़ार में ब्लॉक नहीं होते।
जब आप अपनी स्क्रिप्ट चलाएँ, तो काम के ब्लॉकों के बीच मेन थ्रेड को छोड़ दें ताकि कतार में जमा इंटरैक्शन चल सकें:
async function processQueue(items) {
for (const item of items) {
handle(item)
if (navigator.scheduling?.isInputPending?.()) {
await scheduler.yield()
}
}
}
scheduler.yield() एक लॉन्ग टास्क को टुकड़ों में बाँटता है और प्राथमिकता के साथ फिर से शुरू करता है, ताकि कोई थर्ड-पार्टी स्क्रिप्ट कतार में आपके continuation से आगे न घुस सके।
इसे फ़ील्ड में मापें, लैब में नहीं
Lighthouse INP रिपोर्ट नहीं कर सकता, क्योंकि INP तभी अस्तित्व में आता है जब कोई वास्तविक व्यक्ति इंटरैक्ट करता है। लैब टूल अनुमान लगाते हैं; वे उत्तरदायित्व नहीं मापते।
फ़ील्ड डेटा का उपयोग करें। Chrome User Experience Report (CrUX) ऑप्ट-इन किए हुए Chrome उपयोगकर्ताओं के वास्तविक इंटरैक्शन को एकत्रित करता है, और Search Console की Core Web Vitals रिपोर्ट वही डेटा प्रति URL समूह दिखाती है। यदि आपका CrUX INP ठीक है पर लैब Total Blocking Time अधिक है, तो आपके पास गुंजाइश है; यदि CrUX INP खराब है, तो आपके उपयोगकर्ता पहले से ही महसूस कर रहे हैं।
प्राइवेसी का तर्क और परफ़ॉर्मेंस का तर्क यहाँ मिलते हैं। एक ट्रैकर जो कोई स्टोरेज नहीं पढ़ता, कोई फ़िंगरप्रिंट नहीं बनाता, और कोई वेंडर झरना नहीं भेजता, उसके पास मेन थ्रेड पर करने को लगभग कुछ नहीं — और ठीक इसीलिए वह कभी आपके INP में नहीं दिखता। सर्विलांस मिलीसेकंड में महँगी है, केवल भरोसे में नहीं।
Comments
Loading comments…