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

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

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 और संसाधन का इस्तेमाल करने वाले असल एचटीएमएल टैग के बीच हैश या वर्शन यूआरएल के मैच न होने की संभावना ज़्यादा होती है.

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

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 'ठीक है' पर क्लिक करें. पुराने सिस्टम के साथ काम करने की सुविधा के लिए, आखिरी रिस्पॉन्स में 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 शुरुआती हिंट भी काम करते हैं और Link हेडर, दस्तावेज़ के संसाधनों पर देखे जा सकते हैं:

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

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

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

सर्वर सहायता

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

• Apache: mod_http2 का इस्तेमाल करके काम करता है.
• H2O: इस्तेमाल किया जा सकता है.
• NGINX: एक्सपेरिमेंट वाला मॉड्यूल.
• नोड: http और http2 के लिए 18.11.0 से काम करता है

'शुरुआती हिंट' सुविधा को आसानी से चालू करें

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

• Cloudflare पर शुरुआती हिंट
• तेज़ दिशा में शुरुआती हिंट.
• अकामाई में शुरुआती हिंट.

शुरुआती हिंट की सुविधा का इस्तेमाल न करने वाले क्लाइंट को होने वाली समस्याओं से कैसे बचें

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

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

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

बेहतर पैटर्न

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

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

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

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

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

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

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

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

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

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

H2/पुश से संबंध

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

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

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