← ब्लॉग पर वापस
3 मिनट पठनperformancecore-web-vitalsspaprivacy

Soft Navigations: SPA की परफ़ॉर्मेंस को ब्राउज़र के तरीके से मापना

Chrome की soft navigation heuristics आख़िरकार Core Web Vitals को क्लाइंट-साइड रूट बदलावों से जोड़ देती हैं। जानिए यह API कैसे काम करती है और इसे निगरानी के बिना कैसे मापें।

एक दशक तक Core Web Vitals केवल उस पहले पेज का वर्णन करते थे जिसे विज़िटर लोड करता था। single-page application में उसके बाद का हर रूट बदलाव मेट्रिक्स के लिए अदृश्य रहता था। Chrome का soft navigations प्रयोग इस अंतर को भरता है, और यह बदलता है कि प्राइवेसी-फ़र्स्ट एनालिटिक्स को असली यूज़र परफ़ॉर्मेंस कैसे मापनी चाहिए।

वह ब्लाइंड स्पॉट जिसे soft navigations ठीक करती हैं

एक पारंपरिक hard navigation दस्तावेज़ को unload करती है और एक नया लोड करती है। ब्राउज़र अपनी परफ़ॉर्मेंस टाइमलाइन रीसेट करता है, एक नया LCP फ़ायर करता है, और CLS तथा INP को शून्य से गिनना शुरू करता है। CrUX जैसे फ़ील्ड टूल सब कुछ उसी एक URL को सौंप देते हैं।

SPA इस तरह काम नहीं करते। शुरुआती लोड के बाद, React Router, Next.js का App Router, या SvelteKit History API का इस्तेमाल करके कंटेंट को उसी जगह बदल देते हैं। कोई दस्तावेज़ unload नहीं होता, इसलिए कोई नई परफ़ॉर्मेंस टाइमलाइन शुरू नहीं होती। एक यूज़र दस "पेज" तक क्लिक करके घूम सकता है जबकि हर Core Web Vital प्रवेश वाले URL पर ही टिका रहता है।

यह नतीजा हर उस व्यक्ति को पता है जिसने कभी किसी SPA का ऑडिट किया है: लैंडिंग रूट तेज़ दिखता है, और ऐप के भीतर गहराई में मौजूद धीमी इंटरैक्शन डेटा में कभी नहीं दिखतीं।

Chrome किसी soft navigation का पता कैसे लगाता है

Chrome की heuristic किसी soft navigation को रिकॉर्ड करने से पहले तीन चीज़ों के क्रम में होने की माँग करती है:

  1. नेविगेशन किसी यूज़र इंटरैक्शन से शुरू हो — एक क्लिक या एक key press।
  2. URL को History API या Navigation API द्वारा बदला जाए।
  3. इंटरैक्शन के बाद एक DOM बदलाव हो, जो पहले से मौजूद किसी DOM element को बदले।

यह क्रम जानबूझकर सख़्त है। एनालिटिक्स के लिए बैकग्राउंड में किया गया pushState, अपने आप आगे बढ़ने वाला carousel, या बिना इंटरैक्शन के URL बदलाव योग्य नहीं माने जाते। यह सटीकता मायने रखती है: इसका मतलब है कि एक soft navigation उस चीज़ से मेल खाती है जो किसी इंसान ने सचमुच की, न कि किसी आकस्मिक स्क्रिप्ट गतिविधि से।

API की सतह

soft navigations मानक PerformanceObserver के ज़रिए एक समर्पित entry type का उपयोग करके सामने आती हैं। आप इसे हर observer के लिए चुनते हैं:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log(entry.name, entry.startTime);
  }
}).observe({ type: "soft-navigation", buffered: true });

इससे भी अहम बात: अन्य परफ़ॉर्मेंस entries को एक navigationId मिलती है। किसी soft navigation के बाद उत्सर्जित LCP, layout-shift, और event-timing entries नई ID रखती हैं, इसलिए आप हर Core Web Vital को उस रूट से दोबारा जोड़ सकते हैं जिस पर यूज़र वाकई था:

new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // entry.navigationId इस LCP को एक विशिष्ट soft navigation से जोड़ती है
    send({ metric: "LCP", value: entry.startTime, navId: entry.navigationId });
  }
}).observe({ type: "largest-contentful-paint", buffered: true });

फ़िलहाल यह chrome://flags/#soft-navigation-heuristics और एक origin trial के पीछे रहता है, और CrUX में इसका एक्सपोज़र सीमित है। यह स्थिर Chrome में अभी डिफ़ॉल्ट नहीं है, इसलिए फ़ील्ड आँकड़ों को दिशासूचक मानें, अंतिम प्रमाण नहीं। web-vitals लाइब्रेरी अपने reportSoftNavs विकल्प के ज़रिए वही डेटा उजागर करती है, जो हाथ से observers लिखे बिना इसे जोड़ने का व्यावहारिक तरीक़ा है।

यह प्राइवेसी-फ़र्स्ट एनालिटिक्स से क्यों जुड़ता है

soft navigation डेटा शुद्ध timing है। इसमें कोई पहचानकर्ता नहीं, कोई cookie नहीं, और कुछ भी ऐसा नहीं जो पेज सेशन के बाद बचे — बस एक अवधि, एक मोटा element type, एक रूट path। यह बिल्कुल वही तरह का संकेत है जिसे एक cookie-रहित टूल सहमति की मशीनरी को छुए बिना इकट्ठा कर सकता है।

ट्रैकर पहले से ही history.pushState से हुक करता है ताकि SPA रूट बदलाव गिने जा सकें। soft navigations उसी हुक को और बारीक बनाती हैं: केवल यह पूछने के बजाय कि क्या रूट बदला, आप पूछ सकते हैं कि क्या यह इंटरैक्शन से चलने वाला नेविगेशन था, और इसकी परफ़ॉर्मेंस कैसी रही। परफ़ॉर्मेंस entries मौजूदा pageview beacon के साथ /collect तक जाती हैं, जिससे 2 KB से कम के स्क्रिप्ट पर बोझ डाले बिना और दैनिक-हैश पहचान मॉडल को तोड़े बिना फ़ील्ड मापन जुड़ जाता है।

बचने वाला जाल यह है कि soft navigations को और ज़्यादा इकट्ठा करने का बहाना न बनाएँ। कुछ RUM विक्रेता इस नई attribution का उपयोग एक सेशन भर में प्रति-यूज़र नेविगेशन यात्राओं को सिलने के लिए करेंगे — ठीक वही निगरानी पैटर्न जिसे अस्वीकार करने के लिए cookie-रहित एनालिटिक्स मौजूद है। यह मेट्रिक ठीक इसीलिए मूल्यवान है क्योंकि यह aggregate बनी रह सकती है: प्रति रूट median INP, प्रति रूट LCP वितरण, किसी व्यक्ति तक वापस जाने का कोई रास्ता नहीं।

soft navigations आपके ऐप के सबसे गहरे, सबसे धीमे हिस्सों को पहली बार मापने योग्य बनाती हैं। timing इकट्ठा करें, बाक़ी सब छोड़ दें, और आपको profile के बिना परफ़ॉर्मेंस की तस्वीर मिल जाती है।