टेक्स्ट-आधारित एसेट की एन्कोडिंग और ट्रांसफ़र आकार को ऑप्टिमाइज़ करें

Ilya Grigorik

Jeremy Wagner

पेज लोड होने की स्पीड को बेहतर बनाने के लिए, गैर-ज़रूरी रिसॉर्स को डाउनलोड करने से बचें. इसके अलावा, बाकी रिसॉर्स को ऑप्टिमाइज़ और कंप्रेस करके, डाउनलोड किए जाने वाले डेटा का साइज़ कम करें.

डेटा कंप्रेस करने की बुनियादी जानकारी

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

बेहतरीन परफ़ॉर्मेंस देने के लिए, इन सभी तकनीकों को एक साथ इस्तेमाल करना ज़रूरी है:

• कंप्रेशन, कम बिट का इस्तेमाल करके जानकारी को कोड में बदलने की प्रोसेस है.
• गैर-ज़रूरी डेटा हटाने से हमेशा सबसे अच्छे नतीजे मिलते हैं.
• कंप्रेशन की कई अलग-अलग तकनीकें और एल्गोरिदम हैं.
• वीडियो को सबसे बेहतर तरीके से कंप्रेस करने के लिए, आपको कई तकनीकों की ज़रूरत होगी.

डेटा के साइज़ को कम करने की प्रोसेस को डेटा कंप्रेस करना कहते हैं. कई लोगों ने एल्गोरिदम, तकनीकों, और ऑप्टिमाइज़ेशन में योगदान दिया है, ताकि कंप्रेशन अनुपात, कंप्रेशन की स्पीड, और अलग-अलग कंप्रेशन एल्गोरिदम के लिए ज़रूरी मेमोरी को बेहतर बनाया जा सके.

डेटा कंप्रेस करने के बारे में पूरी जानकारी देना, इस गाइड के दायरे से बाहर है. हालांकि, यह समझना ज़रूरी है कि कंप्रेस करने की प्रोसेस कैसे काम करती है. साथ ही, उन तकनीकों के बारे में जानना भी ज़रूरी है जिनका इस्तेमाल करके, अपने पेजों के लिए ज़रूरी अलग-अलग ऐसेट का साइज़ कम किया जा सकता है.

इन तकनीकों के मुख्य सिद्धांतों को समझाने के लिए, एक आसान टेक्स्ट मैसेज फ़ॉर्मैट को ऑप्टिमाइज़ करने की प्रोसेस पर विचार करें. इस फ़ॉर्मैट को सिर्फ़ इस उदाहरण के लिए बनाया गया है:

# Below is a secret message, which consists of a set of headers in
# key-value format followed by a newline and the encrypted message.
format: secret-cipher
date: 08/25/16
AAAZZBBBBEEEMMM EEETTTAAA

1. मैसेज में, मनमुताबिक एनोटेशन शामिल हो सकते हैं. इन्हें कभी-कभी टिप्पणियां भी कहा जाता है. इन्हें "#" प्रीफ़िक्स से दिखाया जाता है. एनोटेशन से मैसेज के मतलब या उसके व्यवहार पर कोई असर नहीं पड़ता.
2. मैसेज में हेडर हो सकते हैं. ये की-वैल्यू पेयर होते हैं, जो मैसेज की शुरुआत में दिखते हैं. ऊपर दिए गए उदाहरण में, इन्हें ":" से अलग किया गया है.
3. मैसेज में टेक्स्ट पेलोड होते हैं.

पिछले मैसेज का साइज़ कम करने के लिए क्या किया जा सकता है? यह मैसेज 200 वर्णों से शुरू होता है.

1. टिप्पणी दिलचस्प है, लेकिन इससे मैसेज के मतलब पर कोई असर नहीं पड़ता. मैसेज भेजते समय इसे हटा दें.
2. हेडर को बेहतर तरीके से एन्कोड करने के लिए, कई अच्छी तकनीकें उपलब्ध हैं. उदाहरण के लिए, अगर आपको पता है कि सभी मैसेज में "फ़ॉर्मैट" और "तारीख" है, तो उन्हें छोटे इंटीजर आईडी में बदला जा सकता है और सिर्फ़ उन्हें भेजा जा सकता है. हालांकि, ऐसा हो सकता है कि यह बात सच न हो. इसलिए, फ़िलहाल इसे ऐसे ही छोड़ देना बेहतर है.
3. पेलोड में सिर्फ़ टेक्स्ट है. हमें नहीं पता कि इसमें असल में क्या कॉन्टेंट है. ऐसा लगता है कि इसमें "secret-cipher" का इस्तेमाल किया जा रहा है. हालांकि, टेक्स्ट को देखकर ही पता चलता है कि इसमें बहुत ज़्यादा ग़ैर-ज़रूरी कॉन्टेंट है. बार-बार दोहराए जाने वाले अक्षरों को भेजने के बजाय, दोहराए जाने वाले अक्षरों की संख्या को गिना जा सकता है और उन्हें ज़्यादा बेहतर तरीके से कोड में बदला जा सकता है. उदाहरण के लिए, "AAA" को "3A" में बदल दिया जाता है. यह तीन A के क्रम को दिखाता है.

