2024 में JavaScript का बढ़ता बड़प्पन
(tonsky.me)- वेबपेजों पर वास्तविक कंटेंट की तुलना में कहीं अधिक uncompressed JavaScript डाउनलोड कराना आम होता जा रहा है, जिससे साधारण landing page से लेकर कामकाजी ऐप्स तक ब्राउज़र पर बोझ बढ़ रहा है
- माप Firefox on macOS में extension और cache बंद करके केवल JavaScript को गिनते हुए किया गया, ताकि image·video·style को छोड़कर code execution की लागत पर ध्यान रहे
- Wikipedia 0.2MB था, लेकिन Linear 3MB, Zoom·Vercel 6MB, GitLab 13MB जैसे मामलों में साधारण पेज भी कुछ MB से लेकर दो अंकों वाले MB तक पहुँच जाते हैं
- ऐप श्रेणी में Gmail 20MB और FastMail 2MB के बीच 10 गुना का अंतर दिखा, और Jira लगभग 50MB व Slack 55MB जैसे chatting·work tools में code size खास तौर पर बहुत बड़ा है
- JavaScript डाउनलोड होने के बाद भी parsing·memory retention·execution की लागत पैदा करता है, इसलिए छोटे कंटेंट को render करने के लिए बहुत बड़े code bundle की ज़रूरत वाली संरचना performance और battery पर सीधा बोझ डालती है
मापने का तरीका और तुलना के मानदंड
- मापने का वातावरण Firefox on macOS था, और यह मानकर परीक्षण किया गया कि ब्राउज़र बदलने पर भी नतीजे मोटे तौर पर समान रहेंगे
- शर्तें इस प्रकार थीं
- incognito mode नहीं, सामान्य mode
- सभी extension disabled
- केवल JavaScript का मापन
- uncompressed size के आधार पर
- Service Worker enabled
- cache disabled के साथ cold load
- कंटेंट हर साइट पर बहुत अलग होता है, इसलिए उसे तुलना से बाहर रखा गया
- YouTube का video और Slack के text message स्वभाव से ही अलग आकार के होते हैं
- JavaScript को interaction की जटिलता की तुलना के लिए एक साझा संकेतक के रूप में इस्तेमाल किया गया
- मुख्य बात यह है कि browser को code parse और execute करने के लिए कितना काम उठाना पड़ता है
- संदर्भ बिंदु के रूप में tonsky.me ब्लॉग खुद 0.004MB मापा गया
लैंडिंग पेज और स्थिर कंटेंट
- थोड़ी-बहुत interaction वाले सामान्य पेज के उदाहरण में Wikipedia लगभग 0.2MB था
- इससे भारी landing page इस प्रकार थे
- Linear: 3MB
- Zoom: 6MB
- Vercel: 6MB
- GitLab: 13MB
- ऊपर दिए गए आँकड़े image, video, style को छोड़कर केवल JavaScript code के आकार के हैं
- स्थिर text दिखाने वाली वेबसाइटें भी कई MB का JavaScript डाउनलोड कराती हैं
- Medium: 3MB
- Substack: 4MB
- Quora: 4.5MB
- Pinterest: 10MB
- Patreon: 11MB
- ऐसे उदाहरण मिलते हैं जहाँ ऐसा लगता है कि कंटेंट दिखाने का काम static page से हो सकता था, लेकिन उसके लिए बड़े JavaScript bundle इस्तेमाल हो रहे हैं
सर्च और सरल interaction ऐप्स
- search-केंद्रित ऐप्स में query input और result list दिखाना मुख्य काम होता है, फिर भी JavaScript का आकार छोटा नहीं है
- StackOverflow: 3.5MB
- NPM: 4MB
- Airbnb: 7MB
- Booking.com: 12MB
- Google Search को text field और link list वाला सरल UI होने के बावजूद 9MB मापा गया
- साधारण input UI वाली services भी कई MB JavaScript इस्तेमाल करती हैं
- Google Translate: 2.5MB
- ChatGPT: 7MB
- ChatGPT की जटिलता server side पर होने की बात अलग है, लेकिन browser तक 7MB JavaScript फिर भी पहुँचता है
मीडिया सेवाएँ और ईमेल
- video services का JavaScript आकार इस प्रकार था
- Loom: 7MB
- YouTube: 12MB
- Pornhub: 1.4MB
- audio services में SoundCloud और Spotify दोनों लगभग 12MB मापे गए
- email services में अंतर बहुत बड़ा दिखा
- Google Mail: 20MB
- FastMail: 2MB
- FastMail, उसी email service श्रेणी में, Google Mail की तुलना में 10 गुना कम JavaScript इस्तेमाल करता है
- Google Mail का 20MB इतना बड़ा है कि इसकी तुलना Figma जैसे custom C++/OpenGL rendering वाले ऐप से की जा सकती है
productivity tools और दस्तावेज़ संपादन
- productivity apps में भी सरल काम के मुकाबले JavaScript का आकार बड़ा है
- Todoist: 9MB
- Dropbox: 10MB
- 1Password: 13MB
- Trello: 13.5MB
- Discord: 21MB
- Dropbox folder के अंदर file list, 1Password password list, और Trello card display जैसे कामों के लिए भी 10MB से अधिक इस्तेमाल करता है
- document editing services दो अंकों वाले MB स्तर पर हैं
- Google Docs: 13.5MB
- Notion: 16MB
- document editing में cursor movement और sync जैसी कठिन सुविधाएँ होती हैं, फिर भी तुलना में इन services का JavaScript आकार बड़ा ही है
social network और बहुत बड़े उदाहरण
- social network आम तौर पर likes, feed, messaging जैसी सुविधाओं के लिए लगभग 12MB के आसपास JavaScript इस्तेमाल करते हैं
- Twitter: 11MB
- Facebook: 12MB
- TikTok: 12.5MB
- Instagram: 16MB
- LinkedIn: 31MB
- LinkedIn में blog, platform, search, messaging और social features सब शामिल हैं, और इसे 31MB मापा गया
- बहुत बड़े web app के उदाहरण लगभग अलग श्रेणी जैसे हैं
- Jira: लगभग 50MB
- Slack: 55MB
- Slack एक chat app है जो user list, message और reaction संभालता है, फिर भी 55MB JavaScript डाउनलोड कराता है
- react.dev शुरुआत में 2MB से शुरू होता है, लेकिन बार-बार scroll करने पर JavaScript लगातार बढ़ता हुआ देखा गया
- उदाहरण के तौर पर इसे 100MB तक बढ़ाया जा सका
- update के अनुसार सामान्य user experience में embedded code editor पहली load के बाद cache में save हो जाता है, इसलिए बाद के network traffic में यह नहीं दिखता
- फिर भी scroll करते समय 100MB JavaScript लगातार parse, evaluate और initialize हो सकता है
10MB code का क्या मतलब है
- 2015 में औसत webpage size Doom 1 shareware version के 2.5MB के करीब पहुँच रहा था
- 2024 में Slack केवल JavaScript के दम पर मूल Quake 1 के पूरे resource size 55MB तक पहुँच गया
- 10MB code अब सामान्य स्तर जैसा लग सकता है, लेकिन अगर code की औसत एक line 65 characters मानी जाए तो यह लगभग 1.5 लाख lines के बराबर है
- यह code पहले से minified है, इसलिए मूल रूप में यह 3 लाख lines से अधिक हो सकता है
- Google Maps को SPA का प्रतिनिधि उदाहरण माना जाता है, लेकिन यह 4.5MB मापा गया, जो आधुनिक web app मानकों के हिसाब से उल्टा छोटा दिखता है
- Figma जैसा जटिल frontend app होने पर JavaScript download size बड़ा होना स्वाभाविक है, लेकिन Gmail लगभग Figma जितना, LinkedIn 1.5 गुना, और Slack 2.5 गुना तक पहुँचता है
ब्राउज़र को चुकानी पड़ने वाली कीमत
- समस्या सिर्फ download size पर खत्म नहीं होती
- JavaScript को browser को parse करना, memory में रखना, और execute करना पड़ता है, इसलिए यह लगातार लागत पैदा करता है
- अगर मानदंड यह हो कि कंटेंट का आकार code के आकार से बड़ा होना चाहिए, तो 10K characters की blog post render करने के लिए उससे 1000 गुना बड़ा JavaScript चाहिए होना बहुत अधिक है
- अच्छे उदाहरण के रूप में जिन साइटों का ज़िक्र है, वे केवल 0.1MB JavaScript से भी पर्याप्त रूप से काम करती हैं
- उसी web environment में GitLab static landing page दिखाने के लिए 13MB, यानी लगभग 5 लाख lines से अधिक JavaScript की ज़रूरत वाला उदाहरण बनता है
1 टिप्पणियां
Hacker News की रायें
10MB, 12MB जैसी चीज़ों की तुलना Pornhub 1.4MB से कर लो, जो performance की सच में परवाह करता है
पोर्न साइटें हमेशा असल वेब high-tech रही हैं और उनकी engineering भी अच्छी रही है, मज़ाक जैसी “tech” बड़ी कंपनियों से अलग
बेसिक UI/UX, content delivery, और common-sense design को बिगाड़ने की याद शायद ही आती है
सिर्फ़ इसलिए कि असली web applications में page refresh अनचाहा behavior है, अचानक ऐसा लगता है कि हर कोई websites में page refresh से डरने लगा
20 साल तक enterprise applications पर काम किया है, और जन्म से पहले बने systems भी देखे हैं; मेरे हिसाब से React उन systems में पहले के भयानक client/server UI की जगह लेने वाला सबसे अच्छा frontend था
Angular/Vue वगैरह भी इसी संदर्भ में आते हैं। लेकिन सामान्य web pages के लिए, Gmail, Facebook जैसी जगहों को छोड़कर—जहाँ interaction और real-time updates product का core हैं—इनकी लगभग ज़रूरत नहीं है
Pornhub जैसी जगहों के लिए PHP भी काफ़ी है, और अधिकांश websites के लिए भी यही सच है। HN या old.reddit.com को आज भी पसंद करने वाले लोगों को देख लो, और मुझे लगता है कि धीमे हो चुके नए Facebook की बजाय old.Facebook पसंद करने वाले भी बहुत होंगे
जैसे popups, popunders, fake content के जरिए मिलती-जुलती aggregation sites पर भेजना, content की जगह affiliate sites खोलना, search results को प्रदूषित करना
पोर्न उतना technology-driving industry नहीं है जितना लोग कहते हैं, Betamax बनाम VHS वाली urban legend भी सच नहीं है, और यह कहना कि उसने internet innovation को lead किया, अतिशयोक्ति है
कुछ players हैं जो high-quality products बनाते हैं, लेकिन वे पूरी industry का प्रतिनिधित्व नहीं करते। link farms, dummy content, cloned sites, false advertising, और search result manipulation बहुत है
आज top sites तेज़ हैं, यह competition का नतीजा लगता है। UX खराब हो तो मुफ्त porn की भरमार है, user तुरंत कहीं और चला जाता है, इसलिए retention के लिए optimize करना पड़ता है
दूसरी websites में shareholders, content providers, exclusive contracts, monopoly-like position जैसे दूसरे incentives होते हैं, इसलिए उन्हें user experience उतना optimize करने की ज़रूरत नहीं पड़ती
video delivery, live streaming (पहले Flash, अब WebRTC), page size जैसी हर तरह की चीज़ों को optimize करने में अनगिनत घंटे लगाए जाते हैं
समझ नहीं आता कि uncompressed data को क्यों देख रहे हैं। खराब उदाहरण के तौर पर दी गई कुछ sites भी compress करने पर GMaps के 1.5MB से आसानी से छोटी हो जाती हैं
Spotify या GMail जैसी dynamic apps में, अगर page load के बाद navigation तेज़ हो तो मुझे ठीक लगता है
startup पर update में कुछ seconds लेने वाला Discord, हर click पर 2 seconds तक wait करवाने वाले GitLab से बेहतर है
आजकल cold start और static rendering को दी जा रही priority कुछ sites पर उल्टा experience खराब कर रही है, ऐसा मुझे लगता है
प्रयोग के तौर पर GitHub में file tree navigate करके देखो; मेरे device पर यह GitHub के बाकी हिस्सों से काफ़ी ज़्यादा responsive है। संयोग से, यह उन बहुत कम हिस्सों में से एक है जो static rendered नहीं है
मैं रोज़ सैकड़ों GitHub pages क्लिक करता हूँ; एक pipeline देखने के लिए हर बार पूरा footer फिर से download करवाने के बजाय, मैं चाहूँगा कि एक बार बहुत सारा JavaScript भेजें और जितना हो सके cache करें
[1]: GMail और Spotify सिर्फ़ उदाहरण हैं, मैं वास्तव में उनका इस्तेमाल नहीं करता
reachability की चर्चा में यह मुद्दा अक्सर आता है; iOS और Android की CPU performance में बड़ा gap है, और आम जनता द्वारा खूब इस्तेमाल किए जाने वाले low-end devices को देखें तो आज बिकने वाला नया Android device भी 2014 के iPhone से धीमा हो सकता है
अगर developers सिर्फ़ latest iPhone या flagship Android इस्तेमाल करते हैं, तो code bloat का average user पर कितना बड़ा असर पड़ता है, यह चूकना आसान है
https://infrequently.org/2024/01/performance-inequality-gap-...
caching download और decompression की power/time cost घटाती है, लेकिन actual usage cost खत्म नहीं करती
मेरे निजी rule of thumb के हिसाब से, uncompressed JavaScript जितना बड़ा होता है, mouse हिलाने, key दबाने या scroll करने पर CPU द्वारा लगातार चलाया जाने वाला code उतना ज़्यादा होता है
थोड़ा time efficiency छोड़कर power efficiency पाना बेहतर है, और जहाँ CSS से काम चल सकता है, वहाँ fancy behavior की बजाय static चीज़ों को prefer करता हूँ
या फिर असली बड़ा मुद्दा वे sites हो सकती हैं जो click से URL को दूसरी page पर ले जाने के अलावा भी कई actions में और files download करती हैं। यह hidden bloat है और archiving के लिए भी बहुत खराब है
मैं नहीं चाहता कि JavaScript address bar का URL वही रखकर कोई और “page” दिखाए। यह भी archiving के लिए वाकई खराब है
एक और rule of thumb यह है कि uncompressed JavaScript जितना बड़ा होगा, archived site version के ठीक से चलने की संभावना उतनी कम होगी
पिछले हफ्ते internet धीमा था; GitHub website पर file click करने पर वह script से load करने की कोशिश करता और fail हो जाता, इसलिए file tree literally काम नहीं कर रहा था
इसके बजाय file URL copy करके browser address bar में paste करने पर वह ठीक से load हो गया
Spotify में network connectivity की बड़ी समस्या है। album download कर लो, फिर भी network बदलते ही यह पूरी तरह panic में चला जाता है। लगातार online रहने की कोशिश से बेहतर है कि बस offline mode हो
उसे देखकर पूरी architecture को judge करना मुश्किल है; यह कुछ वैसा ही है जैसे किसी बहुत खराब SPA की ओर इशारा करके कहना कि सारे SPA खराब हैं
हर software अपने बनाने वाले organization की शक्ल को दर्शाता है
भेजे जा रहे data का बड़ा हिस्सा शायद page के behavior के लिए सच में जरूरी JavaScript नहीं, बल्कि analytics tools और तरह-तरह की third-party scripts है
सिर्फ “elephant” category ही React जैसे lazy-loading modules से मेल खाती है
इनमें से काफी कुछ marketing teams चला रही होती हैं, जिन्हें इस समस्या का पता नहीं होता या वे इसकी परवाह नहीं करतीं
Developers ने अक्सर बस Google Tag Manager या कोई दूसरी script-injection service page पर लगा दी होती है। कुछ मामलों में developer ने वह भी नहीं किया होता, बल्कि operations infrastructure का proxy page को modify कर देता है
ज्यादा अहम चिंता यह हो सकती है कि output पर असल काम करने वालों से ज्यादा marketing का control है
“elephant” pages के मामले में bloat organization के अंदर ही है। यह कुछ बेवकूफों की नहीं, बल्कि scale किए गए बेवकूफों की समस्या है
पिछली नौकरी में non-technical department के पास Google Tag Manager था, और production pages में inject होने वाले कचरे पर लगातार नजर रखनी पड़ती थी
इसे हटवाने के लिए मैंने सच में बहुत लड़ाई लड़ी
Search में Google, Yahoo से ऐसा था, और Chrome भी launch के समय IE/Firefox से ऐसा था
Chrome में खुद लगभग कोई UI नहीं था, और वही उसका feature था
हाल ही में New Zealand road trip से लौटा हूं, और rural areas के बड़े हिस्से में mobile signal बहुत कम या बिल्कुल नहीं है
Roaming के साथ यह एक और layer धीमा महसूस होता है, इसलिए web का बड़ा हिस्सा इस्तेमाल करना वाकई मुश्किल था
अगर कोई Spotify PM है तो offline UX की समीक्षा करे। Offline premium की core features में से एक है, लेकिन सच में app को offline इस्तेमाल करने की कोशिश करें तो कई मायनों में बहुत खराब है
Spotify अगर मान लेता है कि internet है, तो हर context menu की सामग्री server से पूछता है, कुछ seconds तक response का इंतजार करता है, और कभी menu दिखाना छोड़ देता है तो कभी उस action पर वापस चला जाता है जो offline mode होता तो तुरंत हो जाता
मुझे यह player सच में नापसंद है
बहुत ज्यादा latency या बहुत loss वाले बीच के states में असल में offline जैसा behave करना चाहिए, लेकिन Spotify खुद को online समझता है
हालांकि यह समस्या बहुत आम है और सिर्फ Spotify ही fail नहीं करता; सही thresholds तय करना कठिन होगा
समझ नहीं आता कि signal न होने पर Spotify app को कुछ load करने के लिए 30 seconds तक क्यों इंतजार कराता है। मैं बस अपने downloaded podcasts सुनते रहना चाहता हूं
जानना चाहता हूं कि कौन-सा engineering decision ऐसे scenarios की weighting को इतना जटिल बना देता है
यह लेख खास तौर पर इस बात को पूरी तरह miss करता है कि real web applications में JavaScript files इतनी बड़ी क्यों होती हैं, इसे खोलकर नहीं देखता
उदाहरण के लिए Google Translate को detail में देखें तो यह ऐसा app नहीं है जिसमें एक बार interaction करके काम खत्म हो जाए। इसमें dictionary, alternative suggestions, transliteration, pronunciation, कई input methods वगैरह हैं
यह सब मानकर भी 2.5MB बहुत बड़ा है, और कुछ optional features lazy-load किए जा सकते हैं और करने चाहिए, लेकिन मौजूदा लेख इतना lazy है कि गहरी चर्चा में ज्यादा मदद नहीं करता
if data.transliteration show icon with audio embedके लिए कितनी JavaScript चाहिए होगी?Images बड़ी और ज्यादा हो सकती थीं, यह समझ आता है, लेकिन थोड़ा ironic था
यहां implication यह है कि “JavaScript बहुत ज्यादा है”, यह समझ आता है, लेकिन यह भी बात करनी चाहिए कि इसका कितना हिस्सा pure tracking कचरा है
इससे भी बुरा यह है कि उनमें से कुछ host code से bundled नहीं होतीं, बल्कि external sources से आती हैं, जिससे latency और संभावित security risks बढ़ते हैं
यह ऐसा tool था जो marketers को developer intervention के बिना web application में कोई भी कचरा inject करने देता था
रिश्ते भी थोड़े खराब हुए, मैं जीत भी नहीं पाया, और performance अब भी खराब है
उसके बाद performance problems पैदा करने वाली चीजें maps और charts जैसी भारी libraries होती हैं, और आमतौर पर smart lazy loading से हल हो जाती हैं
खुद देखे मामलों में, बहुत छोटे feature के बावजूद startup पर QR code scanning library और map library load करना; startup पर सभी internationalization strings को waterfall requests में लाकर किसी भी JS के run होने से पहले block कर देना; और Zendesk द्वारा page performance पूरी तरह खराब कर देना, लेकिन ऊपर से आदेश होने के कारण सिर्फ lazy-load ही लगा पाना शामिल है
इसके बाद खराब design वाला code आता है जो बहुत ज्यादा DOM elements, re-rendering या waterfall requests करवाता है
आखिर में app-level code size आता है, जिसे भी lazy loading से ठीक किया जा सकता है, लेकिन application बहुत विशाल होने से पहले आमतौर पर इसकी जरूरत नहीं होती
उदाहरण के लिए GitLab landing page tracking scripts block करते ही 13MB से “सिर्फ” 6MB रह गया
Marketing department हमेशा software bloat को दोगुना करेगा
यह तुलना है कि popular sites cold load पर कितना JavaScript load करती हैं। मुख्य points ये हैं
PornHub, YouTube की तुलना में लगभग 10 गुना कम JS load करता है (1.4MB बनाम 12MB)
Gmail का footprint समझ से परे बड़ा है (20MB). Fastmail 10 गुना हल्का, 2MB है, और Figma उससे अधिक complex app होने के बावजूद लगभग वही 20MB है
Jira का 58MB होना तो बहुत ज़्यादा है
Jira एक बार download होने के बाद update तक offline app की तरह locally load होगा
Pornhub के incognito mode में चलने की संभावना ज़्यादा है, इसलिए cache मदद नहीं करता
Jira भी भयानक और धीमा है
https://wordsandbuttons.online/ की सभी pages animations और interactions होने के बावजूद अभी भी 64KB से कम हैं
उदाहरण के लिए यह page https://wordsandbuttons.online/trippy_polynomials_in_arctang... 51KB है
code भी बिल्कुल किफायती नहीं है। 80% थोड़ा-थोड़ा अलग copy-paste है, और clever तरीके से घटाने की कोई कोशिश भी नहीं। सब पुराना vanilla JS है, compression या whitespace removal भी नहीं
“View page source” से खोलें तो code पूरी तरह पढ़ने लायक हालत में है
राज़ zero-dependency policy है। न third-party dependency, न internal dependency। जितना code चाहिए, सब HTML file के साथ ही मिलता है
विडंबना यह है कि लंबे समय में copy-paste bloat का कारण नहीं, बल्कि उससे बचाव है
mobile पर edges सचमुच दिखाई नहीं देते
dependency खुद कारण नहीं, symptom है। websites और companies के पास अब bloat घटाने का incentive नहीं रहा, इसलिए duplicate dependencies लगभग कभी साफ नहीं की जातीं
2015 का The Website Obesity Crisis लेख [1] याद आता है। उसके बाद [2] स्थिति और खराब हो गई, और अब लगभग 10 साल बीत चुके हैं
क्या यह कहना बेवकूफी होगी कि अगले 10 साल में 2015 के आसपास के PC से web browsing असंभव हो जाएगी? अगर कुछ नहीं बदला तो ऐसा ही लगता है
2013 के पुराने MacBook पर latest Firefox डालने पर भी https://civitai.com page का 23.98MB JavaScript संभलता नहीं, और इस भयावह web frontend को render करने की कोशिश में लगभग 30 सेकंड तक freeze हो जाता है
यह सिर्फ web की समस्या नहीं है। mobile all-in-one apps भी इतनी बड़ी हो गई हैं कि 2013 के phone पर वे भी load नहीं होतीं, और उनमें से आधी web technology stack पर लिखी हैं
समझ नहीं आता कि बड़े budget वाली companies native applications afford क्यों नहीं कर पातीं
[1] https://idlewords.com/talks/website_obesity.htm
[2] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
web की हालत बहुत दुखद है
fiber connection इस्तेमाल करने वाले ज़्यादातर लोगों को यह महसूस भी नहीं होता कि web कितना धीमा हो गया है
लेकिन अगर आप अभी भी 2Mbps connection पर हैं, तो यह सच में भयानक है। मैं ऐसी ही स्थिति में हूँ, और यह तकलीफ़देह है
इसलिए ad/tracking blocker इस्तेमाल न करना तो सोचा भी नहीं जा सकता
Ublock Origin चालू रखकर यह test देखना चाहूँगा
इस code का ज़्यादातर हिस्सा शायद user tracking और ad management के लिए होगा
बेहतर और तेज़ computers और network speeds मिलने के बावजूद apps और websites को लगातार छोटा बनाने पर ध्यान देना चाहिए—यह सोच मुझे समझ नहीं आती
Moore’s law की वजह से developers optimality की कुर्बानी देकर और ज़्यादा push करते हुए तेज़ी से आगे बढ़ सके, और ऐसा अक्सर हुआ है