कंप्रेशन डिक्शनरी की मदद से, Google Search को बेहतर बनाना

Carlos Mateo Muñoz

Barry Pollard

पब्लिश किया गया: 14 मई, 2025

कंप्रेसन डिक्शनरी ट्रांसपोर्ट एक नया स्टैंडर्ड है. इसकी मदद से, हम अलग-अलग अनुरोधों में दोहराए गए कॉन्टेंट को कंप्रेस कर सकते हैं. इसे साल 2024 के आखिर में, Chrome 130 में रिलीज़ किया गया था. Google Search ने इस नई टेक्नोलॉजी को अपनाया है और इसमें काफ़ी सुधार हुए हैं.

अवसर

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

विज़ुअल तौर पर, खोज के नतीजों वाले ज़्यादातर पेज एक जैसे होते हैं. भले ही, खोज के लिए कोई भी शब्द डाला गया हो: सबसे ऊपर Google का लोगो, खोज बार, और कुछ कंट्रोल होते हैं. बीच में, खोज के टाइप के लिए कुछ टैब होते हैं. इसके बाद, बाईं ओर खोज के नतीजों की सूची होती है. इसमें उपयोगकर्ता की मदद के लिए, अलग-अलग विजेट होते हैं. साथ ही, दाईं ओर "इसके बारे में जानकारी" पैनल के साथ अतिरिक्त जानकारी होती है:

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

वेब पर कंप्रेस करना

वेब के लिए, कंप्रेस करने की तकनीक का काफ़ी इस्तेमाल किया जाता है. gzip या Brotli या Zstandard जैसे नए एल्गोरिदम का इस्तेमाल करके रिसॉर्स को कंप्रेस करने से, फ़ाइल में डेटा दोहराए जाने से बचा जा सकता है. इससे, डेटा को सर्वर पर भेजने से पहले, ज़्यादा से ज़्यादा जानकारी को पैक किया जा सकता है. इसके बाद, ब्राउज़र ओरिजनल कॉन्टेंट को वापस लाने के लिए, कंप्रेस किए गए बाइट को अनपैक कर सकता है. इमेज के लिए, लॉस वाली कंप्रेसिंग से भी इसी तरह के फ़ायदे मिलते हैं. इसमें अतिरिक्त बाइट हटा दिए जाते हैं, जो उपयोगकर्ताओं को शायद अलग न लगें.

हाल ही तक, वेब पर कॉन्टेंट को सिर्फ़ संसाधनों में ही कंप्रेस किया जा सकता था. अलग-अलग संसाधनों और पेजों को कंप्रेस नहीं किया जा सकता. वेब इंजीनियर लंबे समय से इस समस्या को ठीक करने की कोशिश कर रहे थे.

कंप्रेशन डिक्शनरी ट्रांसपोर्ट की मदद से!

कंप्रेशन डिक्शनरी ट्रांसपोर्ट एक नया स्टैंडर्ड है. इसकी मदद से, शेयर की गई "डिक्शनरी" का इस्तेमाल करके, सभी संसाधनों को कंप्रेस किया जा सकता है. इससे, बाइट की सामान्य सीरीज़ को शेयर की गई डिक्शनरी के रेफ़रंस से बदला जा सकता है.

Brotli और Zstandard जैसे आधुनिक कंप्रेशन एल्गोरिदम, आम शब्दों की डिक्शनरी का इस्तेमाल करते हैं. इनकी मदद से, उन शब्दों को डिक्शनरी के छोटे रेफ़रंस से बदलकर, ज़्यादा कंप्रेशन किया जा सकता है. Brotli में, वेब की सामान्य शब्दावली की डिक्शनरी भी पहले से मौजूद होती है. कंप्रेशन डिक्शनरी ट्रांसपोर्ट, सर्वर और ब्राउज़र को कस्टम डिक्शनरी शेयर करने के तरीके उपलब्ध कराता है.

कस्टम डिक्शनरी, साइट पर पहले से इस्तेमाल किया जा रहा कोई संसाधन हो सकता है. उदाहरण के लिए, app.v2.js को डाउनलोड करते समय, app.v1.js को डिक्शनरी के तौर पर इस्तेमाल किया जा सकता है. इससे, सिर्फ़ अंतर को डाउनलोड किया जा सकता है. इसे आम तौर पर "डेल्टा-कंप्रेसन" कहा जाता है. इसके अलावा, <link rel="compression-dictionary"> टैग (या इसके बराबर का Link एचटीटीपी हेडर) का इस्तेमाल करके, अलग से एक डिक्शनरी रिसॉर्स तय किया जा सकता है.

इससे, ज़्यादा शेयर किए गए कॉन्टेंट या कोड वाले संसाधनों के डाउनलोड साइज़ को काफ़ी कम किया जा सकता है. जैसे, पहले बताए गए Search के नतीजों के पेज.

Google Search में कंप्रेशन डिक्शनरी का इस्तेमाल

Google Search की टीम, Search की परफ़ॉर्मेंस को लगातार बेहतर बनाने की कोशिश कर रही है. वे कंप्रेसन डिक्शनरी का इस्तेमाल करने वाले शुरुआती लोगों में से एक थे, क्योंकि उन्हें इस टेक्नोलॉजी की संभावनाएं दिखीं.

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

