HTML कम्प्रेसर

HTML को मिनिफ़ाई क्यों किया जाए

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

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

कम्प्रेसर क्या हटाता है

हर विकल्प फूलाव के किसी ख़ास स्रोत को निशाना बनाता है। Remove HTML comments डेवलपर के नोट और टिप्पणी में बदले गए कोड को मिटा देता है जिन्हें विज़िटर कभी नहीं देखते। Remove unnecessary whitespace टैगों के बीच मौजूद स्पेस, टैब और न्यूलाइन की उन कतारों को समेट देता है जो सिर्फ़ पठनीयता के लिए होती हैं। Remove empty attributes बिना किसी मान वाले एट्रिब्यूट हटा देता है, और Remove optional HTML tags उन क्लोज़िंग टैगों को छोड़ देता है जिन्हें HTML विनिर्देश आपको छोड़ देने की अनुमति देता है, जैसे कुछ संदर्भों में सूची आइटमों के एंड टैग।

Collapse boolean attributes एक छोटी पर सुथरी जीत है: disabled या checked जैसे एट्रिब्यूट को HTML में किसी मान की ज़रूरत नहीं होती, इसलिए disabled को स्ट्रिंग disabled पर सेट करने जैसा पूरा-पूरा लिखा हुआ रूप छोटा करके सिर्फ़ एट्रिब्यूट के नाम तक रह जाता है। मिलकर ये पास ऐसे कैरेक्टर हटा देते हैं जिनका रेंडरिंग पर शून्य असर होता है, और यही वजह है कि सही-ढंग से बनी पेजों के लिए मानक मिनिफ़िकेशन सुरक्षित है।

एक हल किया हुआ उदाहरण

ऐसे एक स्निपेट की कल्पना करें जिसमें चार-स्पेस का इंडेंट हो, किसी div के ऊपर एक HTML टिप्पणी हो, और एक चेकबॉक्स इनपुट checked को स्ट्रिंग checked पर सेट करके लिखा हो। कम्प्रेशन के बाद इंडेंटेशन और लाइन ब्रेक समिट जाते हैं ताकि टैग आस-पास बैठ जाएँ, टिप्पणी पूरी तरह ग़ायब हो जाती है, और चेकबॉक्स बस एक ऐसा इनपुट बन जाता है जो नंगा checked एट्रिब्यूट लिए होता है। पेज ब्राउज़र में बिलकुल वैसा ही दिखता और बर्ताव करता है, पर बाइट की गिनती गिर जाती है, और आँकड़े वाला पैनल मूल आकार, कम्प्रेस किया आकार, और बचाया गया प्रतिशत बता देता है ताकि आप अपनी ख़ास फ़ाइल के लिए फ़ायदा देख सकें।

क्या हटाना सुरक्षित है और क्या जोखिम भरा

जिस सीमा का सम्मान करना है वह वह व्हाइटस्पेस है जिस पर पेज सचमुच निर्भर करता है। pre और textarea एलिमेंटों के अंदर, हर स्पेस और न्यूलाइन मायने रखती है: यह हू-ब-हू रेंडर होती है, इसलिए इसे समेटना आउटपुट को साफ़ तौर पर बदल देगा। यही सावधानी उन एलिमेंटों पर लागू होती है जिनका CSS फ़ॉर्मेटिंग बनाए रखने के लिए white-space सेट करता है। टिप्पणियाँ हटाना आम तौर पर सुरक्षित है, पर कुछ बोझ-वहन करने वाली होती हैं, जैसे पुरानी Internet Explorer कंडीशनल टिप्पणियाँ या वे टिप्पणियाँ जिन्हें कोई टेम्प्लेटिंग सिस्टम या फ़्रेमवर्क निशान के रूप में पढ़ता है; उन्हें मिटाना बर्ताव तोड़ सकता है।

CSS और JavaScript मिनिफ़िकेशन विकल्पों को ठीक वजह से प्रयोगात्मक का लेबल दिया गया है। style टैगों और एट्रिब्यूट के अंदर इनलाइन CSS, या script टैगों के अंदर JavaScript को मिनिफ़ाई करना सिर्फ़ लेआउट व्हाइटस्पेस छाँटने के बजाय कोड को फिर से लिखना शामिल करता है, और किनारे वाले मामले मौजूद हैं। उन्हें चालू करने के बाद हमेशा किसी पेज को जाँचें, ख़ासकर अगर आपकी स्क्रिप्ट ख़ास फ़ॉर्मेटिंग, टिप्पणी-आधारित निर्देशों, या नाज़ुक स्ट्रिंग संभाल पर निर्भर हों।

मिनिफ़िकेशन का gzip से क्या रिश्ता है

सर्वर लगभग हमेशा HTML को gzip या Brotli से कम्प्रेस करके भेजते हैं, और लोग कभी-कभी यह मान लेते हैं कि इससे मिनिफ़िकेशन बेमतलब हो जाता है। ऐसा नहीं होता। Gzip दोहराव वाले टेक्स्ट को कम्प्रेस करने में बेहतरीन है, इसलिए मिनिफ़ाई किए HTML के ऊपर यह जो सापेक्ष प्रतिशत बचाता है वह कच्चे HTML की तुलना में छोटा होता है, पर दोनों तकनीकें एक-दूसरे पर चढ़ती हैं: मिनिफ़ाई-फिर-gzip किया गया अब भी सुंदर-छपे-फिर-gzip किए गए से छोटा होता है। मिनिफ़िकेशन उन बाइटों को भी सिकोड़ देता है जिन्हें ब्राउज़र को डिकम्प्रेशन के बाद पार्स करना पड़ता है, और यह कैश में संग्रहित आकार को भी घटाता है।

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

मिनिफ़िकेशन बिल्ड पाइपलाइन में कहाँ बैठता है

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

यह जाँच और सीखने के लिए भी काम का है: कोई पेज पेस्ट करें, उसे चलाएँ, और कमी का प्रतिशत पढ़कर अंदाज़ा लगाएँ कि आपका मार्कअप कितनी चर्बी ढो रहा है, जो ज़्यादा टिप्पणियों या गहराई से इंडेंट किए टेम्प्लेट जैसी आदतों को उजागर कर सकता है जिन्हें स्रोत पर ही सुधारना सार्थक हो।

बचने लायक़ आम ग़लतियाँ

सबसे नुक़सानदेह ग़लती ऐसी सामग्री को मिनिफ़ाई करना है जो व्हाइटस्पेस पर निर्भर हो, और फिर यह पता चलना कि किसी pre ब्लॉक या किसी कोड नमूने के अंदर का टेक्स्ट अपनी फ़ॉर्मेटिंग खो बैठा है; उन्हें अनछुआ रखें या ध्यान से जाँचें। दूसरी ऐसी कंडीशनल या निर्देश टिप्पणियाँ हटाना है जिन पर आगे कुछ निर्भर करता हो। एक सूक्ष्म जाल मिनिफ़ाई की हुई फ़ाइल को सीधे संपादित करना है: एक बार व्हाइटस्पेस चला जाए तो कोड का रखरखाव मुश्किल हो जाता है, इसलिए अपने पठनीय स्रोत को हमेशा सच का स्रोत रखें और मिनिफ़ाई किए संस्करण को एक जनित कलाकृति मानें। और जब भी आप प्रयोगात्मक CSS या JS पास चालू करें, भेजने से पहले लाइव पेज को जाँचें।