इन तकनीकों को मिलाकर, यह नतीजा मिलता है:

format: secret-cipher
date: 08/25/16
3A2Z4B3E3M 3E3T3A

नए मैसेज में 56 वर्ण हैं. इसका मतलब है कि आपने ओरिजनल मैसेज को 72% छोटा कर दिया है. यह एक बड़ी कमी है!

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

काट-छांट: प्रीप्रोसेसिंग और कॉन्टेक्स्ट के हिसाब से ऑप्टिमाइज़ेशन

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

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

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

<html>
  <head>
    <style>
      /* awesome-container is only used on the landing page */
      .awesome-container {
        font-size: 120%;
      }

      .awesome-container {
        width: 50%;
      }
    </style>
  </head>
  <body>
    <!-- awesome container content: START -->
    <div>
      This is my awesome container, and it is <em>so</em> awesome.
    </div>
    <!-- awesome container content: END -->
    <script>
      awesomeAnalytics(); // Beacon conversion metrics
    </script>
  </body>
</html>

पहले वाले एचटीएमएल स्निपेट और उसमें मौजूद तीन अलग-अलग तरह के कॉन्टेंट पर ध्यान दें:

1. एचटीएमएल मार्कअप.
2. पेज के प्रज़ेंटेशन को पसंद के मुताबिक बनाने के लिए सीएसएस.
3. JavaScript, ताकि इंटरैक्शन और पेज की अन्य ऐडवांस सुविधाओं को बेहतर बनाया जा सके.

इनमें से हर तरह के कॉन्टेंट के लिए, मान्य कॉन्टेंट के अलग-अलग नियम होते हैं. साथ ही, टिप्पणियां तय करने के लिए अलग-अलग नियम होते हैं. "इस पेज का साइज़ कैसे कम किया जा सकता है?"

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

<html><head><style>.awesome-container{font-size:120%;width:50%}</style></head><body><div>This is my awesome container, and it is <em>so</em> awesome.</div><script>awesomeAnalytics()</script></body></html>

पिछले चरणों को लागू करने के बाद, पेज में 516 से 204 वर्ण हो जाते हैं. इससे करीब 60% की बचत होती है. यह सच है कि इसे पढ़ना आसान नहीं है, लेकिन इस्तेमाल करने के लिए इसे पढ़ना ज़रूरी नहीं है. डेवलपमेंट के आधुनिक तरीकों की मदद से, सोर्स कोड के अच्छी तरह से फ़ॉर्मैट किए गए और पढ़ने लायक वर्शन को, प्रोडक्शन के लिए भेजे जाने वाले ऑप्टिमाइज़ किए गए कोड से अलग रखा जा सकता है. सोर्स मैप के साथ मिलकर, यह आपके बदले हुए प्रोडक्शन कोड को आसानी से पढ़ा जा सकने वाले फ़ॉर्मैट में दिखाता है. इससे, प्रोडक्शन में मौजूद गड़बड़ियों को आसानी से ठीक किया जा सकता है. इससे आपको डेवलपर के तौर पर बेहतर अनुभव मिलता है. साथ ही, उपयोगकर्ता अनुभव को बेहतर बनाने के लिए, परफ़ॉर्मेंस को ऑप्टिमाइज़ किया जा सकता है.

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

