साइन किए हुए एक्सचेंज का इस्तेमाल करके एलसीपी को ऑप्टिमाइज़ करना

साइन किए हुए एक्सचेंज को मेज़र और ऑप्टिमाइज़ करने का तरीका, ताकि उनमें से ज़्यादा से ज़्यादा सुधार किए जा सकें

साइन किए हुए एक्सचेंज (एसएक्सजी) की मदद से आपके पेज की स्पीड बेहतर होती है. खास तौर पर, यह सबसे बड़े एलिमेंट को रेंडर करने में लगने वाला समय (एलसीपी) है. जब रेफ़र करने वाली साइटों (फ़िलहाल, Google Search) किसी पेज से लिंक होती हैं, तो उपयोगकर्ता के लिंक पर क्लिक करने से पहले, वे साइट को ब्राउज़र की कैश मेमोरी में प्रीफ़ेच कर सकती हैं.

ऐसे वेब पेज भी बनाए जा सकते हैं जिन्हें प्रीफ़ेच किए जाने पर पेज को रेंडर करने के ज़रूरी पाथ पर किसी नेटवर्क की ज़रूरत न हो! किसी 4G कनेक्शन पर, यह पेज लोड 2.8 से 0.9 सेकंड तक हो जाता है (बाकी 0.9, ज़्यादातर सीपीयू के इस्तेमाल के हिसाब से होते हैं):

फ़िलहाल, एसएक्सजी पब्लिश करने वाले ज़्यादातर लोग, Cloudflare की आसानी से इस्तेमाल की जा सकने वाली, ऑटोमैटिक साइन इन एक्सचेंज (एएसएक्स) सुविधा का इस्तेमाल कर रहे हैं. हालांकि, ओपन सोर्स के विकल्प भी मौजूद हैं:

ऊपर बताए गए सुधार पाने के लिए, कई मामलों में इस सुविधा को चालू करने के लिए, बॉक्स पर सही का निशान लगाना ही काफ़ी होता है. कभी-कभी कुछ और चरणों की मदद से यह पक्का किया जाता है कि ये एसएक्सजी, पाइपलाइन के हर चरण में उम्मीद के मुताबिक काम करें. साथ ही, प्रीफ़ेच का पूरा फ़ायदा पाने के लिए पेजों को ऑप्टिमाइज़ किया जा सकता है.

Cloudflare के लॉन्च होने के बाद से, पिछले कुछ महीनों से, मैं अलग-अलग फ़ोरम पर सवालों को पढ़ रहा हूं और उनके जवाब दे रहा हूं. साथ ही, मैं साइटों को सलाह देने का तरीका भी सीख रहा हूं, ताकि यह पक्का किया जा सके कि उन्हें एसएक्सजी डिप्लॉयमेंट का ज़्यादा से ज़्यादा फ़ायदा मिले. इस पोस्ट में, मेरी सलाह का कलेक्शन मौजूद है. हम आपको इन चरणों के बारे में बताएंगे:

• WebPageTest का इस्तेमाल करके, एसएक्सजी की परफ़ॉर्मेंस का विश्लेषण करें.
• अगर विश्लेषण करने वाले चरण से पता चलता है कि यह काम नहीं कर रहा है, तो एसएक्सजी पाइपलाइन को डीबग करें.
• एसएक्सजी प्रीफ़ेच के लिए पेजों को ऑप्टिमाइज़ करें. इसमें बेहतर max-age सेट करना और रेंडर रोकने वाले सबरिसॉर्स को पहले से लोड करना शामिल है.
• सही एक्सपेरिमेंट और कंट्रोल ग्रुप चुनकर, Google Analytics का इस्तेमाल करके SXG में सुधार का आकलन करें.

परिचय

एसएक्सजी ऐसी फ़ाइल होती है जिसमें यूआरएल, एचटीटीपी रिस्पॉन्स हेडर का सेट, और रिस्पॉन्स का मुख्य हिस्सा होता है. इस फ़ाइल में वेब पीकेआई सर्टिफ़िकेट से क्रिप्टोग्राफ़िक तरीके से हस्ताक्षर किए जाते हैं. जब ब्राउज़र किसी एसएक्सजी को लोड करता है, तो यह इन सभी की पुष्टि करता है:

• एसएक्सजी की समयसीमा खत्म नहीं हुई है.
• हस्ताक्षर, यूआरएल, हेडर, मुख्य हिस्से, और सर्टिफ़िकेट से मेल खाता है.
• सर्टिफ़िकेट मान्य है और यूआरएल से मेल खाता है.

अगर पुष्टि नहीं हो पाती है, तो ब्राउज़र एसएक्सजी को छोड़ देता है और साइन किया गया यूआरएल फ़ेच करता है. पुष्टि हो जाने पर ब्राउज़र, साइन किए हुए जवाब को लोड कर देता है. ऐसा इस बात को ध्यान में रखकर किया जाता है कि यह रिस्पॉन्स सीधे साइन किए गए यूआरएल से आया है. इससे एसएक्सजी को किसी भी सर्वर पर फिर से होस्ट किया जा सकता है. ऐसा तब तक हो सकता है, जब तक साइन किए जाने के बाद एसएक्सजी की समयसीमा खत्म न हुई हो या उसमें कोई बदलाव न किया गया हो.

Google Search के मामले में, एसएक्सजी अपने खोज नतीजों में पेजों को प्रीफ़ेच करने की सुविधा चालू करता है. एसएक्सजी के साथ काम करने वाले पेजों के लिए, Google Search, webpkgcache.com पर होस्ट किए गए पेज की कैश मेमोरी में सेव की गई कॉपी को प्रीफ़ेच कर सकता है. ये webpkgcache.com यूआरएल, पेज के डिसप्ले या व्यवहार पर असर नहीं डालते, क्योंकि ब्राउज़र मूल, हस्ताक्षर किए गए यूआरएल का पालन करता है. प्रीफ़ेच करने से आपका पेज ज़्यादा तेज़ी से लोड हो सकता है.

