2024 में JavaScript का बढ़ता bloat

JavaScript के आकार की समस्या

• आधुनिक frontend development से कुछ हद तक दूर था, और मुझे वे लेख याद थे जो कई megabyte तक पहुँचने वाले web page size के बारे में थे.
• मुझे यह अंदाज़ा था कि अगर औसत web page size 3MB है, तो JavaScript bundle लगभग 1MB का होगा.
• वास्तव में यह कितना है, इसे जाँचने के लिए एक प्रयोग किया गया.

तरीका

• macOS पर Firefox का उपयोग (दूसरे browsers में भी संभवतः यही होगा)
• incognito mode नहीं, बल्कि सामान्य mode (ऐप के अंदर के आँकड़े देखना चाहता था, और लगा कि यह वास्तविक अनुभव के अधिक करीब होगा)
• सभी extensions निष्क्रिय
• केवल JavaScript को मापा गया
• uncompressed स्थिति में
• service worker enabled (ज़्यादा वास्तविक परिस्थिति के लिए)
• सभी caching disabled (शुरुआत से loading)

Landing page

• सामान्य, हल्की interactivity वाला page उदाहरण: Wikipedia, 0.2MB
• थोड़ा फूला हुआ page उदाहरण: Linear, 3MB
• खराब landing page उदाहरण: Zoom, 6MB; Vercel, 6MB; Gitlab, 13MB

ज़्यादातर static websites

• static text wall दिखाने से ज़्यादा सरल कुछ नहीं हो सकता.
• Medium को सिर्फ इसके लिए 3MB चाहिए.
• Substack को 4MB, Quora को 4.5MB, Pinterest को 10MB, Patreon को 11MB चाहिए.

Search

• ऐप की interactivity मुख्यतः search तक सीमित है.
• StackOverflow को 3.5MB, NPM को 4MB, Airbnb को 7MB, Booking.com को 12MB चाहिए.
• Google को सिर्फ एक साधारण text field और links की सूची दिखाने के लिए 9MB चाहिए.

Single-interaction apps

• Google Translate को दो text boxes के लिए 2.5MB चाहिए.
• ChatGPT को एक text box के लिए 7MB चाहिए.

Video

• Loom को 7MB, YouTube को 12MB चाहिए.
• Pornhub, जो performance पर ध्यान देने वाली site है, उसे सिर्फ 1.4MB चाहिए.

Audio

• SoundCloud और Spotify, दोनों को 12MB चाहिए.

Email

• Google Mail को 20MB चाहिए.
• FastMail वही functionality देते हुए भी सिर्फ 2MB में काम करता है.

Productivity

• Todoist को 9MB, Dropbox को 10MB, 1Password को 13MB, Trello को 13.5MB चाहिए.
• Discord को chat के लिए 21MB चाहिए.

Document editing

• Google Docs को 13.5MB, Notion को 16MB चाहिए.

Social network

• Twitter को 11MB, Facebook को 12MB, TikTok को 12.5MB, Instagram को 16MB, LinkedIn को 31MB चाहिए.

विशाल category

• Jira को लगभग 50MB, Slack को 55MB चाहिए.
• react.dev शुरुआत में 2MB से शुरू होता है, लेकिन scroll करने पर यह अनंत तक बढ़ सकता है.

क्या यह समय के साथ और तेज़ी से बिगड़ रहा है?

• 2015 में औसत web page size Doom 1 के shareware version (2.5MB) के करीब था.
• 2024 में Slack 55MB लेता है, जो सिर्फ JavaScript में ही मूल Quake 1 के आकार के बराबर है.

10MB कितना बड़ा है?

• 10MB अब इतना बड़ा या असाधारण नहीं लगता.
• औसतन अगर एक पंक्ति में 65 characters मानें, तो हर website पर लगभग 150,000 lines of code भेजी जा रही हैं.
• Google Maps आधुनिक मानकों के हिसाब से अपेक्षाकृत विनम्र 4.5MB पर है.

