अर्ली हिंट के साथ सर्वर थिंक-टाइम का इस्तेमाल करके, तेज़ी से पेज लोड होते हैं

जानें कि आपका सर्वर, ज़रूरी सब-रिसॉर्स के बारे में ब्राउज़र को कैसे संकेत भेज सकता है.

Kenji Baheux

Barry Pollard

रिलीज़ से पहले मिलने वाले हिंट क्या हैं?

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

शुरुआती हिंट एक एचटीटीपी स्टेटस कोड (103 Early Hints) है. इसका इस्तेमाल आखिरी रिस्पॉन्स से पहले शुरुआती एचटीटीपी रिस्पॉन्स भेजने के लिए किया जाता है. इससे सर्वर, मुख्य रिसॉर्स जनरेट करने के दौरान, ब्राउज़र को ज़रूरी सब-रिसॉर्स (उदाहरण के लिए, पेज के लिए स्टाइल शीट, ज़रूरी JavaScript) या उन ऑरिजिन के बारे में संकेत भेज सकता है जिनका इस्तेमाल पेज पर किया जा सकता है. ब्राउज़र, मुख्य रिसॉर्स के इंतज़ार के दौरान, कनेक्शन को वॉर्म अप करने और सब-रिसॉर्स का अनुरोध करने के लिए, उन हिंट का इस्तेमाल कर सकता है. दूसरे शब्दों में, रिकॉर्डिंग शुरू होने से पहले मिलने वाले संकेत, ब्राउज़र को "सर्वर के सोचने के समय" का फ़ायदा लेने में मदद करते हैं. इसके लिए, ब्राउज़र कुछ काम पहले ही कर लेता है, ताकि पेज तेज़ी से लोड हो सके.

कुछ मामलों में, सबसे बड़े कॉन्टेंटफ़ुल पेंट की परफ़ॉर्मेंस में सुधार, कई सौ मिलीसेकंड तक हो सकता है. यह सुधार Shopify और Cloudflare की ओर से देखा जा सकता है और एक सेकंड तक तेज़ी से हो सकता है, जैसा कि तुलना के पहले और बाद में दिखाया गया है:

की मदद से, टेस्ट वेबसाइट पर शुरुआती सुझावों की तुलना करने से पहले/बाद की इमेज

रिलीज़ से पहले मिलने वाले सुझावों का इस्तेमाल करने का तरीका

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

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

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

एचटीएमएल में इनका इस्तेमाल करते समय, आम तौर पर ऐसे रिसॉर्स preconnect या preload किए जाते हैं जिन्हें प्रीलोड स्कैनर एचटीएमएल में नहीं खोज पाएगा. उदाहरण के लिए, फ़ॉन्ट या बैकग्राउंड इमेज, जिन्हें बाद में खोजा जाएगा. रिस्पॉन्स के लिए शुरुआती संकेत देने की सुविधा के लिए, आपके पास एचटीएमएल नहीं होगा. इसलिए, हो सकता है कि आप preconnect अहम डोमेन या preload अहम रिसॉर्स पर जाएं. ऐसा इसलिए, क्योंकि हो सकता है कि एचटीएमएल में इनका पता पहले ही चलता हो. उदाहरण के लिए, main.css या app.js को पहले से लोड करना. इसके अलावा, सभी ब्राउज़र पर रिस्पॉन्स के लिए शुरुआती संकेत देने की सुविधा preload काम नहीं करती. ब्राउज़र के लिए सहायता देखें.

दूसरे चरण में, ऐसे संसाधनों या ऑरिजिन पर रिस्पॉन्स के लिए शुरुआती संकेत इस्तेमाल करने के जोखिम को कम किया जाता है जो शायद पुराने हो गए हों या जिनका इस्तेमाल मुख्य संसाधन अब न करता हो. उदाहरण के लिए, हो सकता है कि अक्सर अपडेट किए जाने वाले और वर्शन वाले संसाधन (उदाहरण के लिए, example.com/css/main.fa231e9c.css) सबसे सही विकल्प न हों. ध्यान दें कि यह समस्या, रिलीज़ से पहले मिलने वाले सुझावों के लिए ही नहीं है. यह किसी भी preload या preconnect पर लागू होती है, चाहे वे कहीं भी मौजूद हों. इस तरह की जानकारी को ऑटोमेशन या टेंप्लेट के ज़रिए बेहतर तरीके से मैनेज किया जा सकता है. उदाहरण के लिए, मैन्युअल प्रोसेस की वजह से, preload और संसाधन का इस्तेमाल करने वाले असली HTML टैग के बीच, हैश या वर्शन यूआरएल का मेल न खाने की संभावना ज़्यादा होती है.