विश्लेषण करें

एसएक्सजी के फ़ायदे देखने के लिए, सबसे पहले लैब टूल का इस्तेमाल करें. इससे, बार-बार इस्तेमाल की जा सकने वाली स्थितियों में एसएक्सजी की परफ़ॉर्मेंस का विश्लेषण किया जा सकता है. एसएक्सजी प्रीफ़ेच के साथ और उसके बिना वॉटरफ़ॉल और एलसीपी की तुलना करने के लिए, WebPageTest का इस्तेमाल किया जा सकता है.

एसएक्सजी के बिना, इस तरह टेस्ट जनरेट करें:

• WebPageTest पर जाएं और साइन इन करें. साइन इन करने पर, जांच का इतिहास सेव हो जाता है, ताकि बाद में आसानी से तुलना की जा सके.
• वह यूआरएल डालें जिसकी आपको जांच करनी है.
• बेहतर कॉन्फ़िगरेशन पर जाएं. (आपको एसएक्सजी टेस्ट के लिए, ऐडवांस कॉन्फ़िगरेशन की ज़रूरत होगी. इसलिए, यहां इसका इस्तेमाल करने से यह पक्का करने में मदद मिलती है कि जांच के विकल्प एक जैसे हैं.)
• टेस्ट सेटिंग टैब में, कनेक्शन को 4G पर सेट करना और "चलाए जाने वाले टेस्ट की संख्या" को बढ़ाना मददगार साबित हो सकता है से 7 तक.
• जांच शुरू करें पर क्लिक करें.

ऊपर बताए गए चरणों का इस्तेमाल करके, एसएक्सजी के साथ टेस्ट जनरेट करें. हालांकि, टेस्ट शुरू करें पर क्लिक करने से पहले, स्क्रिप्ट टैब पर जाएं. इसके बाद, यहां दी गई WebPageTest स्क्रिप्ट को चिपकाएं और navigate के बताए गए यूआरएल में बदलाव करें:

// Disable log collection for the first step. We only want the waterfall for the target navigation.
logData 0

// Visit a search result page that includes your page.
navigate https://google.com/search?q=site%3Asigned-exchange-testing.dev+image

// Wait for the prefetch to succeed.
sleep 10

// Re-enable log collection.
logData 1

// Navigate to the prefetched SXG on the Google SXG Cache.
navigate https://signed--exchange--testing-dev.webpkgcache.com/doc/-/s/signed-exchange-testing.dev/sxgs/valid-image-subresource.html

अगर पहले navigate यूआरएल के लिए, आपका पेज अब भी Google Search के किसी भी नतीजे में नहीं दिखता है, तो इस प्रीफ़ेच पेज का इस्तेमाल करके, खोज नतीजों का वह पेज जनरेट किया जा सकता है जो दिखाता है कि वह खोज के नतीजों में दिखने का तरीका क्या है.

navigate का दूसरा यूआरएल तय करने के लिए, एसएक्सजी वैलिडेटर वाले Chrome एक्सटेंशन का इस्तेमाल करके अपने पेज पर जाएं और कैश मेमोरी का यूआरएल देखने के लिए, एक्सटेंशन आइकॉन पर क्लिक करें:

ये जांच पूरी होने के बाद, जांच के इतिहास पर जाएं. इसके बाद, दोनों जांच चुनें और तुलना करें पर क्लिक करें:

तुलना करने वाले यूआरएल में &medianMetric=LCP जोड़ें, ताकि WebPageTest तुलना के हर हिस्से के लिए मीडियन LCP वाले रन को चुन सके. (डिफ़ॉल्ट रूप से स्पीड इंडेक्स से मीडियन होता है.)

वॉटरफ़ॉल की तुलना करने के लिए, वॉटरफ़ॉल ओपैसिटी सेक्शन को बड़ा करें और स्लाइडर को खींचें और छोड़ें. वीडियो देखने के लिए, फ़िल्मस्ट्रिप सेटिंग अडजस्ट करें पर क्लिक करें, उस डायलॉग बॉक्स में नीचे की ओर स्क्रोल करें, और वीडियो देखें पर क्लिक करें.

अगर एसएक्सजी प्रीफ़ेच हो जाता है, तो आपको "एसएक्सजी के साथ" दिखेगा वॉटरफ़ॉल में एचटीएमएल के लिए लाइन शामिल नहीं होती और सबरिसॉर्स के लिए फ़ेच जल्दी शुरू हो जाते हैं. उदाहरण के लिए, "पहले" की तुलना करें और "बाद में" यहां:

डीबग

अगर WebPageTest से पता चल रहा है कि एसएक्सजी को प्रीफ़ेच किया जा रहा है, तो इसका मतलब है कि वह पाइपलाइन के सभी चरणों में सफल हो गया है; एलसीपी को और बेहतर बनाने का तरीका जानने के लिए, ऑप्टिमाइज़ करें सेक्शन पर जाएं. अगर ऐसा नहीं है, तो आपको यह पता लगाना होगा कि पाइपलाइन में यह कहां फ़ेल हुआ और क्यों; इसका तरीका जानने के लिए आगे पढ़ें.

Publishing

पक्का करें कि आपके पेज, एसएक्सजी के तौर पर जनरेट किए जा रहे हों. ऐसा करने के लिए, आपको क्रॉलर होने का दिखावा करना होगा. एसएक्सजी वैलिडेटर Chrome एक्सटेंशन का इस्तेमाल करने का सबसे आसान तरीका:

एक्सटेंशन, मौजूदा यूआरएल को Accept अनुरोध के हेडर के साथ फ़ेच करता है. इस हेडर में लिखा होता है कि वह एसएक्सजी वर्शन को प्राथमिकता देता है. अगर आपको ऑरिजिन के आगे सही का निशान (✅) दिखता है, तो इसका मतलब है कि एसएक्सजी लौटा दिया गया है; इंडेक्स करना सेक्शन पर जाएं.

अगर आपको क्रॉस का निशान (❌) दिखता है, तो इसका मतलब है कि एसएक्सजी को लौटाया नहीं जा सका:

अगर Cloudflare ASX की सुविधा चालू है, तो क्रॉस मार्क (❌) की वजह से हो सकता है. ऐसा इसलिए होता है, क्योंकि कैश कंट्रोल रिस्पॉन्स हेडर इस प्रोसेस को रोकता है. ASX, इन नामों वाले हेडर का पता लगाता है:

• Cache-Control
• CDN-Cache-Control
• Surrogate-Control
• Cloudflare-CDN-Cache-Control

अगर इनमें से किसी भी हेडर में इनमें से कोई भी हेडर वैल्यू शामिल है, तो यह एसएक्सजी को जनरेट होने से रोकेगा:

• private
• no-store
• no-cache
• max-age 120 से कम, जब तक कि s-maxage को 120 से ज़्यादा या इसके बराबर न बदला जाए

ऐसे मामलों में ASX, एसएक्सजी नहीं बनाता. ऐसा इसलिए, क्योंकि एक से ज़्यादा विज़िट और वेबसाइट पर आने वाले लोगों के लिए, एसएक्सजी को कैश मेमोरी में सेव करके फिर से इस्तेमाल किया जा सकता है.

क्रॉस मार्क (❌) की एक और संभावित वजह Set-Cookie को छोड़कर, इन स्टेटफ़ुल रिस्पॉन्स हेडर में से किसी एक का मौजूद होना है. एसएक्सजी की शर्तों का पालन करने के लिए, ASX, Set-Cookie हेडर को हटा देता है.

Vary: Cookie रिस्पॉन्स हेडर मौजूद होने की भी दूसरी वजह हो सकती है. Googlebot, एसएक्सजी को उपयोगकर्ता के क्रेडेंशियल के बिना फ़ेच करता है और उन्हें वेबसाइट पर आने वाले कई लोगों को भेज सकता है. अगर कुकी के आधार पर, अलग-अलग उपयोगकर्ताओं को अलग-अलग एचटीएमएल दिखाया जाता है, तो हो सकता है कि उन्हें लॉग आउट किया गया व्यू जैसा गलत अनुभव दिखे.

इसके अलावा, Chrome एक्सटेंशन का इस्तेमाल करके, curl जैसे टूल का इस्तेमाल किया जा सकता है:

curl -siH "Accept: application/signed-exchange;v=b3" $URL | less

या dump-signedexchange:

dump-signedexchange -verify -uri $URL

अगर एसएक्सजी मौजूद है और मान्य है, तो आपको एसएक्सजी का ऐसा प्रिंटआउट दिखेगा जिसे कोई भी व्यक्ति आसानी से पढ़ सकता है. ऐसा न करने पर, आपको गड़बड़ी का मैसेज दिखेगा.

इंडेक्स करना

पक्का करें कि Google Search ने आपके एसएक्सजी को इंडेक्स किया हो. Chrome DevTools खोलें. इसके बाद, अपना पेज Google Search में खोजें. अगर इसे एसएक्सजी के तौर पर इंडेक्स किया गया है, तो आपके पेज के Google के लिंक में एक data-sxg-url शामिल होगा जो webpkgcache.com की कॉपी पर ले जाता है:

अगर Google Search को लगता है कि उपयोगकर्ता नतीजे पर क्लिक कर सकता है, तो वह उसे प्रीफ़ेच कर देगा:

<link> एलिमेंट, ब्राउज़र को एसएक्सजी को उसकी प्रीफ़ेच कैश मेमोरी में डाउनलोड करने का निर्देश देता है. जब लोग <a> एलिमेंट पर क्लिक करते हैं, तब पेज को रेंडर करने के लिए ब्राउज़र, कैश मेमोरी में सेव किए गए उस एसएक्सजी का इस्तेमाल करेगा.

DevTools में नेटवर्क टैब पर जाकर और webpkgcache वाले यूआरएल खोजकर भी प्रीफ़ेच का सबूत देखा जा सकता है.

अगर <a>, webpkgcache.com पर ले जाता है, तो इसका मतलब है कि साइन किए गए एक्सचेंज के लिए, Google Search इंडेक्स हो रहा है. इसके बाद, सीधे डेटा डालना सेक्शन पर जाएं.

अगर ऐसा नहीं है, तो हो सकता है कि एसएक्सजी को चालू करने के बाद से, Google ने आपके पेज को फिर से क्रॉल न किया हो. Google Search Console यूआरएल जांचने वाला टूल आज़माएं:

digest: mi-sha256-03=... हेडर के मौजूद होने का मतलब है कि Google ने एसएक्सजी वर्शन को क्रॉल किया है.

अगर digest हेडर मौजूद नहीं है, तो इसका मतलब है कि Googlebot को एसएक्सजी नहीं दिखाया गया है या एसएक्सजी चालू करने के बाद से इंडेक्स को अपडेट नहीं किया गया है.