पिछले उदाहरण से एक अहम बात पता चलती है: अलग-अलग कामों के लिए इस्तेमाल किया जाने वाला कंप्रेसर, जैसे कि किसी भी टेक्स्ट को कंप्रेस करने के लिए डिज़ाइन किया गया कंप्रेसर, पिछले उदाहरण में पेज को कंप्रेस करने का अच्छा काम कर सकता है. हालांकि, उसे टिप्पणियों को हटाने, सीएसएस के नियमों को छोटा करने या कॉन्टेंट के हिसाब से किए जाने वाले अन्य ऑप्टिमाइज़ेशन के बारे में कभी पता नहीं चलेगा. इसलिए, प्रीप्रोसेसिंग, काट-छांट, और संदर्भ के हिसाब से ऑप्टिमाइज़ेशन करना ज़रूरी है.

ध्यान दें: उदाहरण के लिए, लोकप्रिय फ़्रेमवर्क के अनकंप्रेस्ड डेवलपमेंट वर्शन, प्रोडक्शन में इस्तेमाल किए जाने वाले वर्शन की तुलना में काफ़ी बड़े होते हैं. उदाहरण के लिए, Angular 1.8.3 का डेवलपमेंट वर्शन करीब 1.4 मेगाबाइट का है. प्रोडक्शन वर्शन 177 किलोबाइट का है. इससे साफ़ तौर पर पता चलता है कि इन ऑप्टिमाइज़ेशन से कितना फ़ायदा हो सकता है!

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

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

कंप्रेस करने के एल्गोरिदम की मदद से टेक्स्ट को कंप्रेस करना

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

• gzip और Brotli, कॉन्टेंट को कंप्रेस करने के लिए आम तौर पर इस्तेमाल किए जाने वाले एल्गोरिदम हैं. ये टेक्स्ट पर आधारित ऐसेट पर सबसे अच्छा काम करते हैं: सीएसएस, JavaScript, एचटीएमएल.
• सभी मॉडर्न ब्राउज़र, gzip और Brotli कंप्रेशन के साथ काम करते हैं. साथ ही, वे Accept-Encoding एचटीटीपी अनुरोध के हेडर में, दोनों के साथ काम करने की जानकारी देंगे.
• कंप्रेशन की सुविधा चालू करने के लिए, आपके सर्वर को कॉन्फ़िगर किया जाना चाहिए. वेब सर्वर सॉफ़्टवेयर, अक्सर टेक्स्ट पर आधारित संसाधनों को कंप्रेस करने के लिए, डिफ़ॉल्ट रूप से मॉड्यूल चालू कर देते हैं.
• कंप्रेशन के लेवल में बदलाव करके, gzip और Brotli, दोनों को बेहतर बनाया जा सकता है. इससे कंप्रेशन रेशियो को बेहतर किया जा सकता है. gzip के लिए, कंप्रेस करने की सेटिंग 1 से 9 तक होती हैं. इनमें से 9 सबसे अच्छी सेटिंग है. Brotli के लिए, यह रेंज 0 से 11 है. इसमें 11 सबसे बेहतर है. हालांकि, ज़्यादा कंप्रेस करने की सेटिंग में ज़्यादा समय लगता है. डाइनैमिक तौर पर कंप्रेस किए गए संसाधनों के लिए, रेंज के बीच की सेटिंग, कंप्रेशन रेशियो और स्पीड के बीच सबसे अच्छा संतुलन बनाती हैं. डाइनैमिक तौर पर कंप्रेस किए गए संसाधन, वे संसाधन होते हैं जो अनुरोध के समय कंप्रेस किए जाते हैं. हालांकि, स्टैटिक कंप्रेशन किया जा सकता है. इसमें जवाब को पहले ही कंप्रेस कर दिया जाता है. इसलिए, हर कंप्रेशन एल्गोरिदम के लिए उपलब्ध सबसे बेहतर कंप्रेशन सेटिंग का इस्तेमाल किया जा सकता है.
• कॉन्टेंट डिलीवरी नेटवर्क (सीडीएन) आम तौर पर, ज़रूरी शर्तों को पूरा करने वाले रिसॉर्स को अपने-आप कंप्रेस करने की सुविधा देते हैं. सीडीएन, आपके लिए डाइनैमिक और स्टैटिक कंप्रेशन को भी मैनेज कर सकते हैं. इससे आपको कंप्रेशन के एक पहलू के बारे में चिंता करने की ज़रूरत नहीं पड़ती.

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

ध्यान दें:  अगर आपको कंप्रेस करने के तरीके के बारे में ज़्यादा जानकारी चाहिए, तो gzip के बारे में कम लेवल पर दी गई यह जानकारी देखें. अगर आपको टेक्स्ट कंप्रेशन के साथ एक्सपेरिमेंट करना है, तो हमारे gzip और Brotli कोडलैब आज़माएं.