उदाहरण के लिए, नीचे दिया गया फ़्लो देखें:

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]

सर्वर का अनुमान है कि main.abcd100.css की ज़रूरत होगी और सर्वर को शुरुआती हिंट का इस्तेमाल करके इसे पहले से लोड करने का सुझाव देता है:

103 Early Hints
Link: </main.abcd100.css>; rel=preload; as=style
[...]

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

200 OK
[...]
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.abcd105.css">

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

<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">

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

GET /main.html
Host: example.com
User-Agent: [....] Chrome/103.0.0.0 [...]
103 Early Hints
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script

कुछ देर बाद:

200 OK
Content-Length: 7531
Content-Type: text/html; charset=UTF-8
Content-encoding: br
Link: <https://fonts.google.com>; rel=preconnect
Link: </main.css>; rel=preload; as=style
Link: </common.js>; rel=preload; as=script
Link: </experimental.3eab3290.css>; rel=preload; as=style
<HTML>
<head>
   <title>Example</title>
   <link rel="stylesheet" href="/main.css">
   <link rel="stylesheet" href="/experimental.3eab3290.css">
   <script src="/common.js"></script>
   <link rel="preconnect" href="https://fonts.googleapis.com">

ब्राउज़र समर्थन

हालांकि, सभी मुख्य ब्राउज़र में 103 रिस्पॉन्स के लिए रिमाइंडर भेजने की सुविधा काम करती है, लेकिन हर ब्राउज़र के लिए रिमाइंडर के तौर पर भेजे जा सकने वाले डायरेक्टिव अलग-अलग होते हैं:

पहले से कनेक्ट करने की सुविधा:

वीडियो को पहले से लोड करने की सुविधा:

Chrome DevTools में 103 Early Hints की सुविधा भी है. साथ ही, दस्तावेज़ के संसाधनों पर Link हेडर देखे जा सकते हैं:

ध्यान दें, शुरुआती हिंट वाले संसाधनों का इस्तेमाल करने के लिए, DevTools में Disable cache पर सही का निशान नहीं लगाया जाना चाहिए. इसकी वजह यह है कि शुरुआती हिंट में ब्राउज़र की कैश मेमोरी का इस्तेमाल किया जाता है. पहले से लोड किए गए संसाधनों के लिए, शुरू करने वाला early-hints और साइज़ (Disk cache) के तौर पर दिखेगा:

इसके लिए, एचटीटीपीएस की जांच के लिए भरोसेमंद सर्टिफ़िकेट की भी ज़रूरत होती है.

Firefox के 126 वर्शन में, DevTools में साफ़ तौर पर 103 रिन्यूअल के लिए रिमाइंडर की सुविधा नहीं है. हालांकि, रिन्यूअल के लिए रिमाइंडर का इस्तेमाल करके लोड किए गए संसाधनों में एचटीटीपी हेडर की जानकारी नहीं दिखती. यह एक इंडिकेटर है कि वे संसाधन, रिन्यूअल के लिए रिमाइंडर का इस्तेमाल करके लोड किए गए थे.

सर्वर सहायता

यहां ओपन सोर्स सॉफ़्टवेयर के लोकप्रिय एचटीटीपी सर्वर सॉफ़्टवेयर में, रिस्पॉन्स के लिए जल्दी जानकारी देने की सुविधा के लेवल के बारे में खास जानकारी दी गई है:

• Apache: mod_http2 का इस्तेमाल करके, काम करता है.
• H2O: काम करता है.
• NGINX: प्रयोग के तौर पर उपलब्ध मॉड्यूल.
• Node: http और http2 के लिए, 18.11.0 से काम करता है

रिलीज़ होने से पहले सुझाव पाने की सुविधा को आसानी से चालू करना

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

• Cloudflare पर शुरुआती हिंट
• Fastly पर शुरुआती हिंट.
• Akamai पर शुरुआती हिंट.

उन क्लाइंट के लिए समस्याओं से बचने का तरीका जो रिकॉर्डिंग शुरू होने से पहले के संकेत की सुविधा के साथ काम नहीं करते

