2024 में JavaScript ब्लोट
आधुनिक वेबसाइटें नियमित रूप से कई मेगाबाइट JavaScript शिप करती हैं—यहाँ तक कि अपेक्षाकृत सरल पेजों के लिए भी—और उदाहरणों में हल्के पक्ष पर ~1–3 MB से लेकर Gmail, Figma और Jira जैसी सेवाओं के लिए 10–60 MB तक शामिल हैं। टिप्पणीकारों का तर्क है कि यह ब्लोट भारी फ़्रेमवर्क्स, खराब code-splitting, थर्ड-पार्टी ट्रैकिंग और संगठनात्मक प्रोत्साहनों से पैदा होता है, और वे नोट करते हैं कि compression और caching CPU, memory और battery लागत को नहीं ठीक करते, खासकर लो-एंड डिवाइसों या धीमे कनेक्शनों पर। कुछ लोग बड़े बंडलों को समृद्ध web applications के लिए स्वीकार्य मानते हैं यदि शुरुआती लोड के बाद नेविगेशन तेज़ हो, जबकि अन्य हल्की साइट्स और zero-dependency approaches को इस बात का प्रमाण मानते हैं कि कहीं अधिक कुशल डिज़ाइन संभव हैं.
हेडलाइन आकार की तुलना और हैरानियाँ
- टिप्पणीकार बड़े JS पेलोड्स पर जोर देते हैं: Gmail और Figma ~20 MB, YouTube ~12 MB JS + 2.5 MB CSS, Jira ~58 MB, और कुछ लैंडिंग पेज केवल टेक्स्ट और इमेज दिखाने के लिए ही कई MB के होते हैं।
- पोर्न साइट्स (जैसे, Pornhub) को बार-बार अपेक्षाकृत हल्का बताया जाता है (≈1–1.4 MB), जबकि वे मीडिया-समृद्ध होती हैं।
- कई डेवलपर्स अपनी जटिल ऐप्स को 1–4 MB पर चलाते हुए बताते हैं और हैरान हैं कि उससे कहीं बड़ी कंपनियाँ 10–50 MB शिप करती हैं।
कंप्रेशन, पार्सिंग, और डिवाइस सीमाएँ
- कंप्रेस्ड बनाम अनकंप्रेस्ड साइज़ देखने पर बहस होती है: कंप्रेशन ट्रांसफ़र कम करता है, लेकिन पार्स/एक्ज़ीक्यूट लागत नहीं।
- पुराने और लो-एंड Android डिवाइस बड़े बंडलों और भारी DOM काम से सबसे अधिक प्रभावित बताए जाते हैं।
- कुछ लोग तर्क देते हैं कि सिर्फ आकार एक मोटा संकेतक है; प्रोफाइलिंग दिखाती है कि DOM रेंडरिंग, लेआउट, अकार्यक्षम रिएक्टिविटी, और वॉटरफ़ॉल्स अक्सर अधिक भारी पड़ते हैं।
ब्लोट के स्रोत: SPAs, फ़्रेमवर्क, और ट्रैकिंग
- कई लोग SPA फ़्रेमवर्क्स और जरूरत से ज़्यादा जटिल आर्किटेक्चर्स को सरल साइट्स को ऐप्स में बदलने के लिए दोषी मानते हैं।
- अन्य कहते हैं कि बहुत सारे बाइट्स एनालिटिक्स, टैग मैनेजर्स, AB-टेस्टिंग, और कस्टमर-सपोर्ट विजेट्स के होते हैं, जिन्हें मार्केटिंग चलाती है और कभी-कभी डेवलपर ओवरसाइट के बिना इंजेक्ट किया जाता है।
- थर्ड-पार्टी ट्रैकिंग स्क्रिप्ट्स खुद कई MB की हो सकती हैं और अक्सर बाहरी CDNs से लोड होती हैं।
यूज़र अनुभव: कुछ के लिए तेज़, कुछ के लिए अनुपयोगी
- मिश्रित रिपोर्ट्स: कुछ लोगों को YouTube, GitHub, Discord आदि “स्नैपी” लगते हैं; अन्य को खासकर मिड/पुराने हार्डवेयर या मोबाइल पर स्पष्ट लैग और फ़्रीज़ दिखाई देते हैं।
- सीमित कनेक्शनों पर रहने वाले लोग (ग्रामीण, रोमिंग, 2 Mbps, या 15 GB/महीना जैसे कम डेटा कैप) कई आधुनिक साइट्स को ब्लॉकर्स के बिना मुश्किल से उपयोग योग्य बताते हैं।
- Spotify और Gmail जैसे ऐप्स के ऑफ़लाइन/खराब-कनेक्टिविटी UX की बहुत आलोचना की जाती है।
बहस: क्या बड़े बंडल वास्तव में समस्या हैं?
- एक पक्ष: “Less JS = better” एक उपयोगी ह्यूरिस्टिक है; बुनियादी UI के लिए 10–50 MB साफ़ तौर पर बर्बादी है और औसत उपयोगकर्ताओं को नुकसान पहुँचाता है।
- दूसरा पक्ष: “सामान्य” कनेक्शनों पर लागत स्वीकार्य है; बंडल आकार मेट्रिक्स का पीछा करने से बेहतर है कि समग्र UX (कैशिंग, तेज़ इन-ऐप नेविगेशन) को ऑप्टिमाइज़ किया जाए।
- कुछ लोगों का तर्क है कि kilobytes पर जुनूनी होने के बजाय हमें कैशिंग/PWA और प्लेटफ़ॉर्म समस्याएँ ठीक करनी चाहिए।
कार्यविधि की आलोचनाएँ और बारीकियाँ
- कई टिप्पणियाँ लेख की माप-सम्बंधी समस्याएँ बताती हैं:
- केवल cold loads और uncompressed sizes देखना।
- disabled cache repeat downloads को बढ़ा-चढ़ाकर दिखाता है (जैसे, React docs sandboxes)।
- कुछ “static-looking” पेज वास्तव में multi-tool webapps के front-doors होते हैं (जैसे, Outlook, Translate)।
- अन्य लोग जवाब देते हैं कि इन सावधानियों के बावजूद, परिमाण-स्तरीय अंतर और वास्तविक दुनिया की सुस्ती एक वास्तविक ब्लोट समस्या दिखाते हैं।
विकल्प, टूल्स, और प्रथाएँ
- सुझाए गए उपाय: code-splitting, lazy loading, virtual lists, अनावश्यक DOM nodes से बचना, और bundle analysis tools (जैसे, Webpack/Rollup analyzers)।
- कुछ लोग zero-dependency या minimal-dependency तरीकों, HTMX/PJAX-शैली नेविगेशन, या नए “resumable” frameworks (जैसे, Qwik) की वकालत करते हैं।
- एक मजबूत बार-बार उभरने वाला विषय: संगठनात्मक प्रोत्साहन (मार्केटिंग, विकास की गति) JS जोड़ने को बढ़ावा देते हैं; प्रदर्शन के बहुत कम समर्थक हैं।