आम तौर पर, gzip और Brotli, दोनों ही टेक्स्ट वाले कॉन्टेंट पर सबसे अच्छा परफ़ॉर्म करते हैं. बड़ी फ़ाइलों के लिए, अक्सर 70 से 90% तक की कंप्रेशन दर हासिल की जाती है. हालांकि, इन एल्गोरिदम को ऐसी एसेट पर चलाने से कोई फ़ायदा नहीं होता जो पहले से ही अन्य एल्गोरिदम का इस्तेमाल करके कंप्रेस की गई हैं. जैसे, ज़्यादातर इमेज फ़ॉर्मैट, जिनमें फ़ाइल कंप्रेस करने से क्वालिटी पर असर न पड़ने वाली या लॉसी कंप्रेस करने की तकनीक का इस्तेमाल किया जाता है.

सभी मॉडर्न ब्राउज़र, Accept-Encoding एचटीटीपी अनुरोध के हेडर में gzip और Brotli के साथ काम करने की जानकारी देते हैं. हालांकि, सर्वर देने वाली संस्था की ज़िम्मेदारी है कि वह यह पक्का करे कि वेब सर्वर को सही तरीके से कॉन्फ़िगर किया गया हो, ताकि क्लाइंट के अनुरोध करने पर कंप्रेस किए गए संसाधन को दिखाया जा सके.

फ़ाइल	एल्‍गोरि‍दम	कंप्रेस नहीं किया गया साइज़	संपीडित आकार	कंप्रेशन का अनुपात
angular-1.8.3.js	Brotli	1,346 केआईबी	256 केआईबी	81%
angular-1.8.3.js	gzip	1,346 केआईबी	329 केआईबी	76%
angular-1.8.3.min.js	Brotli	173 केआईबी	53 केआईबी	69%
angular-1.8.3.min.js	gzip	173 केआईबी	60 केआईबी	65%
jquery-3.7.1.js	Brotli	302 केआईबी	69 केआईबी	77%
jquery-3.7.1.js	gzip	302 केआईबी	83 केआईबी	73%
jquery-3.7.1.min.js	Brotli	85 केआईबी	27 केआईबी	68%
jquery-3.7.1.min.js	gzip	85 केआईबी	30 केआईबी	65%
lodash-4.17.21.js	Brotli	531 केआईबी	73 केआईबी	86%
lodash-4.17.21.js	gzip	531 केआईबी	94 केआईबी	82%
lodash-4.17.21.min.js	Brotli	71 केआईबी	23 केआईबी	68%
lodash-4.17.21.min.js	gzip	71 केआईबी	25 केआईबी	65%

ऊपर दी गई टेबल में, Brotli और gzip कंप्रेशन से होने वाली बचत दिखाई गई है. यह बचत, कुछ लोकप्रिय JavaScript लाइब्रेरी के लिए है. फ़ाइल और एल्गोरिदम के हिसाब से, 65% से 86% तक की बचत होती है. रेफ़रंस के लिए, Brotli और gzip, दोनों के लिए हर फ़ाइल पर ज़्यादा से ज़्यादा कंप्रेशन लेवल लागू किया गया था. जहां भी संभव हो, gzip के बजाय Brotli का इस्तेमाल करें.

अहम जानकारी: ऊपर दी गई टेबल से साफ़ तौर पर पता चलता है कि काट-छांट जैसे ऑप्टिमाइज़ेशन के साथ-साथ, कंप्रेस करने की सुविधा का इस्तेमाल करने से, ज़्यादा बचत कैसे की जा सकती है. ऐसा हमेशा नहीं होता कि सिर्फ़ कंप्रेस करने से, काट-छांट के असर का कोई मतलब न रह जाए. यह एक अतिरिक्त ऑप्टिमाइज़ेशन है.

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

कंप्रेशन की प्रोसेस को देखने का एक आसान तरीका है, Chrome DevTools खोलना. इसके बाद, नेटवर्क पैनल खोलें, अपनी पसंद का कोई पेज लोड करें, और नेटवर्क पैनल के सबसे नीचे देखें.

Chrome DevTools के नेटवर्क पैनल में, पेज के सभी रिसॉर्स के ट्रांसफ़र साइज़ (यानी कि कंप्रेस किया गया साइज़) और उनके असल साइज़ की तुलना.

ऊपर दी गई इमेज की तरह, आपको इनका ब्रेकडाउन दिखेगा:

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

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