100 रेंज में जानकारी देने वाले एचटीटीपी रिस्पॉन्स, एचटीटीपी स्टैंडर्ड का हिस्सा हैं. हालांकि, कुछ पुराने क्लाइंट या बॉट को इनसे समस्या हो सकती है, क्योंकि 103 रिस्पॉन्स के लॉन्च से पहले, इनका इस्तेमाल सामान्य वेब ब्राउज़िंग के लिए शायद ही किया जाता था.

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

इसके अलावा, सुझावों को सिर्फ़ एचटीटीपी/2 या एचटीटीपी/3 कनेक्शन पर भेजने का सुझाव दिया जाता है. ज़्यादातर ब्राउज़र, उन्हें सिर्फ़ उन प्रोटोकॉल पर स्वीकार करेंगे.

ऐडवांस पैटर्न

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

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

मौजूदा सीमाएं

Chrome में लागू की गई शुरुआती हिंट की सीमाएं यहां दी गई हैं:

• यह सुविधा सिर्फ़ नेविगेशन के अनुरोधों के लिए उपलब्ध है. यह टॉप लेवल के दस्तावेज़ का मुख्य संसाधन है.
• सिर्फ़ preconnect और preload के साथ काम करता है. इसका मतलब है कि prefetch काम नहीं करता.
• शुरुआती हिंट के बाद आखिरी जवाब पर क्रॉस-ऑरिजिन रीडायरेक्ट की वजह से Chrome, शुरुआती हिंट का इस्तेमाल करके मिले संसाधनों और कनेक्शन को छोड़ देगा.
• रिस्पॉन्स के लिए ज़रूरी रिसॉर्स, रिस्पॉन्स मिलने से पहले लोड किए जा सकते हैं. इसके लिए, रिस्पॉन्स के लिए ज़रूरी रिसॉर्स को एचटीटीपी कैश मेमोरी में सेव किया जाता है. बाद में, पेज इन रिसॉर्स को कैश मेमोरी से वापस पा लेता है. इसलिए, सिर्फ़ कैश मेमोरी में सेव किए जा सकने वाले रिसॉर्स को, रिस्पॉन्स मिलने से पहले लोड किया जा सकता है. ऐसा न करने पर, रिसॉर्स को दो बार फ़ेच किया जाएगा. पहला बार रिस्पॉन्स मिलने से पहले और दूसरा बार दस्तावेज़ से. Chrome में, भरोसेमंद नहीं एचटीटीपीएस सर्टिफ़िकेट के लिए एचटीटीपी कैश मेमोरी बंद रहती है. भले ही, आपने पेज लोड करना जारी रखा हो.
• imagesrcset, imagesizes या media का इस्तेमाल करके, रिस्पॉन्सिव इमेज को पहले से लोड करने की सुविधा, एचटीटीपी <link> हेडर का इस्तेमाल करके काम नहीं करती. इसकी वजह यह है कि दस्तावेज़ बनने तक व्यूपोर्ट तय नहीं होता. इसका मतलब है कि रिस्पॉन्सिव इमेज को पहले से लोड करने के लिए, 103 शुरुआती हिंट का इस्तेमाल नहीं किया जा सकता. साथ ही, इसके लिए इस्तेमाल किए जाने पर गलत इमेज लोड हो सकती है. इस समस्या को बेहतर तरीके से मैनेज करने के सुझावों पर की गई चर्चा देखें.

अन्य ब्राउज़र की सीमाएं समान होती हैं और जैसा कि पहले बताया गया है, कुछ ब्राउज़र 103 शुरुआती हिंट को सिर्फ़ preconnect तक सीमित करते हैं.

आगे क्या करना है?

कम्यूनिटी की दिलचस्पी के आधार पर, हम इन सुविधाओं के साथ, रिलीज़ से पहले सुझाव देने की सुविधा को बेहतर बना सकते हैं:

• एचटीटीपी कैश के बजाय, मेमोरी कैश का इस्तेमाल करके, ऐसे रिसॉर्स के लिए रिस्पॉन्स के समय के बारे में पहले से जानकारी.
• सबरिसॉर्स के अनुरोध करने पर शुरुआती हिंट भेजे जाते हैं.
• iframe के मुख्य संसाधन के अनुरोधों पर भेजे गए शुरुआती संकेत.
• अर्ली हिंट में प्रीफ़ेच की सुविधा है.

हम आपके सुझाव का स्वागत करते हैं. इससे हमें यह तय करने में मदद मिलेगी कि किन पहलुओं को प्राथमिकता दी जाए और शुरुआती सुझावों को और कैसे बेहतर बनाया जाए.

H2/पुश के साथ संबंध

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

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

थंबनेल इमेज, पियरे बामिन की है.