जानें कि आपका सर्वर, ज़रूरी सब-रिसॉर्स के बारे में ब्राउज़र को कैसे संकेत भेज सकता है.
रिलीज़ से पहले मिलने वाले हिंट क्या हैं?
समय के साथ वेबसाइटें ज़्यादा बेहतर हो गई हैं. इसलिए, यह कोई असामान्य बात नहीं है कि अनुरोध किए गए पेज का एचटीएमएल जनरेट करने के लिए, सर्वर को कुछ मुश्किल काम करने पड़ें. जैसे, डेटाबेस को ऐक्सेस करना या ओरिजिन सर्वर को ऐक्सेस करने वाले सीडीएन. माफ़ करें, लेकिन इस "सर्वर थिंक-टाइम" की वजह से, ब्राउज़र के पेज को रेंडर करने में ज़्यादा समय लगता है. असल में, सर्वर को जवाब तैयार करने में जितना समय लगता है, उतने समय तक कनेक्शन बंद रहता है.
रिस्पॉन्स के बारे में पहले से जानकारी देने वाला एचटीटीपी स्टेटस कोड (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 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 से काम करता है
आसानी से रिलीज़ से पहले के सुझावों की सुविधा चालू करना
अगर इनमें से किसी सीडीएन या प्लैटफ़ॉर्म का इस्तेमाल किया जा रहा है, तो हो सकता है कि आपको रिडायरेक्ट के लिए रिमाइंडर की सुविधा को मैन्युअल तरीके से लागू करने की ज़रूरत न पड़े. यह जानने के लिए कि आपके सलूशन प्रोवाइडर का सलूशन, रिकॉर्डिंग शुरू होने से पहले मिलने वाले सुझावों के साथ काम करता है या नहीं, उसके ऑनलाइन दस्तावेज़ देखें. इसके अलावा, यहां दी गई सूची में भी इस बारे में जानकारी मिल सकती है. हालांकि, इसमें सभी सलूशन प्रोवाइडर शामिल नहीं हैं:
उन क्लाइंट के लिए समस्याओं से बचने का तरीका जो रिकॉर्डिंग शुरू होने से पहले के संकेत की सुविधा के साथ काम नहीं करते
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/पुश के साथ संबंध
अगर आपको एचटीटीपी 2/पुश की सुविधा के बारे में पता है, तो हो सकता है कि आप सोचें कि रिलीज़ से पहले के संकेत, इस सुविधा से कैसे अलग हैं. रिस्पॉन्स के साथ सब-रिसॉर्स भेजने के लिए, एचटीटीपी/2/पुश का इस्तेमाल करने पर, ब्राउज़र को क्रिटिकल सब-रिसॉर्स फ़ेच करने के लिए राउंड ट्रिप की ज़रूरत नहीं होती. हालांकि, रिस्पॉन्स के साथ सब-रिसॉर्स भेजने के लिए, रिलीज़ होने से पहले के संकेत का इस्तेमाल करने पर, ब्राउज़र को क्रिटिकल सब-रिसॉर्स फ़ेच करने के लिए राउंड ट्रिप की ज़रूरत होती है. यह सुविधा काफ़ी शानदार लगती है, लेकिन इससे स्ट्रक्चर में एक अहम समस्या आती है: एचटीटीपी 2/पुश की मदद से, ब्राउज़र में पहले से मौजूद सब-रिसॉर्स को पुश करने से रोकना काफ़ी मुश्किल था. इस "ओवर-पुशिंग" इफ़ेक्ट की वजह से, नेटवर्क बैंडविड्थ का इस्तेमाल कम असरदार तरीके से किया गया. इससे परफ़ॉर्मेंस से जुड़े फ़ायदों पर काफ़ी असर पड़ा. कुल मिलाकर, Chrome के डेटा से पता चला है कि एचटीटीपी 2/पुश, असल में पूरे वेब की परफ़ॉर्मेंस के लिए बुरा था.
इसके उलट, रिस्पॉन्स से पहले मिलने वाले हिंट की सुविधा, प्रैक्टिस में बेहतर परफ़ॉर्म करती है. इसकी वजह यह है कि इसमें शुरुआती जवाब भेजने की सुविधा के साथ-साथ हिंट भी शामिल होते हैं. इन हिंट की मदद से, ब्राउज़र को वह डेटा फ़ेच करने या उससे कनेक्ट करने की सुविधा मिलती है जिसकी उसे ज़रूरत होती है. हालांकि, रिडायरेक्ट करने के उन सभी तरीकों के लिए रिडायरेक्ट करने से पहले सूचनाएं भेजने की सुविधा का इस्तेमाल नहीं किया जा सकता जिन्हें एचटीटीपी 2/पुश सिद्धांत के हिसाब से ठीक किया जा सकता है. हालांकि, हमारा मानना है कि नेविगेशन को तेज़ करने के लिए, रिडायरेक्ट करने से पहले सूचनाएं भेजने की सुविधा एक ज़्यादा काम का तरीका है.
थंबनेल इमेज, पियरे बामिन की है.