अगर कोई एसएक्सजी क्रॉल हो गया है, लेकिन उसे लिंक नहीं किया जा रहा है, तो हो सकता है कि एसएक्सजी कैश मेमोरी की ज़रूरी शर्तों को पूरा न कर पाए. इनके बारे में अगले सेक्शन में बताया गया है.

डेटा डालना

जब Google Search किसी एसएक्सजी को इंडेक्स करता है, तो वह उसकी कॉपी Google एसएक्सजी कैश मेमोरी में भेजता है. एसएक्सजी कैश मेमोरी इस बात की पुष्टि करती है कि एसएक्सजी, कैश मेमोरी से जुड़ी ज़रूरी शर्तों के मुताबिक है या नहीं. Chrome एक्सटेंशन यह नतीजा दिखाता है:

अगर आपको सही का निशान (✅) दिखता है, तो सीधे ऑप्टिमाइज़ पर जाएं.

अगर यह ऐप्लिकेशन ज़रूरी शर्तों को पूरा नहीं करता है, तो आपको एक क्रॉस का निशान (❌) वाला एक मैसेज दिखेगा. साथ ही, चेतावनी वाला एक मैसेज भी दिखेगा, जिसमें बताया गया होगा कि ऐसा क्यों हुआ:

इस स्थिति में, एसएक्सजी को चालू करने से पहले पेज की तरह ही काम करेगा. Google, एसएक्सजी प्रीफ़ेच के बिना, अपने ओरिजनल होस्ट पर मौजूद पेज को लिंक करेगा.

अगर कैश मेमोरी में सेव की गई कॉपी की समयसीमा खत्म हो गई है और उसे बैकग्राउंड में फिर से फ़ेच किया जा रहा है, तो आपको एक रेत-घड़ी (⌛) दिखेगी:

एसएक्सजी पर मौजूद Google के डेवलपर दस्तावेज़ में, कैश मेमोरी में सेव डेटा को मैन्युअल तरीके से क्वेरी करने का तरीका भी बताया गया है.

Optimize

अगर एसएक्सजी वैलिडेटर वाले Chrome एक्सटेंशन में सभी सही के निशान (✅) दिखते हैं, तो आपके पास एक एसएक्सजी है जो उपयोगकर्ताओं को दिखाया जा सकता है! अपने वेब पेज को ऑप्टिमाइज़ करने का तरीका जानने के लिए आगे पढ़ें. इससे आपको एसएक्सजी से एलसीपी में सबसे ज़्यादा सुधार करने में मदद मिलेगी.

ज़्यादा से ज़्यादा उम्र

एसएक्सजी की समयसीमा खत्म होने पर, Google एसएक्सजी कैश मेमोरी बैकग्राउंड में एक नई कॉपी फ़ेच कर देगी. फ़ेच किए जाने का इंतज़ार करते समय, उपयोगकर्ताओं को उसके मूल होस्ट पर मौजूद पेज पर भेज दिया जाता है, जिसे प्रीफ़ेच नहीं किया जाता है. Cache-Control: max-age को जितना ज़्यादा सेट किया जाता है उतना ही कम यह बैकग्राउंड फ़ेच होता है. इसलिए, एलसीपी को प्रीफ़ेच के ज़रिए कम किया जा सकता है.

यह परफ़ॉर्मेंस और अपडेट होने के बीच का अंतर है. कैश मेमोरी की मदद से साइट के मालिक, दो मिनट से सात दिन के बीच एसएक्सजी उपलब्ध करा सकते हैं. ये एसएक्सजी, हर पेज की ज़रूरत के हिसाब से दिए जा सकते हैं. आम तौर पर, हम देखते हैं कि:

• परफ़ॉर्मेंस के लिए, max-age=86400 (1 दिन) या इससे लंबे समय तक काम करता है
• max-age=120 (2 मिनट) में काम नहीं करती

उम्मीद है कि हम इन दोनों के बीच के मानों के बारे में ज़्यादा जानेंगे, क्योंकि हम डेटा का ज़्यादा अध्ययन कर रहे हैं.

उपयोगकर्ता एजेंट

एक बार, प्रीफ़ेच किए गए एसएक्सजी का इस्तेमाल करने पर, एलसीपी में बढ़ोतरी हुई. मैंने WebPageTest चलाया. इसमें एसएक्सजी प्रीफ़ेच के बिना और उसके बिना मीडियन नतीजों की तुलना की गई. नीचे बाद में पर क्लिक करें:

मैंने देखा कि प्रीफ़ेच काम कर रहा था. एचटीएमएल को ज़रूरी पाथ से हटा दिया जाता है और इसलिए सभी सबरिसॉर्स जल्दी लोड हो पाते हैं. हालांकि, एलसीपी—हरी डैश वाली लाइन—2 सेकंड से बढ़कर 2.1 सेकंड हो गई.

इसका पता लगाने के लिए, मैंने फ़िल्म स्ट्रिप को देखा. मैंने पाया कि एसएक्सजी में पेज अलग तरह से रेंडर हुआ था. सादे एचटीएमएल में, Chrome ने पाया कि "सबसे बड़ा एलिमेंट" वहीं, इस हेडलाइन का इस्तेमाल किया गया. हालांकि, एसएक्सजी वर्शन में, पेज में लेज़ी लोडेड बैनर जोड़ा गया, जिसकी वजह से हेडलाइन को वेबसाइट में फ़ोल्ड के नीचे ले जाया गया. इसकी वजह से, नया एलिमेंट, लेज़ी-लोडेड कुकी के लिए सहमति वाला डायलॉग बॉक्स बन गया. सब कुछ पहले से ज़्यादा तेज़ी से रेंडर हुआ, लेकिन लेआउट में बदलाव की वजह से मेट्रिक की रिपोर्ट धीमी हो गई.

