क्रॉस-साइट प्रीफ़ेचिंग की मदद से, सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) को तेज़ करना.
Android के लिए Chrome 103 से, Chrome में प्राइवेट प्रीफ़ेच प्रॉक्सी की सुविधा धीरे-धीरे रोल आउट की जाएगी. इससे Google Search और इस सुविधा में हिस्सा लेने वाली अन्य वेबसाइटों से आउटगोइंग नेविगेशन की स्पीड औसतन 30% तक बढ़ जाएगी. निजी प्रीफ़ेच प्रॉक्सी की इस सुविधा की मदद से, क्रॉस-ऑरिजिन कॉन्टेंट को प्रीफ़ेच किया जा सकता है. ऐसा तब तक किया जा सकता है, जब तक उपयोगकर्ता ने डेस्टिनेशन वेबसाइट पर नेविगेट नहीं किया है. इस दौरान, उपयोगकर्ता की जानकारी को डेस्टिनेशन वेबसाइट के साथ शेयर नहीं किया जाता.
यह सुविधा कैसे काम करती है, यह आपकी साइट के सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) को बेहतर बनाने में कैसे मदद कर सकती है या रेफ़रर वेबसाइटें, अलग-अलग साइट पर तेज़ी से नेविगेट करके अपने लक्ष्य हासिल करने में कैसे मदद कर सकती हैं, इनके बारे में जानने के लिए आगे पढ़ें.
प्राइवेट प्रीफ़ेच प्रॉक्सी कैसे काम करती है
सिक्योर कम्यूनिकेशन चैनल
यह सुविधा, CONNECT
प्रॉक्सी का इस्तेमाल करके, Chrome और प्रीफ़ेच किए जाने वाले कॉन्टेंट को होस्ट करने वाले सर्वर के बीच सुरक्षित कम्यूनिकेशन चैनल बनाती है. यह सुरक्षित कम्यूनिकेशन चैनल, प्रॉक्सी को किसी भी डेटा ट्रांसफ़र की जांच करने से रोकता है. ध्यान दें कि निजी प्रीफ़ेच प्रॉक्सी को सुरक्षित कम्यूनिकेशन चैनल बनाने के लिए, होस्ट का नाम ज़रूर दिखता है. हालांकि, उसे न तो पूरे यूआरएल दिखते हैं और न ही संसाधन.
साथ ही, सुरक्षित कम्यूनिकेशन चैनल पूरी तरह सुरक्षित (E2EE) होता है. इसलिए, मध्यस्थ होस्ट के नामों को नहीं देख सकते और न ही प्रीफ़ेच की गई साइटों के कॉन्टेंट को देख सकते हैं. आखिर में, प्रॉक्सी, मूल रूप से डेस्टिनेशन सर्वर को उपयोगकर्ता का आईपी पता देखने से रोकती है.
उपयोगकर्ता की पहचान से जुड़ी जानकारी को रोकना
पहले बताए गए नेटवर्क से जुड़े पहलुओं के अलावा, हमें सर्वर को यह भी रोकना होगा कि वे प्रीफ़ेच के समय, उपयोगकर्ता की पहचान करने के लिए उसके डिवाइस पर पहले से सेव की गई जानकारी का इस्तेमाल न करें. इसलिए, Chrome फ़िलहाल निजी प्रीफ़ेच प्रॉक्सी का इस्तेमाल सिर्फ़ उन वेबसाइटों के लिए करता है जिनके लिए उपयोगकर्ता के पास कोई कुकी या अन्य लोकल स्टेटस नहीं है. प्राइवेट प्रीफ़ेच प्रॉक्सी की मदद से किए गए, कॉन्टेंट को पहले से लोड करने के अनुरोधों पर ये पाबंदियां लागू होती हैं:
- कुकी: प्रीफ़ेच अनुरोधों को कुकी ले जाने की अनुमति नहीं है.
- अगर किसी संसाधन के लिए कोई कुकी है, तो Chrome बिना क्रेडेंशियल के फ़ेच करेगा, लेकिन रिस्पॉन्स का इस्तेमाल नहीं करेगा (बाद में कैशिंग सेक्शन देखें).
- हालांकि, पेज को पहले से लोड करने के अनुरोध के जवाबों में कुकी शामिल हो सकती हैं, लेकिन ये कुकी सिर्फ़ तब सेव होंगी, जब उपयोगकर्ता पहले से लोड किए गए पेज पर जाएगा.
- फ़िंगरप्रिंट: फ़िंगरप्रिंट के लिए इस्तेमाल किए जा सकने वाले अन्य प्लैटफ़ॉर्म में भी बदलाव किए गए हैं. उदाहरण के लिए, प्रीफ़ेच प्रॉक्सी से भेजे गए
User-Agent
हेडर में सिर्फ़ सीमित जानकारी होती है.
आने वाले समय में, हम निजी प्रीफ़ेच प्रॉक्सी को कुकी या लोकल स्टेटस वाले लिंक पर भी उपलब्ध कराएंगे. साथ ही, निजता से जुड़ी सुविधाओं को पहले जैसा ही बनाए रखेंगे. ज़्यादा जानकारी के लिए, आगे क्या करना है सेक्शन देखें.
कैश मेमोरी में सेव करना
Chrome, संसाधनों को पहले से लोड कर लेगा, भले ही वे पहले से कैश मेमोरी में मौजूद हों. हालांकि, इनमें ETag
या If-Modified-Since
जैसे शर्तों वाले हेडर नहीं होंगे. इनमें सर्वर से सेट की गई वैल्यू होती हैं, जिनका इस्तेमाल कुकी के बिना भी ट्रैकिंग के लिए किया जा सकता है. यह प्रीफ़ेचिंग, क्लाइंट की कैश मेमोरी की स्थिति को प्रीफ़ेच की गई वेबसाइट पर लीक होने से रोकने के लिए की जाती है. इसके अलावा, Chrome सिर्फ़ तब कैश मेमोरी में पहले से फ़ेच किया गया संसाधन सेव करेगा, जब उपयोगकर्ता पहले से फ़ेच की गई वेबसाइट पर जाना चाहेगा.
प्राइवेट प्रीफ़ेच प्रॉक्सी का इस्तेमाल शुरू करना
वेबसाइट के मालिकों के लिए
जिन लिंक के लिए उपयोगकर्ता के पास कोई कुकी या लोकल स्थिति नहीं होती है, उनके लिए निजी प्रीफ़ेच प्रॉक्सी का फ़ायदा पाना शुरू करने के लिए, वेबसाइट के मालिकों को कोई कार्रवाई करने की ज़रूरत नहीं है. हमारे प्रयोगों के आधार पर, ज़्यादातर वेबसाइटों के लिए यह एक महत्वपूर्ण अवसर है. इसके अलावा, पहली बार या कभी-कभी आने वाले लोगों को वेबसाइट तेज़ी से लोड होने का अनुभव देना हमेशा अच्छा होता है. पिछले एक्सपेरिमेंट से, हमें पता चला है कि पहले से लोड किए गए नेविगेशन पर, सबसे बड़े कॉन्टेंटफ़ुल पेंट की प्रोसेस 20% से 30% तक तेज़ हुई है.
आने वाले समय में, हम इस सुविधा को कुकी या लोकल स्टेटस वाले लिंक पर भी उपलब्ध कराएंगे. साथ ही, हम निजता से जुड़ी सुविधाओं को भी बनाए रखेंगे. कुकी से जुड़ी समस्या यह है कि इनका इस्तेमाल, उपयोगकर्ता अनुभव को ऐसे तरीके से बदलने के लिए किया जा सकता है जिसका अनुमान लगाना मुश्किल हो. इसलिए, कुकी वाले लिंक के लिए निजी प्रीफ़ेच प्रॉक्सी का फ़ायदा पाने के लिए, वेबसाइट के मालिकों को ऑप्ट इन करना होगा या अपनी साइट में बदलाव करना होगा.
खास तौर पर, प्रीफ़ेच अनुरोधों में क्रेडेंशियल नहीं होंगे. हालांकि, जब उपयोगकर्ता उस वेब पेज पर जाएगा, तो उसे कुकी और अन्य लोकल स्टेटस का ऐक्सेस मिल जाएगा. डेवलपर इस सुविधा का फ़ायदा उठाकर, कुकी या लोकल स्टोरेज के आधार पर, उपयोगकर्ताओं के हिसाब से कॉन्टेंट दिखाने की सुविधा और बदलावों को फिर से जोड़ सकते हैं. इसके अलावा, डेवलपर यह एलान भी कर सकते हैं कि वे कुछ रिसॉर्स को बिना कुकी के प्रीफ़ेच और इस्तेमाल करना बिलकुल सही मानते हैं (मतलब, जो किसी भी कुकी पर निर्भर नहीं होते). ज़्यादा जानने और हमें अपने प्लान के बारे में बताने के लिए, कृपया अगला कदम क्या है सेक्शन देखें.
जगह के आधार पर कॉन्टेंट या सेवाएं
अगर आपकी वेबसाइट, उपयोगकर्ता के आईपी पते के आधार पर अलग-अलग मार्केट में अलग-अलग तरीके से काम करती है, तो हो सकता है कि आपको यह पता न चले कि प्राइवेट प्रीफ़ेच प्रॉक्सी के प्रीफ़ेच अनुरोधों को कैसे मैनेज करें. उदाहरण के लिए, अलग-अलग कॉन्टेंट या चुनिंदा ऐक्सेस. यह जानना ज़रूरी है कि प्राइवेट प्रीफ़ेच प्रॉक्सी, दुनिया भर में मौजूद कई सर्वर की मदद से काम करती है. साथ ही, प्रॉक्सी का आईपी उस देश की जगह की जानकारी देगा जहां से उपयोगकर्ता ने प्रीफ़ेच शुरू किया था.
इसलिए, इसे ध्यान में रखते हुए हम आपको यह सुझाव देते हैं:
Sec-Purpose: Prefetch; anonymous-client-ip
एचटीटीपी हेडर की मौजूदगी से, प्राइवेट प्रीफ़ेच प्रॉक्सी से किए गए प्रीफ़ेच अनुरोधों की पहचान करें.- उस निजी प्रीफ़ेच प्रॉक्सी की भौगोलिक जगह की जानकारी देखें जिसने आईपी पते के ज़रिए अनुरोध किया था. रोल आउट किए गए देशों या इलाकों और उनसे जुड़े आईपी पतों की अप-टू-डेट सूची के लिए, यह संसाधन देखें.
- इस खास भौगोलिक स्थान से जुड़े बाज़ार के हिसाब से संसाधनों को उपलब्ध कराना.
ट्रैफिक कंट्रोल
पिछले प्रयोगों से हमें पता चला है कि इस सुविधा की वजह से, मुख्य संसाधनों (उदाहरण के लिए, एचटीएमएल दस्तावेज़) के लिए आम तौर पर 2% से कम अतिरिक्त अनुरोध मिलते हैं. हालांकि, अगर आपको सावधानी बरतनी है, तो ट्रैफ़िक से जुड़ी सलाह के फ़्रैक्शन फ़ील्ड का इस्तेमाल करके यह कंट्रोल किया जा सकता है कि निजी प्रीफ़ेच प्रॉक्सी को कितना ट्रैफ़िक पास करना चाहिए. शुरुआत में, 0.3 (यानी 30%) जैसे छोटे फ़्रैक्शन से शुरू किया जा सकता है. इसके बाद, /.well-known/traffic-advice
फ़ाइल में यह JSON जोड़कर, इसे धीरे-धीरे 1.0 (यानी 100%) तक बढ़ाया जा सकता है. इस फ़ाइल को application/trafficadvice+json
एमआईएम टाइप के साथ दिखाया जाना चाहिए:
[{
"user_agent": "prefetch-proxy",
"fraction": 0.3
}]
fraction
फ़ील्ड, 0.0 (बिल्कुल भी प्रीफ़ेच नहीं) और 1.0 (100% प्रीफ़ेच अनुरोध पूरे होते हैं) के बीच की कोई फ़्लोटिंग वैल्यू होती है.
इस कॉन्फ़िगरेशन की मदद से, इसे पूरी तरह से बंद भी किया जा सकता है:
[{
"user_agent": "prefetch-proxy",
"disallow": true
}]
/.well-known/traffic-advice
फ़ाइल को क्लाइंट के बजाय प्रॉक्सी से फ़ेच किया जाता है. साथ ही, इसे सामान्य एचटीटीपी कैश मेमोरी के सेमेंटेक्स के मुताबिक, प्रॉक्सी पर कैश मेमोरी में सेव किया जाता है. ज़्यादा सुविधाओं के लिए, जैसे कि अचानक बहुत ज़्यादा ट्रैफ़िक आने पर, 503 स्टेटस कोड के साथ प्रीफ़ेच अनुरोधों (Sec-Purpose: prefetch;anonymous-client-ip
) को कुछ समय के लिए अस्वीकार किया जा सकता है. इसके लिए, रिस्पॉन्स में Cache-Control: no-store
हेडर सेट करें. Retry-After
हेडर भी जोड़ा जा सकता है, ताकि Chrome को यह बताया जा सके कि पेज लोड होने से पहले अनुरोध करने की कोशिश फिर से करने से पहले, कितनी देर इंतज़ार करना है.
रेफ़रल देने वाली वेबसाइट के मालिकों के लिए
अगर आपकी वेबसाइट पर दूसरी वेबसाइटों के कई लिंक हैं, तो क्रॉस-ऑरिजिन नेविगेशन को तेज़ करने के लिए, प्राइवेट प्रीफ़ेच प्रॉक्सी की सुविधा का इस्तेमाल किया जा सकता है. आपको अपने पेजों में अनुमान के नियम जोड़ने होंगे, ताकि Chrome यह जान सके कि आपको किस पेज को निजी प्रीफ़ेच प्रॉक्सी के ज़रिए प्रीफ़ेच करना है. इसका एक आसान उदाहरण यहां दिया गया है:
<script type="speculationrules">
{
"prefetch": [
"source": "list",
"urls": ["https://example.com/index.html"],
"requires": ["anonymous-client-ip-when-cross-origin"]
]
}
</script>
आगे क्या करना है?
यह लॉन्च सिर्फ़ एक शुरुआत है. हमें उम्मीद है कि कम्यूनिटी की दिलचस्पी और सुझाव/राय/शिकायत के आधार पर, हम इस सुविधा को और बेहतर बना पाएंगे. उदाहरण के लिए, हमें इस बारे में सुझाव, राय या शिकायत भेजकर यह बताएं कि कुकी और स्थानीय स्थिति वाले लिंक को इस तरह कैसे बड़ा किया जाए कि डेवलपर को कम परेशानी हो. इसके अलावा, इस सुविधा को रेफ़रर वेबसाइटों के लिए ज़्यादा काम का बनाने के तरीकों के बारे में भी हमें बताएं.