Core Web Vitals पर पड़ने वाले असर

परफ़ॉर्मेंस में हुए सुधारों को तब तक मेज़र नहीं किया जा सकता, जब तक कि उन सुधारों को दिखाने वाली मेट्रिक न हों. Core Web Vitals पहल का मकसद, ऐसी मेट्रिक बनाना और उनके बारे में जागरूकता बढ़ाना है जिनसे उपयोगकर्ता के असल अनुभव का पता चलता है. यह पेज लोड होने में लगने वाले समय जैसी मेट्रिक से अलग है. ऐसी मेट्रिक से उपयोगकर्ता अनुभव की क्वालिटी के बारे में साफ़ तौर पर पता नहीं चलता.

इस गाइड में बताए गए ऑप्टिमाइज़ेशन को अपनी वेबसाइट के संसाधनों पर लागू करने से, Core Web Vitals पर अलग-अलग असर पड़ सकते हैं. यह असर, ऑप्टिमाइज़ किए गए संसाधनों और शामिल मेट्रिक के आधार पर अलग-अलग हो सकता है. हालांकि, यहां कुछ ऐसे उदाहरण दिए गए हैं जिनमें इन ऑप्टिमाइज़ेशन को लागू करने से, आपकी वेबसाइट की Core Web Vitals को बेहतर बनाया जा सकता है:

• एचटीएमएल रिसॉर्स की काट-छांट और उन्हें कंप्रेस करने से, एचटीएमएल के लोड होने में लगने वाले समय को कम किया जा सकता है. साथ ही, उसके सब-रिसॉर्स को खोजने लायक बनाया जा सकता है. इससे सब-रिसॉर्स के लोड होने में लगने वाले समय को भी कम किया जा सकता है. इससे किसी पेज के सबसे बड़े एलिमेंट को रेंडर करने में लगने वाले समय (एलसीपी) को कम किया जा सकता है. rel="preload" जैसे रिसॉर्स हिंट का इस्तेमाल करके, रिसॉर्स को खोजे जाने लायक बनाया जा सकता है. हालांकि, बहुत ज़्यादा रिसॉर्स हिंट का इस्तेमाल करने से, बैंडविड्थ की समस्या हो सकती है. नेविगेशन अनुरोध के लिए एचटीएमएल रिस्पॉन्स को कंप्रेस करके, उनमें मौजूद रिसॉर्स को प्रीलोड स्कैनर की मदद से जल्द से जल्द खोजा जा सकता है.
• कंप्रेशन का इस्तेमाल करके, कुछ एलसीपी कैंडिडेट को भी जल्दी लोड किया जा सकता है. उदाहरण के लिए, एलसीपी के लिए चुनी गई SVG इमेज के संसाधन लोड होने में लगने वाले समय को टेक्स्ट के आधार पर कंप्रेस करके कम किया जा सकता है. यह अन्य इमेज टाइप में किए जाने वाले ऑप्टिमाइज़ेशन से अलग है. अन्य इमेज टाइप, कंप्रेस करने के अन्य तरीकों से कंप्रेस किए जाते हैं. जैसे, JPEG इमेज में लॉसी कंप्रेशन का इस्तेमाल किया जाता है.
• इसके अलावा, टेक्स्ट नोड भी एलसीपी एलिमेंट हो सकते हैं. इस गाइड में बताई गई तकनीकों का इस्तेमाल कैसे किया जाए, यह इस बात पर निर्भर करता है कि आपके वेब पेजों पर टेक्स्ट के लिए वेब फ़ॉन्ट का इस्तेमाल किया जा रहा है या नहीं. अगर वेब फ़ॉन्ट का इस्तेमाल किया जा रहा है, तो वेब फ़ॉन्ट ऑप्टिमाइज़ेशन के सबसे सही तरीके लागू होते हैं. हालांकि, अगर वेब फ़ॉन्ट का इस्तेमाल नहीं किया जा रहा है, बल्कि सिस्टम फ़ॉन्ट का इस्तेमाल किया जा रहा है, तो सीएसएस को छोटा और कंप्रेस करने से, रिसॉर्स लोड होने में लगने वाला समय कम हो जाता है. सिस्टम फ़ॉन्ट, बिना किसी रिसॉर्स लोड के दिखते हैं. इसका मतलब है कि संभावित एलसीपी टेक्स्ट नोड की रेंडरिंग जल्दी हो सकती है.

नतीजा

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

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

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