मैंने बारीकी से इसकी जानकारी ढूंढी है और हमें पता चला है कि लेआउट में इस अंतर की वजह यह है कि पेज User-Agent के हिसाब से अलग-अलग है और लॉजिक में कोई गड़बड़ी थी. हालांकि, एसएक्सजी के क्रॉल हेडर में मोबाइल का इस्तेमाल होने के बावजूद, यह डेस्कटॉप पेज दिखा रहा था. इस गड़बड़ी को ठीक करने के बाद, ब्राउज़र ने पेज की हेडलाइन को फिर से सबसे बड़े एलिमेंट के तौर पर सही तरीके से पहचाना.

"बाद में" पर क्लिक करने पर, मुझे पता चला कि प्रीफ़ेच किया गया एलसीपी 1.3 सेकंड तक कम हो जाता है:

एसएक्सजी, डिवाइस के हर नाप या आकार के लिए चालू हैं. इसकी तैयारी करने के लिए, पक्का करें कि इनमें से कोई एक बात सही है:

• आपका पेज User-Agent से Vary नहीं करता है (उदाहरण के लिए, यह रिस्पॉन्सिव डिज़ाइन या अलग मोबाइल/डेस्कटॉप यूआरएल का इस्तेमाल करता है).
• अगर आपका पेज डाइनैमिक तरीके से दिखाने की सुविधा का इस्तेमाल करता है, तो <meta name=supported-media content=...> का इस्तेमाल करके वह खुद को मोबाइल या डेस्कटॉप पर एनोटेट करता है.

सबरिसॉर्स

एसएक्सजी का इस्तेमाल, एचटीएमएल के साथ-साथ सबरिसॉर्स (इमेज भी शामिल हैं) को प्रीफ़ेच करने के लिए किया जा सकता है. Cloudflare ASX, एक ही ऑरिजिन (पहले पक्ष) के <link rel=preload> एलिमेंट के लिए, एचटीएमएल को स्कैन करेगा और उन्हें SXG के साथ काम करने वाले लिंक हेडर में बदल देगा. सोर्स कोड के बारे में ज़्यादा जानकारी यहां और यहां दी गई है.

अगर यह काम कर रहा है, तो आपको Google Search से और प्रीफ़ेच दिखेंगे:

एलसीपी के लिए ऑप्टिमाइज़ करने के लिए, अपने वॉटरफ़ॉल में बारीकी से देखें और पता करें कि सबसे बड़े एलिमेंट को रेंडर करने के लिए कौनसे संसाधन अहम हैं. अगर उन्हें प्रीफ़ेच नहीं किया जा सकता, तो देखें कि उन्हें ज़रूरी पाथ से हटाया जा सकता है या नहीं. ऐसी स्क्रिप्ट का ध्यान रखें जो पेज को तब तक छिपाती हैं, जब तक वे लोड नहीं हो जातीं.

Google एसएक्सजी कैश मेमोरी, 20 तक सबरिसॉर्स को पहले से लोड करने की अनुमति देती है. साथ ही, एएसएक्स पक्का करता है कि यह सीमा पार न हो. हालांकि, बहुत ज़्यादा सबरिसॉर्स प्रीलोड जोड़ने का जोखिम हो सकता है. ब्राउज़र, पहले से लोड किए गए सबरिसॉर्स का इस्तेमाल सिर्फ़ तब करेगा, जब सभी सोर्स को फ़ेच किया जा चुका हो, ताकि क्रॉस-साइट ट्रैकिंग को रोका जा सके. जितने ज़्यादा उपसंसाधन होंगे, उपयोगकर्ता के आपके पेज पर क्लिक करने से पहले ही उन सभी के प्रीफ़ेच करने की संभावना उतनी ही कम होगी.

एसएक्सजी की पुष्टि करने वाला प्रोग्राम, फ़िलहाल सबरिसॉर्स की जांच नहीं करता है; डीबग करने के लिए, इस दौरान curl या dump-signedexchange का इस्तेमाल करें.

मापें

WebPageTest के तहत एलसीपी सुधार को ऑप्टिमाइज़ करने के बाद, आपकी साइट की पूरी परफ़ॉर्मेंस पर एसएक्सजी प्रीफ़ेच करने के असर को मापना फ़ायदेमंद होता है.

सर्वर-साइड मेट्रिक

टाइम टू फ़र्स्ट बाइट (टीटीएफ़बी) जैसी सर्वर साइड मेट्रिक का आकलन करते समय, यह ध्यान रखना ज़रूरी है कि आपकी साइट सिर्फ़ उन क्रॉलर को एसएक्सजी दिखाती है जो फ़ॉर्मैट स्वीकार करते हैं. TTFB के मेज़रमेंट को सिर्फ़ असली उपयोगकर्ताओं से मिलने वाले अनुरोधों तक ही सीमित रखें, न कि बॉट से. एसएक्सजी जनरेट करने से, क्रॉलर अनुरोधों के लिए टीटीएफ़बी में बढ़ोतरी होती है. हालांकि, इससे आपकी वेबसाइट पर आने वाले लोगों के अनुभव.

क्लाइंट-साइड मेट्रिक

क्लाइंट-साइड मेट्रिक, खास तौर पर एलसीपी के लिए एसएक्सजी की स्पीड का सबसे ज़्यादा फ़ायदा है. इनकी असर का आकलन करते समय, Cloudflare ASX को चालू किया जा सकता है. इसके लिए, Googlebot के फिर से क्रॉल होने का इंतज़ार करें. इसके बाद, Core Web Vitals (CWV) के डेटा को इकट्ठा करने के लिए, 28 दिन इंतज़ार करें. इसके बाद, अपने नए CWV नंबर देखें. हालांकि, इस समयावधि में हुए बदलावों को अन्य सभी बदलावों के साथ मिला देने पर, उनका पता लगाना मुश्किल हो सकता है.

