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

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

शुरुआती हिंट क्या है?

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

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

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

शुरुआती हिंट लागू करना

विषय के बारे में ज़्यादा गहराई से जानने से पहले, कृपया ध्यान दें कि अगर आपका सर्वर तुरंत 200 (या दूसरे आखिरी जवाब) भेज सकता है, तो शुरुआती हिंट इस्तेमाल नहीं किए जा सकते. इसके बजाय, मुख्य रिस्पॉन्स (Link rel एचटीटीपी हेडर) में या मुख्य रिस्पॉन्स (<link> एलिमेंट) में, सामान्य link rel=preload या link rel=preconnect का इस्तेमाल करें. जिन मामलों में आपके सर्वर को मुख्य जवाब जनरेट करने के लिए थोड़ा समय चाहिए, उनके लिए आगे पढ़ें!

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

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

दूसरे चरण में, ऐसे संसाधनों या ऑरिजिन पर शुरुआती संकेतों के इस्तेमाल के जोखिम को कम करना शामिल है जो शायद पुराने हो गए हैं या मुख्य संसाधन अब इस्तेमाल नहीं किए जा रहे हैं. ऐसा हो सकता है कि अक्सर अपडेट किए जाने वाले और कई वर्शन में अपडेट किए जाने वाले संसाधन (जैसे कि example.com/css/main.fa231e9c.css) आपके लिए सबसे सही विकल्प न हों. ध्यान दें कि यह समस्या शुरुआती संकेतों के लिए नहीं है. यह किसी भी लिंक rel=preload या rel=preconnect पर लागू होती है, जहां भी वे मौजूद हो सकते हैं. यह इस तरह की जानकारी है, जो ऑटोमेशन या टेंप्लेट के साथ सबसे सही तरीके से काम करती है. उदाहरण के लिए, मैन्युअल प्रोसेस की वजह से हो सकता है कि रिसॉर्स का इस्तेमाल करने वाले, link rel=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">

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

प्रीकनेक्ट सहायता:

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

सर्वर सहायता

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

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

रिलीज़ होने से पहले हिंट पाने की सुविधा, एक आसान तरीका है

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

• Cloudflare पर शुरुआती संकेत
• झटपट संकेत.
• अकामाई पर शुरुआती संकेत.

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

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

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

इसके अलावा, हमारी सलाह है कि रिलीज़ होने से पहले हिंट पाने की सुविधा, सिर्फ़ एचटीटीपी/2 या एचटीटीपी/3 कनेक्शन पर भेजें.

बेहतर पैटर्न

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

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

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

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

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

दूसरे ब्राउज़र की सीमाएं भी ऐसी ही हैं. वे 103 शुरुआती संकेतों को सिर्फ़ preconnect तक सीमित करते हैं.

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

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

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

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

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

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

इसके उलट, Early Prompts सबसे बेहतर परफ़ॉर्म करता है, क्योंकि इसमें संकेतों के साथ शुरुआती जवाब भेजने की सुविधा दी जाती है. इससे ब्राउज़र पर यह तय होता है कि उसे फ़ेच करने या उससे कनेक्ट करने की ज़िम्मेदारी ब्राउज़र पर है या नहीं. शुरुआती हिंट में इस्तेमाल के वे सभी उदाहरण नहीं दिए गए हैं जिनके बारे में HTTP2/Push, सिद्धांत के तौर पर पता लगा सकता है. हालांकि, हमारा मानना है कि Early बचे हुए, नेविगेशन की रफ़्तार बढ़ाने के लिए ज़्यादा कारगर समाधान हैं.

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