निष्कर्ष

• सिर्फ download size ही समस्या नहीं है.
• JavaScript ऐसी चीज़ है जिसे browser को parse करना, memory में रखना और execute करना पड़ता है.
• मेरा मानना है कि content को code size से बड़ा होना चाहिए.
• Gitlab को static landing page दिखाने के लिए 13MB code, यानी 500K+ LoC की JS चाहिए.

GN⁺ की राय:

1. यह web development की मौजूदा स्थिति का एक यथार्थवादी निदान है, जो यह समझने में मदद करता है कि websites के JavaScript size का user experience और performance पर क्या असर पड़ता है.
2. यह frontend developers को optimization के महत्व की याद दिलाता है और ज़रूरत से ज़्यादा resources के इस्तेमाल से सावधान करता है.
3. यह website performance को लेकर developer community के भीतर चर्चा को बढ़ावा देने वाला दिलचस्प data प्रदान करता है.

[GN⁺]

Hacker News की राय

• एडल्ट वेबसाइट्स वास्तव में performance पर ध्यान देने का एक उदाहरण हैं; Pornhub सिर्फ 1.4MB data लोड करता है। यह कुछ बड़े tech companies के performance की तुलना में कहीं बेहतर है। Pornhub बुनियादी UI/UX या content delivery में शायद ही कभी गलती करता है।
• न्यूज़ीलैंड के ग्रामीण इलाके में roaming service इस्तेमाल करते हुए web का अनुभव बहुत खराब था। Spotify के offline user experience (UX) में भी सुधार की ज़रूरत है।
• यह सवाल उठाया गया कि हम uncompressed data क्यों देख रहे हैं। Spotify और Gmail जैसे dynamic apps को माफ़ किया जा सकता है अगर page load होने के बाद navigation तेज़ हो। कुछ sites शुरुआती loading पर ज़रूरत से ज़्यादा ज़ोर देकर user experience खराब कर रही हैं।
• software उसे बनाने वाले संगठन को प्रतिबिंबित करता है। अधिकांश data transfer असल में page चलाने के लिए ज़रूरी JavaScript नहीं, बल्कि analytics और third-party scripts हैं। marketing teams या तो इन बातों से अनजान हैं या उन्हें इसकी परवाह नहीं है।
• web applications के JavaScript file size पर विश्लेषण गायब था। उदाहरण के लिए Google Translate सिर्फ एक साधारण interactive app नहीं है; उसमें बहुत-सी features हैं, फिर भी 2.5MB अब भी बहुत ज़्यादा है।
• Wordsandbuttons.online वेबसाइट के सभी pages animation और interaction के बावजूद 64KB से कम हैं। यह third-party dependencies न रखने की policy की वजह से संभव है।
• सिर्फ JavaScript के अत्यधिक उपयोग ही नहीं, बल्कि tracking scripts की मात्रा पर भी चर्चा होनी चाहिए।
• लोकप्रिय sites पर लोड होने वाली JavaScript की मात्रा की तुलना की गई। उदाहरण के लिए, Pornhub YouTube की तुलना में लगभग 10 गुना कम JavaScript लोड करता है।
• web की मौजूदा स्थिति बहुत दुखद है। तेज़ internet connection इस्तेमाल करने वाले लोगों को एहसास ही नहीं होता कि web कितना धीमा हो चुका है। ad/tracker blocker के बिना रहना सोचना भी मुश्किल है।
• maintainability आसान बनाने के लिए जटिल frameworks और abstractions बनाए और संभाले जाते हैं, लेकिन बहुत-से developers को JavaScript की बुनियादी बातें भी नहीं पता। वे web applications को ज़रूरत से ज़्यादा engineer कर देते हैं और इतनी सारी layers बना देते हैं कि असली language ही छिप जाती है। अगर JavaScript को खुद सीखा जाए और frameworks की जगह plain JavaScript इस्तेमाल किया जाए, तो JavaScript codebase को काफ़ी हद तक घटाया जा सकता है।