जब कोई क्लाइंट पहली बार खोज के नतीजों का पेज लोड करता है, तो सर्वर Link: एचटीटीपी हेडर का इस्तेमाल करके, डिक्शनरी का लिंक उपलब्ध कराता है. यह लिंक rel=compression-dictionary टाइप का होता है:

अगर क्लाइंट, Brotli डिक्शनरी कंप्रेस करने की सुविधा के साथ काम करता है, लेकिन उसने अब तक शेयर की गई डिक्शनरी को कैश मेमोरी में सेव नहीं किया है, तो ब्राउज़र, डिवाइस के इस्तेमाल में न होने के दौरान इस डिक्शनरी को डाउनलोड करता है. डिक्शनरी के रिस्पॉन्स में Use-As-Dictionary रिस्पॉन्स हेडर शामिल होता है. इससे ब्राउज़र को पता चलता है कि वह इस डिक्शनरी का इस्तेमाल किन रिसॉर्स के लिए कर सकता है:

डिक्शनरी, स्टैंडर्ड cache-control सेमेटिक्स का इस्तेमाल करेगी. साथ ही, वह उस हेडर में बताए गए नियमों से मैच करने वाले सभी संसाधनों के लिए उपलब्ध होगी. इस उदाहरण में, /search से शुरू होने वाले पेज.

आने वाले समय में खोज के नतीजों के पेज लोड होने के लिए, ब्राउज़र सर्वर को बता सकता है कि उसके पास Available-Dictionary एचटीटीपी अनुरोध हेडर का इस्तेमाल करके, डिक्शनरी है. पेज को फिर से लोड करने पर, यह कार्रवाई दिखती है:

लॉग सेव करें चेकबॉक्स चालू होने और फ़िल्टर करने पर, हम दोनों जवाबों की तुलना कर सकते हैं:

इस उदाहरण में, पहला अनुरोध 107 केबी का पूरा रिस्पॉन्स है और इसमें Brotli (br) कंप्रेसन का इस्तेमाल किया गया है. वहीं, रीलोड किए गए दूसरे अनुरोध का साइज़ करीब आधा है, यानी 60 केबी. इसमें डिक्शनरी-कंप्रेस्ड Brotli (dcb) कंप्रेसन का इस्तेमाल किया गया है. इस वजह से, डाउनलोड में लगने वाला समय कम हो जाता है.

शेयर की गई डिक्शनरी देखने के लिए, Chrome में chrome://net-internals/#sharedDictionary पेज पर जाएं. अगर आपको इस उदाहरण को फिर से शुरू से दोहराना है, तो डिक्शनरी मिटाएं.

नतीजे

यह बदलाव, 2025 की शुरुआत में Search के उपयोगकर्ताओं के लिए लॉन्च किया गया था. शुरुआत में, यह बदलाव Chrome के उपयोगकर्ताओं के लिए लॉन्च किया गया था. इससे, स्टैंडर्ड Brotli कंप्रेसन की तुलना में, Chrome का इस्तेमाल करने वाले सभी लोगों के लिए एचटीएमएल पेलोड का औसत साइज़ 23% तक कम हो गया. इस कुल औसत में, डिक्शनरी के बिना खोज करने वाले नए उपयोगकर्ताओं के नतीजे और डिक्शनरी की मदद से खोज के नतीजे, दोनों शामिल होते हैं. डिक्शनरी से कंप्रेस किए गए नतीजों के लिए, बचत और भी ज़्यादा होती है. जैसा कि हमने पिछले उदाहरण में देखा था, इसमें करीब 50% की बढ़ोतरी हुई थी.

इससे सबसे बड़े कॉन्टेंटफ़ुल पेंट (एलसीपी) में कुल 1.7% और ज़्यादा इंतज़ार वाले नेटवर्क पर 9% तक की बढ़ोतरी हुई. यह छोटी बात लग सकती है, लेकिन Google Search एक बेहतर तरीके से ऑप्टिमाइज़ की गई साइट है. इसलिए, इस तरह के फ़ायदे काफ़ी बड़े होते हैं. अन्य साइटों को इस टेक्नोलॉजी से ज़्यादा सुधार दिख सकते हैं.

इसे अपनी साइट पर आज़माएं!

कंप्रेशन डिक्शनरी ट्रांसपोर्ट की सुविधा, अब Chromium पर आधारित सभी ब्राउज़र (Chrome, Edge, Opera वगैरह) में इस्तेमाल के लिए तैयार है. यह एक बेहतर सुविधा है, जिसे इस्तेमाल न करने वाले ब्राउज़र अनदेखा कर देंगे. हालांकि, ज़्यादा ब्राउज़र के साथ काम करने पर, इसका फ़ायदा उन्हें भी मिल सकता है.

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

इस टेक्नोलॉजी के काम करने के तरीके और इसे अपनी साइट पर लागू करने के बारे में ज़्यादा जानने के लिए, MDN पर मौजूद गाइड देखें.

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