इसके बजाय, मुझे "ज़ूम इन" करना मददगार लगता है को प्रभावित करता है और उसे इस तरह से फ़्रेम करता है, "एसएक्सजी, पेज व्यू के X% पर असर डालते हैं, जिससे उनका एलसीपी 75वें पर्सेंटाइल पर Y मिलीसेकंड तक बेहतर हो जाता है."

फ़िलहाल, एसएक्सजी प्रीफ़ेच सिर्फ़ कुछ खास स्थितियों में होता है:

• Chromium ब्राउज़र (जैसे, iOS को छोड़कर Chrome या Edge), M98 या उसके बाद का वर्शन
• Referer: google.com या अन्य Google Search डोमेन. (ध्यान दें कि Google Analytics में, एक रेफ़रल टैग सेशन के दौरान सभी पेज व्यू पर लागू होता है, जबकि एसएक्सजी प्रीफ़ेच सिर्फ़ पहले पेज व्यू पर लागू होता है, जो सीधे Google Search से लिंक होता है.)

"X% पेज व्यू" को मेज़र करने का तरीका जानने के लिए, मौजूदा समय में की गई स्टडी का सेक्शन पढ़ें और "अपने एलसीपी को Y मिलीसेकंड तक बेहतर बनाना" शामिल है.

कंटेपररी स्टडी

उपयोगकर्ता के रीयल-टाइम मॉनिटरिंग (आरयूएम) डेटा को देखते समय, आपको पेज लोड को एसएक्सजी और बिना एसएक्सजी के हिसाब से बांट देना चाहिए. ऐसा करते समय यह ज़रूरी है कि आपको दिखने वाले पेज लोड के सेट को सीमित किया जाए, ताकि एसएक्सजी का हिस्सा न होने वाला हिस्सा, एसएक्सजी के लिए ज़रूरी शर्तों को पूरा कर सके. ऐसा करने से पेज में होने वाले भेदभाव से बचा जा सकता है. ऐसा न करने पर, नीचे दी गई सभी चीज़ें सिर्फ़ बिना एसएक्सजी वाले पेज लोड में मौजूद होंगी, जिनमें मूल रूप से अलग एलसीपी हो सकती है:

• iOS डिवाइस: इन डिवाइसों का इस्तेमाल करने वाले उपयोगकर्ताओं के हार्डवेयर या नेटवर्क की स्पीड में अंतर की वजह से.
• पुराने Chromium ब्राउज़र: इन्हीं वजहों से.
• डेस्कटॉप डिवाइस: इन्हीं वजहों से या पेज लेआउट की वजह से "सबसे बड़े एलिमेंट" का दिखना अलग है चुनें.
• एक ही साइट के नेविगेशन (साइट में मौजूद लिंक पर आने वाले लोग): इसलिए, क्योंकि वे पिछले पेज लोड की कैश मेमोरी में सेव किए गए सबरिसॉर्स का फिर से इस्तेमाल कर सकते हैं.

Google Analytics (UA) में, "हिट" स्कोप के साथ दो कस्टम डाइमेंशन बनाएं. इनमें से एक का नाम "isSXG" होगा और एक "रेफ़रलकर्ता" नाम दिया गया है. (पहले से मौजूद "सोर्स" डाइमेंशन में सेशन का स्कोप शामिल है, इसलिए यह उसी साइट वाले नेविगेशन को बाहर नहीं रखता.)

"एसएक्सजी काउंटरफ़ैक्चुअल" नाम से कस्टम सेगमेंट बनाएं जिन्हें नीचे दिए गए फ़िल्टर से AND जोड़ा गया है:

• referrer की शुरुआत https://www.google. से होती है
• Browser, Chrome से पूरी तरह मेल खाता है
• Browser वर्शन, रेगुलर एक्सप्रेशन ^(9[8-9]|[0-9]{3}) से मेल खाता है
• isSXG, false से पूरी तरह मेल खाता है

"SXG" नाम के इस सेगमेंट की एक कॉपी बनाएं. इसमें सिर्फ़ true से पूरी तरह मेल खाने वाला isSXG शामिल नहीं है.

अपने साइट टेंप्लेट में, Google Analytics स्निपेट के ऊपर, इस स्निपेट को जोड़ें. यह एक स्पेशल सिंटैक्स है, जो एसएक्सजी जनरेट करते समय, ASX की वैल्यू false से बदलकर true हो जाएगी:

<script data-issxg-var>window.isSXG=false</script>

एलसीपी रिकॉर्ड करने के लिए, सुझाव के मुताबिक अपनी Google Analytics रिपोर्टिंग स्क्रिप्ट को पसंद के मुताबिक बनाएं. अगर आपने gtag.js का इस्तेमाल किया है, तो कस्टम डाइमेंशन सेट करने के लिए, 'config' कमांड में बदलाव करें ('dimension1' और 'dimension2' को उन नामों से बदलें जिनका इस्तेमाल Google Analytics करता है):

gtag('config', 'YOUR_TRACKING_ID', {
  'dimension1': String(isSXG),
  'dimension2': document.referrer,
});

अगर analytics.js का इस्तेमाल किया जा रहा है, तो 'create' कमांड को यहां दिए गए दस्तावेज़ के तौर पर बदलें.

