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

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

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

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

इमेज, जिसमें सर्वर को पेज लोड करने और अन्य रिसॉर्स के लोड होने के बीच 200 मि॰से॰ का टाइम गैप दिखाया गया है.
शुरुआती हिंट के बिना: सर्वर पर सब कुछ ब्लॉक होता है, जो यह तय करता है कि मुख्य संसाधन का जवाब कैसे देना है.

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

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

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

दो साइटों की तुलना.
WebPageTest (Moto G4 - DSL) की मदद से एक टेस्ट वेबसाइट पर शुरुआती हिंट की तुलना करने से पहले/बाद में

शुरुआती हिंट इस्तेमाल करने का तरीका

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

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

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

आम तौर पर, इन्हें एचटीएमएल में इस्तेमाल करते समय, preconnect या preload ऐसे संसाधनों की ज़रूरत होती है जिन्हें Preload Scanner एचटीएमएल में नहीं खोज पाएगा. उदाहरण के लिए, ऐसे फ़ॉन्ट या बैकग्राउंड इमेज जिन्हें आम तौर पर, देर से खोजा जा सकता है. शुरुआती हिंट के लिए, आपके पास एचटीएमएल नहीं होगा. इसलिए, आपको इसे ज़रूरी डोमेन में 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">

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

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

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

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

ब्राउज़र सहायता

  • 103
  • 103
  • 120
  • 17

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

ब्राउज़र सहायता

  • 103
  • 103
  • 123
  • x

Chrome DevTools में 103 Early ब्रैंड की सुविधा भी मौजूद है.

सर्वर सहायता

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

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

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

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

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

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

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

बेहतर पैटर्न

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

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

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

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

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

अन्य ब्राउज़र की सीमाएं भी इसी तरह की होती हैं. साथ ही, कुछ ब्राउज़र 103 शुरुआती संकेतों को सिर्फ़ preconnect तक सीमित रखते हैं.

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

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

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

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

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

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

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

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