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

साइन किए गए एक्सचेंज को बेहतर बनाने के लिए, उन्हें मेज़र और ऑप्टिमाइज़ करने का तरीका

Devin Mullins

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

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

ध्यान दें: पहले, इस पोस्ट में 6s से 0.9s तक का सुधार दिखाया गया था. यह सच है, लेकिन उस समय साइट की जांच बहुत ही धीमी थी. फिर भी, यह ज़्यादा सबरिसॉर्स, धीमे सर्वर या धीमे कनेक्शन वाले कनेक्शन वाले उपयोगकर्ताओं के उदाहरण के तौर पर काम कर सकता है.

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

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

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

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

शुरुआती जानकारी

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

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

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

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

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

आंकड़े देखें

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

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

एसएक्सजी के बिना टेस्ट जनरेट करने के लिए, यहां दिया गया तरीका अपनाएं:

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

ऊपर दिए गए तरीके का इस्तेमाल करके, एसएक्सजी के साथ टेस्ट जनरेट करें. हालांकि, टेस्ट शुरू करें पर क्लिक करने से पहले, स्क्रिप्ट टैब पर जाएं और यहां दी गई 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

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

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

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

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

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

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

डीबग

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

कॉन्टेंट पब्लिश करना

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

ध्यान दें: एसएक्सजी, एसएक्सजी की सुविधा वाले क्रॉलर के लिए होते हैं, ताकि प्रीफ़ेच करने की सुविधा चालू की जा सके. जब उपयोगकर्ता सीधे आपकी साइट पर आते हैं, तो आपको उन्हें एसएक्सजी नहीं देने चाहिए, क्योंकि उन्हें प्रीफ़ेच नहीं किया जाएगा—ऐसा करने से सिर्फ़ ओवरहेड बढ़ते हैं. Cloudflare ASX, कॉन्टेंट से जुड़ी नेगोशिएशन अपने-आप करता है.

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

ध्यान दें: आने वाले समय में, Vary: Cookie का इस्तेमाल करने वाले पेज, एसएक्सजी के साथ काम करेंगे. इसके लिए, उन लोगों को ही आपकी साइट पर आने वाले लोगों को दिखाया जाएगा जिनके पास कुकी नहीं हैं. यह सुविधा Chromium में लागू होती है. साथ ही, पूरी तरह रोल आउट होने के बाद, Google Search में इसे चालू कर दिया जाता है.

इसके अलावा, 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 एक्सटेंशन, सभी सही के निशान दिखाता है (✅), तो आपके पास ऐसा एसएक्सजी है जो लोगों को दिया जा सकता है! अपने वेब पेज को ऑप्टिमाइज़ करने का तरीका जानने के लिए आगे पढ़ें. इससे आपको एसएक्सजी से एलसीपी में सबसे ज़्यादा सुधार करने में मदद मिलेगी.

max-age

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

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

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

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

ध्यान दें: हम आने वाले समय में, इस समस्या को आसानी से मैनेज करने के लिए कैश मेमोरी को पूरी तरह मिटाने वाला एपीआई जोड़ने पर काम कर रहे हैं. इसकी सूचना webपैकेजिंग-एनाउंस पर दी जाएगी.

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

एक बार, प्रीफ़ेच किए गए एसएक्सजी का इस्तेमाल करते समय, मुझे एलसीपी में बढ़ोतरी दिखी थी. मैंने 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 सबरिसॉर्स पहले से लोड किए जा सकते हैं. साथ ही, एएसएक्स पक्का करता है कि यह सीमा पार न हुई हो. हालांकि, सबरिसॉर्स में कई सारे प्रीलोड जोड़ने का जोखिम रहता है. क्रॉस-साइट ट्रैकिंग को रोकने के लिए, ब्राउज़र पहले से लोड किए गए सबरिसॉर्स का इस्तेमाल सिर्फ़ तब करेगा, जब सभी रिसोर्स को फ़ेच करने की प्रोसेस पूरी हो गई हो. सबरिसॉर्स की संख्या जितनी ज़्यादा होगी, उपयोगकर्ता के आपके पेज पर क्लिक करने से पहले ही उन सभी में प्रीफ़ेच होने की संभावना उतनी ही कम होगी.

ध्यान दें: फ़िलहाल, ASX सिर्फ़ एक ही ऑरिजिन (पहले पक्ष) के सबरिसॉर्स के लिए प्रीफ़ेच की सुविधा देता है. अगर आपके पास तीसरे पक्ष की सबरिसॉर्स प्रोवाइडर के बारे में जानकारी है, जो एसएक्सजी के साथ काम करती हैं, तो इस गड़बड़ी के बारे में हमें बताएं, ताकि हम क्रॉस-ऑरिजिन सहायता को प्राथमिकता दे सकें.

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

दूरी मापें

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

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

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

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

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

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

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

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

ध्यान दें: Google Search उन कॉन्टेक्स्ट को बढ़ाने की योजना बना रहा है जिनमें एसएक्सजी प्रीफ़ेच हो सकता है. इसमें डेस्कटॉप ओएस वगैरह शामिल हैं. इसमें समय के साथ X% की बढ़ोतरी हो सकती है. इसका मतलब यह भी है कि आपको इस बदलाव के हिसाब से अपनी मेट्रिक को अपडेट करना है. अगर ऐसा होता है, तो उसका एलान webpackaging-anounce पर किया जाना चाहिए.

"पेज व्यू के X%" को मापने और "उनके एलसीपी को Y मिलीसेकंड में सुधार करने" का तरीका जानने के लिए, कृपया साथ ही के समय की स्टडी वाला सेक्शन पढ़ें.

आधुनिक अध्ययन

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

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

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

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

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

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

अपने साइट टेंप्लेट में, 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% पर असर डालने वाले एसएक्सजी" के लिए, इसे X से भरना चाहिए:

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

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

ध्यान दें

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

नतीजा

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

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

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