डेटा इकट्ठा होने में कुछ दिन लग सकते हैं. इसके बाद, Google Analytics इवेंट रिपोर्ट पर जाएं और एसएक्सजी सेगमेंट के लिए ड्रिल-डाउन जोड़ें. इसमें X दर्ज होना चाहिए, क्योंकि "SXG, पेज व्यू के X% पर असर डालते हैं":

आखिर में, वेब की परफ़ॉर्मेंस की जानकारी देने वाली रिपोर्ट पर जाएं. इसके बाद, "सेगमेंट चुनें" और फिर "एसएक्सजी काउंटरफ़ैक्चुअल" चुनें और "एसएक्सजी".

"सबमिट करें" पर क्लिक करने के बाद, आपको दोनों सेगमेंट के लिए एलसीपी डिस्ट्रिब्यूशन दिखेगा. इसमें Y मिलीसेकंड तक, Y मिलीसेकंड तक अपने एलसीपी को बेहतर बनाने के लिए Y होना चाहिए:

चेतावनियां

ऊपर दिए गए सभी फ़िल्टर लागू करने के बाद, एसएक्सजी काउंटरफ़ैक्चुअल पेज लोड में ये चीज़ें शामिल होनी चाहिए:

• कैश मेमोरी में सेव नहीं होना: अगर Google एसएक्सजी कैश में किसी यूआरएल के लिए, एसएक्सजी की नई कॉपी नहीं है, तो वह आपकी साइट पर मूल यूआरएल पर रीडायरेक्ट हो जाएगा.
• अन्य तरह के नतीजे: फ़िलहाल, Google Search सिर्फ़ सामान्य वेब नतीजों और कुछ अन्य तरह के नतीजों के लिए एसएक्सजी के साथ काम करता है. चुनिंदा स्निपेट और टॉप स्टोरीज़ कैरसेल जैसे दूसरे चैनलों को आपकी साइट के ओरिजनल यूआरएल से लिंक किया जाएगा.
• ज़रूरी शर्तें पूरी न करने वाले यूआरएल: अगर आपकी साइट के कुछ पेज, एसएक्सजी की ज़रूरी शर्तें पूरी नहीं करते (उदाहरण के लिए, क्योंकि उन्हें कैश मेमोरी में सेव नहीं किया जा सकता), तो वे इस सेट में दिख सकते हैं.

एसएक्सजी पेज लोड और ऊपर दिए गए बिना एसएक्सजी पेज लोड के सेट में कुछ फ़र्क़ हो सकता है. हालांकि, मौजूदा समय में किए जाने वाले स्टडी सेक्शन में ऊपर बताए गए तरीके से किए गए फ़र्क़ की तुलना में, इसका साइज़ कम होना चाहिए. उदाहरण के लिए, हो सकता है कि आपके कैश न किए जा सकने वाले पेज, कैश मेमोरी में सेव किए जा सकने वाले पेजों की तुलना में धीमे या ज़्यादा तेज़ हों. अगर आपको लगता है कि किसी समस्या की वजह से ऐसा हो सकता है, तो एसएक्सजी की ज़रूरी शर्तें पूरी करने वाले किसी यूआरएल तक सीमित डेटा का इस्तेमाल करें. इससे आपको यह पता चलेगा कि इसके नतीजे पूरी स्टडी से मेल खाते हैं या नहीं.

अगर आपकी साइट में कुछ एएमपी पेज हैं, तो एसएक्सजी को चालू करने से शायद उन पर परफ़ॉर्मेंस में सुधार नहीं दिखेंगे. इसकी वजह यह है कि इन पेजों को Google Search से पहले ही प्रीफ़ेच किया जा सकता है. ऐसे पेजों को बाहर रखने के लिए, "ज़ूम इन करें" को और बेहतर बनाने के लिए, फ़िल्टर जोड़ें के बारे में जानकारी मिलेगी.

आखिर में, चुने गए सभी पक्षपातों को ठीक करते हुए भी, एक जोखिम यह है कि सर्वाइवरशिप बायस, आरयूएम के आंकड़ों में गिरावट की तरह दिखता है. यह लेख उस जोखिम की अच्छी तरह से व्याख्या करता है और ऐसा होने का पता लगाने के लिए परित्याग मेट्रिक को देखने का सुझाव देता है.

पढ़ाई से पहले या बाद में

मौजूदा स्टडी से मिले नतीजों की पुष्टि करने के लिए, एसएक्सजी को चालू करने से पहले और बाद में एलसीपी की तुलना करना मददगार साबित हो सकता है. ऊपर बताए गए संभावित पक्षपात को खत्म करने के लिए, एसएक्सजी पेज व्यू तक सीमित न करें. इसके बजाय, एसएक्सजी की ज़रूरी शर्तें पूरी करने वाले नतीजों को देखें—ऊपर दी गई सेगमेंट की परिभाषाएं, लेकिन isSXG कंस्ट्रेंट के बिना.

ध्यान दें कि Google Search को आपकी साइट के सभी पेजों को फिर से क्रॉल करने में कई हफ़्ते लग सकते हैं. इससे यह पता चलता है कि उनके लिए एसएक्सजी की सुविधा चालू है या नहीं. इन हफ़्तों में, कुछ अन्य पक्षपात भी हो सकते हैं जो:

• ब्राउज़र की नई रिलीज़ या उपयोगकर्ताओं की पहुंच में सुधार हार्डवेयर की मदद से, पेज लोड होने की स्पीड तेज़ हो सकती है.
• छुट्टियों जैसी किसी बड़ी घटना की वजह से, सामान्य से कम ट्रैफ़िक मिल सकता है.

ऊपर दी गई स्टडी की पुष्टि करने के लिए, पहले और बाद के कुल 75वें पर्सेंटाइल एलसीपी पर नज़र डालना भी मददगार होता है. जनसंख्या के किसी सबसेट के बारे में जानने से, यह ज़रूरी नहीं है कि हमें कुल जनसंख्या के बारे में पता चले. उदाहरण के लिए, मान लें कि एसएक्सजी ने 10% पेज लोड को 800 मि॰से॰ तक बेहतर बनाया है.

• अगर ये पहले से ही 10% तेज़ी से पेज लोड होने वाले पेज थे, तो इसका 75वें पर्सेंटाइल पर कोई असर नहीं पड़ेगा.
• अगर वे सबसे धीमे पेज लोड थे, लेकिन शुरुआत में वे 75वें पर्सेंटाइल एलसीपी की तुलना में 800 मि॰से॰ से ज़्यादा धीमे थे, तो इसका 75वें पर्सेंटाइल पर कोई असर नहीं पड़ेगा.

ये गंभीर उदाहरण हैं. ऐसा हो सकता है कि इन उदाहरणों से असलियत न दिखे. हालांकि, हमें उम्मीद है कि ये समस्याएं साफ़ तौर पर समझाई जा सकती हैं. व्यावहारिक तौर पर, यह संभावना है कि एसएक्सजी ज़्यादातर साइटों के 75वें पर्सेंटाइल पर असर डाले. क्रॉस-साइट नेविगेशन की स्पीड कम होती है और प्रीफ़ेच करने की प्रोसेस में काफ़ी सुधार होते हैं.

कुछ यूआरएल ऑप्ट-आउट करें

एसएक्सजी की परफ़ॉर्मेंस की तुलना करने का एक तरीका यह है कि आप अपनी साइट पर यूआरएल के कुछ सबसेट के लिए एसएक्सजी को बंद कर दें. उदाहरण के लिए, Cloudflare ASX को एसएक्सजी जनरेट करने से रोकने के लिए, CDN-Cache-Control: no-store हेडर सेट किया जा सकता है. मेरा सुझाव है कि ऐसा न करें.

इसमें, अन्य स्टडी के तरीकों की तुलना में, डेटा को चुनने से जुड़े पूर्वाग्रह की ज़्यादा संभावना होती है. उदाहरण के लिए, कंट्रोल ग्रुप या एक्सपेरिमेंट ग्रुप में आपकी साइट के होम पेज या उसी तरह के किसी लोकप्रिय यूआरएल को चुने जाने पर, यह बहुत असर डाल सकता है.

होल्डबैक स्टडी

प्रभाव को मापने का सबसे अच्छा तरीका यह है कि आप एक होल्डबैक स्टडी करें. माफ़ करें, फ़िलहाल इस तरह की जांच नहीं की जा सकती. हम आने वाले समय में, इस तरह की जांच के लिए सहायता उपलब्ध कराने के बारे में सोच रहे हैं.

होल्डबैक स्टडी में ये प्रॉपर्टी शामिल हैं:

• एक्सपेरिमेंट ग्रुप में, पेज व्यू के कुछ ऐसे रैंडम हिस्से जो एसएक्सजी हो सकते हैं, उन्हें "होल्ड बैक" के तौर पर दिखाया जाता है. साथ ही, इन्हें गैर-एसएक्सजी के तौर पर दिखाया जाता है. यह "Apples-to-apples" की अनुमति देता है मिलते-जुलते उपयोगकर्ताओं, डिवाइसों, स्थितियों, और पेजों के बीच तुलना.
• रोके गए पेज व्यू (यानी काउंटरफ़ैक्चुअल) को Analytics में उसी तरह से लेबल किया जाता है. इससे "ज़ूम-इन" करने की अनुमति मिलती है डेटा का एक व्यू है, जहां हम कंट्रोल में एसएक्सजी पेज लोड की तुलना, प्रयोग में एसएक्सजी काउंटरफ़ैक्चुअल से कर सकते हैं. इससे, उन दूसरे पेजों से आने वाला शोर कम हो जाता है जिन पर एसएक्सजी प्रीफ़ेच का असर नहीं होता.

यह विकल्प चुनने से जुड़े पक्षपात के ऊपर बताए गए संभावित सोर्स को खत्म कर देगा. हालांकि, इससे एलसीपी सर्वाइवरशिप बायस का खतरा खत्म नहीं होगा. इन दोनों प्रॉपर्टी को चालू करने के लिए, ब्राउज़र या रेफ़रर की ज़रूरत होती है.

नतीजा

वाह! यह बहुत बड़ी बात थी. उम्मीद है कि इससे लैब टेस्ट में एसएक्सजी की परफ़ॉर्मेंस को टेस्ट करने, लैब टेस्ट की मदद से फ़ीडबैक लूप में परफ़ॉर्मेंस को ऑप्टिमाइज़ करने, और असल में इसकी परफ़ॉर्मेंस को मेज़र करने के तरीके की पूरी जानकारी मिलती है. इन सभी को एक साथ रखने से, आपको एसएक्सजी का ज़्यादा से ज़्यादा फ़ायदा पाने में मदद मिलती है. साथ ही, यह भी पक्का किया जा सकता है कि उनसे आपकी साइट और आपके उपयोगकर्ताओं को फ़ायदा हो रहा है.

अगर एसएक्सजी परफ़ॉर्मेंस को कैप्चर करने के बारे में आपके पास कोई और सलाह है, तो कृपया हमें बताएं! अपने सुझाए गए सुधारों के साथ developer.chrome.com के ख़िलाफ़ गड़बड़ी की शिकायत करें.

साइन किए गए एक्सचेंज के बारे में ज़्यादा जानकारी के लिए, web.dev दस्तावेज़ और Google Search के दस्तावेज़ देखें.