धीमे डिवाइस इस्तेमाल करने वाले यूज़र्स पर वेब ब्लोट का असर

• 2017 के बाद bandwidth में हुई बढ़ोतरी ने आम साइटों के transfer size में बढ़ोतरी को कुछ हद तक पीछे छोड़ दिया, लेकिन web apps की CPU requirements low-end डिवाइसों के performance से तेज़ी से बढ़ीं, जिससे तेज़ इंटरनेट पर भी वेब accessibility खराब हुई
• 1Gbps connection पर भी Tecno Spark 8C में Discourse forum पर browser crash हुआ, और Itel P32 पर Discourse, Reddit, Shopify, Substack, Wix, Mastodon, Bluesky जैसी साइटें FAIL या व्यावहारिक रूप से इस्तेमाल न करने योग्य रहीं
• measurement में M3 Max, M1 Pro, Chrome 10x CPU throttling, Tecno Spark 8C, Itel P32 पर LCP* और main thread CPU time की तुलना की गई; PageSpeed Insights score का वास्तविक महसूस होने वाली speed से कमजोर संबंध था
• MyBB, phpBB, पुराने WordPress, HN, danluu.com जैसी सरल या पुरानी साइटें low-end mobile पर भी अपेक्षाकृत अच्छी चलीं, जबकि Discourse, Medium, Reddit, Substack जैसी ज़्यादा dynamic loading वाली साइटों में scrolling, search और tap delay साफ दिखे
• Nigeria, India, Latin America जैसे क्षेत्रों में low-end डिवाइस इस्तेमाल करने वाले लोग वास्तविक web users हैं, और अगर वेब सिर्फ iOS और तेज़ इंटरनेट को आधार बनाकर बनाया जाए तो कम संपन्न users और low-spec desktop users भी बाहर छूट जाते हैं

---

bandwidth से ज़्यादा CPU bottleneck बना वेब

• 2017 में slow connections पर web bloat ने usability को बहुत नुकसान पहुंचाया था, और उसके बाद high-end connections की bandwidth Nielsen के हिसाब से सालाना करीब 50% की दर से तेज़ी से बढ़ी
• slow internet इस्तेमाल करने वाले users अब भी बहुत हैं और modern web का बड़ा हिस्सा slow connections पर इस्तेमाल करना मुश्किल है, लेकिन सामान्य साइटों में bandwidth growth ने transfer size growth को कुछ हद तक पीछे छोड़ा है
• इसके उलट web apps की CPU performance requirements bandwidth जितनी तेज़ी से बेहतर नहीं हुईं, इसलिए अच्छी internet connection होने पर भी low-spec devices पर web इस्तेमाल करना मुश्किल हो गया
• Discourse आधारित “modern” forum Tecno Spark 8C पर browser crash तक करा देता है, और crashes के बीच responsiveness भी 8 MHz 286 और 1200 baud modem से BBS इस्तेमाल करने से खराब मापी गई
• Discourse में message titles लाने वाला compressed payload 2.6 MB है, जो पुराने समय की तुलना में transfer amount में 1000x बढ़ोतरी जैसा है, लेकिन 1Gbps connection पर यह अपेक्षाकृत हल्का है
• CPU के लिहाज़ से, 8-core (2 1.6 GHz Cortex-A75 / 6 1.6 GHz Cortex-A55) वाला Tecno Spark 8C भी Discourse को संभाल नहीं पाता, जबकि यह CPU 286 से लगभग 100000x तेज़ है

measurement targets और metrics

• test devices थे M3 Max Macbook (14-core), M1 Pro Macbook (8-core), Chrome DevTools में 10x throttled M3 Max, Tecno Spark 8C, Itel P32
• network को devices के पक्ष में रखने के लिए 1Gbps internet और load के दौरान low latency के लिए benchmark किए गए WiFi router का इस्तेमाल किया गया
• comparison targets में blogs/microblogs, forums, और small business platforms शामिल थे
  • blogs/microblogs: danluu.com, Substack, Medium, Ghost, Hugo, Tumblr, Mastodon, Twitter, Threads, Bluesky, Patreon
  • forums: Discourse, Reddit, Quora, vBulletin, XenForo, phpBB, MyBB
  • small business platforms: Wix, Squarespace, Shopify, WordPress
• मुख्य metrics थे transfer compressed size (wire), decompressed size (raw), LCP*, main thread CPU time
• LCP* Chrome द्वारा measured Largest Contentful Paint नहीं है; जब बड़ा screen update user के लिए उपयोगी न हो, तब वास्तविक उपयोगी content दिखने के समय को आधार बनाया गया
• CPU time Core Web Vital नहीं है, लेकिन slow devices पर users को महसूस होने वाली usability से मजबूत जुड़ा एक सरल metric के रूप में इस्तेमाल किया गया

table से दिखी usability gap

• danluu.com और HN सभी test devices पर तेज़ चले
  • danluu.com ने 6kB wire / 18kB raw, Tecno Spark 8C पर 0.4s LCP* / 0.3s CPU
  • HN ने 11kB wire / 50kB raw, Tecno Spark 8C पर 0.5s LCP* / 0.5s CPU
• पुराने PHP-based forums slow devices पर modern forums से कहीं बेहतर रहे
  • MyBB ने Tecno Spark 8C पर 0.8s LCP* / 0.8s CPU
  • phpBB ने 1.7s LCP* / 1.5s CPU
  • vBulletin ने 4.4s LCP* / 4.8s CPU
  • Discourse ने 15s LCP* / 26s CPU, और Itel P32 पर FAIL
• blog platforms में भी पुराना WordPress theme low-spec devices पर Medium और Substack से बहुत तेज़ था
  • WordPress(old) ने Tecno Spark 8C पर 0.7s LCP* / 1.7s CPU
  • Medium ने 2.8s LCP* / 33s CPU
  • Substack ने 14s LCP* / 14s CPU
• कई modern sites Itel P32 पर fail हुईं या व्यावहारिक रूप से unusable थीं
  • XenForo, Mastodon, Bluesky, Wix, Substack, Shopify, Discourse, Reddit ने FAIL
  • Threads ने 28s LCP* / 66s CPU, Twitter ने 24s LCP* / 43s CPU, Medium ने 3.2s LCP* / 63s CPU
• 10s+ CPU लेने वाले pages load के बाद भी खराब experience देते हैं
  • scrolling कुछ FPS तक गिर जाती है, tap delay इतना लंबा होता है कि user को पता लगाना मुश्किल हो जाता है कि tap registered हुआ या नहीं
  • दोबारा tap करने पर पहला tap देर से registered होने के बाद दूसरा tap गलत action करा सकता है

वास्तविक devices और CPU throttling का अंतर

• Chrome DevTools का CPU throttling सुविधाजनक है, लेकिन असली slow devices के results को consistently approximate नहीं कर पाता
• M3/10 और Tecno Spark 8C की तुलना में site-by-site अंतर काफी अलग थे
  • danluu.com और Ghost का approximation कुछ हद तक ठीक था
  • Medium, Substack, Twitter पर Tecno Spark 8C का CPU time करीब 3x धीमा था
  • Reddit और Discourse करीब 4x धीमे थे
  • Shopify में Tecno Spark 8C ने M3/10 से एक order of magnitude से भी ज़्यादा तेज़ result दिखाया
• slow pages, device धीमा होने पर कई बार superlinear तरीके से और धीमे हो जाते हैं, और एक page की slowness दूसरे page की slowness को ठीक से predict नहीं करती
• Discourse, Medium, Reddit M3 और M1 पर CPU ज़्यादा इस्तेमाल करते नहीं दिखते, लेकिन Tecno Spark 8C पर सबसे धीमे समूह में आते हैं
• Reddit बिना किसी interaction के इंतज़ार करने पर भी ~90% CPU इस्तेमाल करता है, इसलिए CPU ∞ के रूप में दिखाया गया

पुरानी sites और simple pages की ताकत

• पुरानी sites आम तौर पर latest sites से तेज़ थीं, और 10–20 साल में visually बहुत कम बदली sites सबसे तेज़ समूह में रहीं
• MyBB, Discourse से M3 पर 3.6x / 5x, Tecno Spark 8C पर 19x / 33x तेज़ था
• WordPress(old), Medium से M3 Max पर 17.5x / 10x, Tecno Spark 8C पर 4x / 19x तेज़ measured हुआ
• Ghost, Medium से 1 साल बाद launch हुआ modern platform है, लेकिन पुराने platforms से compete करने लायक performance दिखाने वाला exception है
• appendix test में NodeBB भी modern forums में exception के करीब था
  • M1 पर 0.3s / 0.4s
  • Tecno Spark 8C पर 3.4s / 7.2s
  • Discourse से बहुत तेज़, और load के बाद scrolling और taps भी मूल रूप से काम करते हैं

dynamic loading और metric optimization के जाल

• Discourse, Reddit, Substack जैसी sites जो page का एक हिस्सा पहले load करती हैं और बाकी dynamically लाती हैं, उनकी वास्तविक usability table scores से भी खराब है
• slow devices पर scroll distance predict करना मुश्किल होता है, और बहुत दूर scroll करने पर additional loading trigger होकर page freeze हो सकता है
• scrolled past content हटाने वाले pages slow devices पर व्यावहारिक रूप से unusable हैं
• dynamic loading pages पर browser के तेज़ Ctrl/Command+F search को सीधे इस्तेमाल करना मुश्किल होता है और अपना search implement करना पड़ता है
  • Google Docs search पिछले कुछ महीनों या करीब एक साल से document load होते ही तुरंत इस्तेमाल करने लायक नहीं रहता, क्योंकि यह देर से load होता है
  • Discourse search slow devices या बहुत तेज़ न होने वाले devices पर कभी ठीक से काम करता नहीं दिखा
• theoretical तौर पर initial CPU work बाद की interactions को तेज़ बना सकता है, लेकिन test किए गए pages में initial load, subsequent load और load के बाद interactions सभी धीमे थे

LCP gaming

• LCP मूल रूप से यह अनुमान लगाने का metric है कि user को page का main content कब दिखता है, लेकिन Chrome measurement ज्यादा इस बात के करीब है कि screen पर बड़ा paint कब हुआ
• कुछ sites user के लिए उपयोगी न होने वाली बड़ी loading screen जल्दी दिखाकर LCP घटाती हैं, और बाद में वास्तविक content को छोटे updates में बांट देती हैं ताकि वह LCP में न पकड़ा जाए
• Discourse ने Discourse Splash को public तौर पर introduce किया, और बताया कि slow load में बड़े splash screen से LCP काफी घटा
• Discourse का official response इस आशय का था कि अगर वास्तविक content banner splash से बड़ा हो, तो LCP के लिए नुकसानदायक होगा
• उपयोगी content आधारित LCP* और Chrome measured LCP में बड़ा अंतर दिखाने वाले cases Wix और Discourse थे
  • Wix: M3 पर 6x, M1 पर 12x, Tecno Spark 8C पर 3x
  • Discourse: M3 पर 10x, M1 पर 12x, Tecno Spark 8C पर 4x

performance optimization का business पर असर

• बड़ी companies में sites और apps की performance improvements की monetary value इतनी बड़ी थी कि उसे A/B tests से measure किया जाता था
• long-term holdback में भी performance improvement growth और retention पर अपेक्षाकृत बड़ा असर डालने वाला intervention दिखा
• Twitter पर user-observed p99 latency India और कई African countries के साथ United States में भी करीब 60s थी
• हर देश में slow devices या connections वाले users पर्याप्त संख्या में हैं, इसलिए limiting factor पूरी आबादी के average device/connection distribution से ज़्यादा user patience के करीब था
• slow devices पर 60s को 50s करने वाला improvement high-end device users के लिए भी 5s को 4.5s करने जैसा असर डाल सकता है, और revenue, growth, retention को भी प्रभावित करता है

low-end devices को ध्यान में रखकर design

• slow devices या low bandwidth/unstable connections पर बहुत सारा content एक बार में static page के रूप में load करने का experience आम तौर पर सबसे अच्छा होता है
• images में उचित width, height, alt attributes होना मददगार है, लेकिन progressive JPEG खास बड़ी मदद नहीं करता
• तेज़ connection वाले slow devices पर हल्के static pages अच्छे चलते हैं, और performance-conscious हल्के dynamic pages भी चल सकते हैं
• भारी pages में scroll करने पर additional loading और search interception usable interaction model को बिगाड़ देते हैं
• Substack में iPhone 8 पर article का LCP तेज़ हो सकता है, लेकिन header के नीचे scroll करने के लिए अगला page load होने का 6s इंतज़ार करना पड़ता है और उसके बाद भी 1s~2s रुकना पड़ता है—ऐसे cases हैं
• उलटा उदाहरण: बड़े plain HTML pages low-end devices पर भी अपेक्षाकृत अच्छे चलते हैं
  • https://danluu.com/diseconomies-scale/ 0.1 MB wire / 0.4 MB raw
  • https://danluu.com/threads-faq/ 0.4 MB wire / 1.1 MB raw
  • 1.1 MB text का एक page slow devices पर अधिकांश modern sites से बेहतर चलता है
• Zig standard library documentation source code को शुरुआत में पूरा fetch करके locally render करता है, फिर भी Tecno Spark 8C पर 4.7s CPU use के बाद अपेक्षाकृत responsive रहता है

low-income users और accessibility

• Tecno Spark 8C Nigeria में करीब USD 50-60, India में करीब USD 100-110 में मिल सकता है, लेकिन इन क्षेत्रों के median household income के अनुपात में यह United States के current-generation iPhone से कहीं बड़ा खर्च है
• वैश्विक मानक से Tecno Spark 8C सबसे सस्ते devices के करीब नहीं है, और Itel P32 भी वास्तव में इस्तेमाल होने वाले lowest-spec devices की तुलना में ऊंचे group में है
• Alex Russell के अनुसार iOS share India में 7%, Latin America में 6% है
• Windows telemetry के आधार पर अधिकांश laptop/desktop users ऐसे low-spec devices इस्तेमाल करते दिखते हैं जिनके latest iPhone से धीमे होने की संभावना ज्यादा है
• सुधारात्मक निगरानी में लोगों को दिए जाने वाले “lifeline” phone में iPhone 6 या iPhone 8 भी होते हैं, लेकिन Itel P32 से कमज़ोर devices भी बहुत हैं, और data limits कम होने से limit खत्म होने के बाद job search, welfare forms भरना या Maps इस्तेमाल करना मुश्किल हो सकता है
• mobile apps अच्छे connection पर पहले से download की जा सकती हैं, लेकिन web apps को अगर हर access पर कई MB compressed JavaScript डाउनलोड करनी पड़े, तो वे limited connections पर इस्तेमाल नहीं की जा सकतीं

experiment conditions और limitations

• हर site को संभव “सबसे basic” experience खोजने के तरीके से measure किया गया
  • WordPress में current default theme twentytwentyfour demo इस्तेमाल किया गया
  • Shopify में theme list में पहले दिखे theme का इस्तेमाल किया गया
  • Discourse, vBulletin, XenForo, phpBB, MyBB के लिए official forum के रूप में search किए गए pages इस्तेमाल किए गए
• यह काम एक दिन के भीतर data collection और analysis वाले छोटे project के रूप में किया गया, इसलिए इसमें सबसे common themes या actual user customization distribution तक reflect नहीं हुए
• laptops को लगभग 60% battery, unplugged, 20°C room में thermal equilibrium के करीब रखकर test किया गया
• mobile को लगभग 100% charge पर, plugged in, बिना दूसरे apps और tabs के test किया गया
• वास्तविक users को उसी device पर भी ज्यादा apps और background tasks के कारण अधिकतर खराब performance दिखने की संभावना है
• sizes mobile पर measured थे, इसलिए mobile और desktop को अलग assets मिलने पर mobile asset size reflect हुआ
• CPU को main thread CPU time के रूप में measure किया गया; other thread time recorded था लेकिन metric में इस्तेमाल नहीं हुआ

site-specific notable cases

• Wix में Tecno Spark 8C पर scrolling ठीक से stable नहीं होती, और Itel P32 पर nondeterministically fail होती है
• Patreon में initial load numbers की तुलना में scrolling performance खराब है, इसलिए पुराने posts ढूंढना इतना असुविधाजनक है कि अलग Patreon post index maintain करना पड़ता है
• Discourse में LCP बहुत ज्यादा gamed है; M3 Max के 1Gbps connection पर भी Chrome measured LCP 115ms था, लेकिन actual content 1.1s में load हुआ
• Bluesky ने Itel P32 पर blank screen दिखाई
• Shopify के पहले दो real-world use cases test किए गए demo page से दोनों काफी धीमे थे
• Tumblr में Itel P32 पर JavaScript error आता है, लेकिन उसी वजह से page जल्दी load होता है और scrolling/link click काम करते हैं
• MyBB mobile version नहीं देता, जिससे Google में नुकसान हो सकता है, लेकिन slow mobile पर scrolling और taps असल में अच्छी तरह काम करते हैं
• Woo Commerce को सिर्फ initial load performance के आधार पर Shopify से compare करना मुश्किल है, और cart/checkout जैसे real flows तक शामिल करके अलग comparison चाहिए, इसलिए उसे table से बाहर रखा गया

[GN⁺]

Hacker News की रायें

• हाल ही में अपेक्षाकृत धीमा Android फोन इस्तेमाल करके देखा, तो टेक्स्ट और इमेज भर दिखने वाले वेबपेज भी लोड होने में सचमुच तकलीफदेह हो सकते हैं
  असली bottleneck नेटवर्क नहीं, बल्कि trackers, ads और JavaScript bloat के करीब है
  धीमे पुराने फोन पर मोबाइल Firefox जैसा पूरा browser खुद ही बहुत भारी पड़ता है, इसलिए Firefox Focus जैसे हल्के browser का इस्तेमाल करना पड़ता है; लेकिन extensions नहीं चलतीं, इसलिए uBlock Origin भी नहीं चलता और web experience और खराब हो जाता है
  कुछ sites “standard” browser न होने पर शिकायत करती हैं और unusable हो जाती हैं, और कंपनियां इसके बजाय app install करने पर मजबूर करती हैं
  पहले धीमे devices और connections के लिए simplified versions होते थे, लेकिन वे धीरे-धीरे गायब हो रहे हैं; शायद इसलिए कि JavaScript bloat के बिना ads और tracking network चलाना मुश्किल है

  • ad blocking के बिना modern web बेकार है—यह सचमुच पूरी तरह फंसी हुई स्थिति है
    अंतहीन scroll होने वाले pages में random ads ठुंसे हों तो हालत खासकर और खराब होती है
  • standard browser इस्तेमाल करने पर भी कंपनियां कभी-कभी जानबूझकर website खराब कर देती हैं ताकि लोग app इस्तेमाल करें
    हाल का उदाहरण: Nike webshop ने checkout के दौरान बेकार-सा error दिखाया, और support team ने बस “app try कीजिए” कहा
    यूरोपीय airline booking sites भी बड़ी कंपनियों की websites के बार-बार टूटने के प्रतिनिधि उदाहरण हैं
    2024 में लगभग असीमित resources होते हुए भी काम करने वाली website न बना पाना brand पर बुरा असर नहीं डालता—ऐसा सोचना अजीब है
  • उन apps में भी दस में से नौ बार website की किसी आंशिक offline copy वाला browser shell ही होने की संभावना ज्यादा है
  • 10 साल पहले जब nokia.com की main site का code लिख रहा था, तो resources धीमे load हो रहे हैं या नहीं, यह कई तरीकों से detect करके extra features बंद करने वाला flag set किया था
    उसे हर देश में काम करना था, और सबसे धीमे phones में से कई उसी कंपनी के products थे
  • मेरे पास अब भी 2013 का MacBook Pro है, क्योंकि वह Apple का बनाया सबसे अच्छा keyboard है, इसलिए उसे संभालकर रखा है
    वह तेज नहीं है, लेकिन websites इस्तेमाल करने में दिक्कत नहीं होती; नए hardware जितना instant नहीं है, पर पूरी तरह usable है
    हालांकि uBlock Origin इस्तेमाल कर रहा हूं
    सोचता हूं क्या ये Android devices सच में 11 साल पुराने base-spec MacBook से भी कमजोर हैं

• Dan की इस मुख्य बात से मैं काफी सहमत हूं कि हमें दुनिया भर में inequality levels को ध्यान में रखना चाहिए, लेकिन Latin America और Southeast Asia जैसे middle-income देशों को भी शामिल करना चाहिए
  उदाहरण के लिए कुछ users के पास महीने का data cap single-digit GB में होता है, और RAM/CPU 10 साल पहले के US flagship स्तर का होता है
  ऐसा नहीं कि वे Discourse बिल्कुल इस्तेमाल न कर सकें, लेकिन experience अप्रिय रूप से धीमा होने की संभावना ज्यादा है
  मुझे लगता है Dan ने CPU/RAM/disk में incremental improvements से participation measurable तरीके से बढ़ता है, यह मुख्यतः इसी user group की वजह से देखा
  Dan के charts से दिखता है कि Itel P32 जैसे सबसे सस्ते devices इस्तेमाल करने वालों को incremental optimization से खास फायदा नहीं मिलता
  जो मदद कर सकता है वह है पूरी तरह अलग client architecture: features और polish की कुर्बानी देकर जितना संभव हो उतना पतला code देना, यानी कोई वैकल्पिक lite/basic mode
  हालांकि ऐसे approaches अक्सर सफल नहीं हुए, क्योंकि US developers performance के लिए क्या रखना और क्या हटाना है, इसका गलत अंदाजा लगाते हैं—यानी empathy problem फिर सामने आ जाती है

  • समझ नहीं आता कि इसे “वैकल्पिक” choice क्यों होना चाहिए
    मौजूदा Discourse आखिर PhpBB या DLang forum से ऐसा क्या देता है?
    mobile-friendly design छोड़ दें तो, किसी सामान्य दुनिया में responsive CSS की कुछ lines बदलना ही काफी होना चाहिए
  • मैं एक गरीब Southeast Asian देश में रहता हूं, और छोटे data plans इस्तेमाल करने वाले लोग data इसलिए नहीं बचाते कि websites efficient हैं; वे हर जगह मौजूद Wi‑Fi इस्तेमाल करते हैं
    महीने का 30GB data $3.64 का है, और minimum wage के हिसाब से करीब 4–6 घंटे के बराबर है
    ज्यादा अहम बात यह है कि लोग Western countries की तरह data अंधाधुंध इस्तेमाल नहीं करते
    cafés, restaurants, supermarkets, shopping malls—हर जगह free Wi‑Fi है, और ज्यादातर लोग menu से पहले Wi‑Fi password पूछते हैं
    मैंने कभी देखा या सुना नहीं कि websites data बहुत जल्दी खत्म कर देती हैं
    यह ऐसी चिंता लगती है जो उन लोगों ने बनाई है जिन्होंने विकासशील देशों में सचमुच रहकर नहीं देखा
    यहां data खत्म होता है तो वजह TikTok, Instagram, Facebook पर videos देखना है, website bloat नहीं
  • अगर सभी sites अधिक efficient हों, तो non-technical users को “computer धीमा हो गया है, नया खरीदना पड़ेगा” महसूस होने का समय देर से आएगा, और laptops और PCs की उम्र भी बढ़ सकती है
    computer के साथ install होने वाला bloatware भी इसी तरह है
    हाल ही में नया laptop खरीदा, तो $50 की “tuning” offer की गई
    कल्पना कीजिए कि कोई new car dealer ऐसा offer करे—अजीब लगेगा
  • एक generation पुराने iPhone पर भी इनमें से कुछ sites सचमुच बर्दाश्त से बाहर हैं
    signal खराब हो तो समस्या 10 गुना बढ़ जाती है
    बात fixed headers और ads की वजह से screen का केवल एक-तिहाई हिस्सा दिखाने वाली complex UI की नहीं है, बल्कि ऐसी website के अपने size की है जिसे जैसे-तैसे तब तक मिलाया गया जब तक वह design document जैसी दिखने न लगे
    ठीक से बनाई गई होती तो भी पहले से bloated site धीमे internet connection पर unusable हो जाती है, धीमे hardware की तो बात ही छोड़िए
    बताई गई परिस्थितियों में internet इस्तेमाल करना कैसा लगता होगा, इसकी कल्पना करना मुश्किल है; बस उम्मीद है कि वे लोग अपनी bandwidth और devices के अनुकूल local sites इस्तेमाल करते हों और हमें झेलने वाला bloated garbage उन्हें न झेलना पड़े
  • मैं Canada में रहता हूं और मेरा data plan भी single-digit GB में था; अभी-अभी करीब 10 साल पुराने flagship से upgrade किया है
    ज्यादातर websites यातना जैसी हैं

• यह दिलचस्प है कि ज़्यादातर लोग सिर्फ़ बॉस या डरावनी बड़ी कंपनियों को दोष देते हैं
  डेवलपर यह मानने को तैयार नहीं होते कि कमज़ोर वेब प्रोग्रामर का भी एक बड़ा वर्ग है, जिन्हें efficiency की समझ कम है और वे समझना भी नहीं चाहते लगते
  खराब software बनवाने वाले बॉसों या corporate leadership जितने ही, ये लोग भी वेब software की इस दुखद दुनिया के लिए ज़िम्मेदार हैं

  • मैंने ऐसे लोगों के साथ काम किया है
    जब “output” यानी HTML, CSS, JS के ठोस हिस्सों के बारे में पूछा जाता, तो वे ऐसे देखते जैसे कोई दूसरी भाषा बोली जा रही हो
    वे JavaScript framework की दुनिया से आए थे और उसके नीचे बनने वाले output के बारे में ज़्यादा सोचा ही नहीं था
    मेरी philosophy लगभग उलटी है: मैं पूछता हूँ कि हाथ से अच्छे से लिखी गई HTML+CSS+JS website जैसा नतीजा देने वाला न्यूनतम maintainable code क्या होगा
    आम तौर पर output कई orders of magnitude छोटा हो जाता है
    उन्होंने पूछा कि मैंने 1000 table rows को real-time filter करते हुए भी mobile पर तेज़ load और अच्छी तरह काम करने लायक कैसे बनाया; मैंने कहा कि पहले request में पूरा data भेज दिया और filter से match न करने वाले data को बस dynamically hide किया
    webserver को बस वही cached data सबको देना था, और site पर चलने वाला JavaScript भी बस इतना ही था, इसलिए उन्हें यह अजीब तरह से तेज़ लगा
    उनके framework-based solution में वैसी ही table row HTML देखें तो उसका 80% ऐसा boilerplate था जो इस्तेमाल ही नहीं होता था
    web development बहुत जड़ हो गया है, और बहुत से लोग web technology के मूल से बहुत दूर भटक गए हैं
  • करीब 5 साल पहले, मैंने एक ऐसी company में apply किया था जो ग्रामीण अफ्रीका के लोगों को उनके बनाए सामान को आसानी से बेचने में मदद करती थी
    अगर मुख्य target US या EU users हों, तो low-end hardware और unstable low-bandwidth, high-latency connections के लिए बहुत ज़्यादा optimize न करना समझ में आ सकता है
    लेकिन अगर target ग्रामीण अफ्रीका हो, तो aggressive optimization स्वाभाविक लगता था
    फिर भी homepage 2MB की एक विशाल image load करता था, जिसे CSS से 500×1000 pixels तक घटाया गया था, और उसके बाद हालत और खराब थी
    सटीक JS payload size याद नहीं है, लेकिन वह कई MB का था; ज़्यादातर हिस्सा traditional template-based backend app जैसा दिखता था, फिर भी frontend बेहद भारी था
    concept अच्छा था इसलिए मैंने apply किया, लेकिन technology भयानक थी
    मैं पहले interview stage तक भी नहीं पहुँच पाया, इसलिए नहीं जानता कि ऐसा क्यों था, लेकिन यह कल्पना करना मुश्किल है कि Western Europe के developers को इस पहलू में ठीक से अंदाज़ा था कि वे क्या कर रहे हैं
  • “डरावनी बड़ी company” में काम करने के अनुभव से कहूँ तो ज़िम्मेदारी 100% उन्हीं की है
    शुरुआत developer से नहीं, budget से होती है
    अगर ऊपर के लोग technical समझ वाले या engineering background से नहीं हैं, तो वे आम तौर पर नई features के लिए budget रखते हैं, लेकिन maintenance और technical debt हटाने के लिए बहुत कम या बिल्कुल budget नहीं रखते
    maintenance budget हो भी तो वह लगभग पूरी तरह सस्ती overseas maintenance team को दे दिया जाता है
    feature team 6 महीने feature बनाती है, overseas maintenance team के साथ 1 घंटे का “KT session” करती है, और फिर code handover कर देती है
    overseas team के पास feature की कुछ जानकारी होती है, लेकिन existing technical debt manage करने लायक नहीं; वे बस आग बुझी रहे, इतना संभालते हैं
    organization में यह cycle 100~1000 बार दोहर जाए, तो frontend जो मूल रूप से अधिकतम 250,000 lines का होना चाहिए था, जल्दी ही 2 million lines का हो जाता है
    नई feature team में सबसे अच्छे engineers आएँ, तब भी उन्हें पहले से बने box के भीतर ही काम करना पड़ता है
    अगर mockup और elements match नहीं करते, तो mockup गलत हो सकता है, UI kit upgrade हुई हो सकती है, या existing UI kit refactoring की ज़रूरत हो सकती है, लेकिन उसके लिए budget नहीं होता
    इसलिए team को कहा जाता है कि component copy करो और अपनी feature के हिसाब से modify कर लो
    maintenance team को handover करते समय भी नई team existing feature work को छेड़ना नहीं चाहती, इसलिए उसे वैसा ही छोड़ देती है
    non-technical management को फर्क पता नहीं चलता, और सालों तक teams नई features फिट करने के लिए copy/paste दोहराती रहती हैं, नतीजतन codebase में “Button” नाम के 50 से ज़्यादा components बन जाते हैं
  • यह fair नहीं है
    अगर team में efficiency को महत्व देने वाला skilled developer हो, और वह अधिक efficient site के लिए push करे या शुरुआत से ही ज़्यादा efficient बनाए, तो page बेहतर हो सकता है
    लेकिन ज़्यादातर मामला incentives का है
    अगर management को परवाह नहीं है, तो programmer के efficiency बढ़ाने में समय लगाने के बजाय आधे समय में बस चीज़ चलाने लायक बनाकर backlog निपटाने को चुनने की संभावना ज़्यादा है
  • आम तौर पर खराब web software, खराब content के साथ आता है
    इसलिए धीमे devices कचरे से बचाने वाला बेहतरीन filter हैं

• मैंने हाल ही में 6 साल पुराने LG flagship से नए Galaxy पर switch किया, और performance का अंतर बहुत बड़ा था
  ऐसा नहीं होना चाहिए
  launch के समय वह बहुत high-end device था, इतना पुराना भी नहीं है, और अब भी नया जैसा काम करता है
  testing के लिए रखे Galaxy S9 भी वही संघर्ष करते दिखते हैं, तो यह सिर्फ़ मेरे phone की समस्या नहीं है
  काश test में Amazon भी शामिल होता
  मेरे अनुभव में Amazon website 4 साल से ज़्यादा पुराने mobile devices पर सबसे खराब में से है
  अपेक्षाकृत recent high-end mobile hardware पर भी, जिन sites पर मैं नियमित जाता था उनमें यह अकेली site थी जो लगभग इस्तेमाल लायक नहीं थी

  • 7 साल पुराने Snapdragon 835 वाले दो devices इस्तेमाल करके लगा कि RAM और नया Android version बड़ा फर्क डालते हैं
    LineageOS के साथ Android 14 चलाने वाला OnePlus 5 मैं daily use में रखता हूँ, और non-gaming tasks में user experience काफी ठीक है
    इस phone में 6GB RAM है, जो आज के mid-range phones जैसी है
    मेरी अकेली शिकायत यह है कि battery बदलनी पड़ी और phone खोलना झंझट है
    दूसरी तरफ, वही SoC लेकिन 4GB memory और Samsung modifications वाले stock Android 9 पर चलने वाला Galaxy S8 लगातार अटकता रहता है
    2GB memory का फर्क असर डाल सकता है, लेकिन दोनों phones का अंतर रात-दिन जैसा है
    मुझे नहीं पता Android 14 की memory management Android 9 से इतनी बेहतर है, या Samsung का धीमा और bloated software device को पीछे खींच रहा है
    जो भी हो, यह चिढ़ाने वाली बात है कि कई companies पुराने और low-end devices पर test नहीं करतीं
    अगर आप worldwide users को target कर रहे हैं, तो यह देखना चाहिए कि दुनिया के ज़्यादातर लोग latest flagship इस्तेमाल नहीं करते
  • सोचता हूँ कि Amazon पर JavaScript disable करके देखा है क्या
    असल में वह इतना खराब काम नहीं करता
    बेशक, मैं सहमत हूँ कि ऐसा करने की ज़रूरत होनी ही नहीं चाहिए
  • हाल ही में Brazil गया था, वहाँ मेरा नया phone हाथ से छीन लिया गया, और अब backup के तौर पर 4 साल पुराना phone इस्तेमाल कर रहा हूँ; सच कहूँ तो फर्क महसूस नहीं होता
    हालांकि Firefox में सारे ad blockers इस्तेमाल कर रहा हूँ, शायद उससे मदद मिलती है
  • मेरे पास Palm Phone है, और आज की तारीख में उस पर web browsing लगभग असंभव लगती है
  • latest iOS 16 वाले iPhone 8 पर Amazon में कोई समस्या नहीं है

• आज की तकनीक तकनीक से परिचित न होने वाले लोगों के प्रति भी बहुत उदासीन है
  मुझे लगता है कि smartphone इसका सबसे अच्छा उदाहरण हैं
  मैंने सच में बहुत से ऐसे लोगों को देखा है जो अपने device को मुश्किल से इस्तेमाल कर पाते हैं या बिल्कुल नहीं समझते, और उनके लिए यह सब काले जादू जैसा दिखता है
  सबसे बड़ी समस्या यह है कि ऐसी gesture navigation पर जरूरत से ज्यादा निर्भरता है, जो दिखाई नहीं देती, इसलिए मानो उसका अस्तित्व ही नहीं
  iPhone की gesture bar किसी तरह समझ में आ भी जाए, तो notification center या control center की अवधारणा नहीं होती
  ये लोग मूर्ख नहीं हैं, और दूसरे क्षेत्रों में मुझसे कहीं बेहतर हो सकते हैं
  तकनीक में समस्या मेहनत की कमी नहीं, बल्कि intuitive interface की कमी है

  • नया iPhone खरीदने पर भी उसके साथ documentation न आना मदद नहीं करता
    असली documentation देखने के लिए Apple site के documentation page तक जाना पड़ता है, और थोड़ा और खोजने पर एक page मिलता है जो बस मोटे तौर पर कुछ gestures दिखाता है जिन्हें और गहराई में जाने पर इस्तेमाल किया जा सकता है
    कौन सा gesture कब और कहाँ इस्तेमाल करना है, इसके लिए एक-वाक्य के उदाहरण से ज्यादा कुछ नहीं है
    यह भी सिर्फ operating system की बात है
    मुझे संदेह है कि कितने apps अपने app में gesture features कैसे इस्तेमाल होते हैं, यह समझाने वाली documentation साथ देते हैं
    https://support.apple.com/guide/iphone/learn-basic-gestures-...
  • मैंने ऐसे middle-aged और older लोगों को देखा है जो शायद cassette deck भी नहीं चला पाते और typewriter भी कठिन लगती
    वे निश्चित रूप से ऐसे devices के आसपास बड़े हुए थे
    इसलिए मुझे नहीं लगता कि यह सिर्फ modern technology की गलती है
  • बाहर से देखने पर, कम से कम चमकदार products वाले interfaces सबके लिए एक ही आकार वाली सोच से design किए जाते लगते हैं
    user को अपने लिए उपयुक्त design और interaction चुनने देने के बजाय, designer या product owner ऐसे व्यवहार करता है मानो वह जानता हो कि सभी users के लिए क्या सबसे अच्छा है
  • gesture navigation पर जरूरत से ज्यादा निर्भरता smartphone की समस्या नहीं, बल्कि iPhone-विशेष समस्या है
    Android से आने के बाद यह मेरी सबसे बड़ी शिकायतों में से एक थी
    back button कहाँ है, home button कहाँ है, और button खुद कहाँ हैं, समझ नहीं आता
    मुझे Apple का minimalism obsession सच में नापसंद है, और जब यह phone मर जाएगा तो मैं Android पर लौट जाऊँगा

• यह लेख desktop पर 48 साल के मेरे लिए मूल रूप से पढ़ना मुश्किल है
  developer tools में body में नीचे वाला जोड़ने पर यह पढ़ने लायक हो गया
  font-size: 18px;
line-height: 1.5em;
max-width: 38rem;
  इससे दिखता है कि यह कितना readable और सुंदर हो जाता है
  मैं Dan Luu के लेख बहुत पढ़ता हूँ, लेकिन हर बार मुझे इसी तरह बदलना पड़ता है
  गंभीरता से कहूँ तो, technologists, page को अधिक readable बनाने में सिर्फ 64 bytes और लगते हैं

  • मैं 53 साल का हूँ और चश्मा बनवाने का समय कम से कम 5 साल पार कर चुका हूँ, इसलिए अभी भी चश्मा नाक की नोक पर टिका रहता है और कभी-कभी angle भी मिलाना पड़ता है
    वह page लगभग ठीक था, बस CTRL + से zoom करना पड़ा
    वह page लगभग pure text है और interaction भी बहुत कम है
    आपके पास अपने use case के लिए समाधान है, और मेरे पास मेरा समाधान है
    दृष्टिबाधित reader भी अपने समाधान से access कर सकता है
    source simple होने की वजह से accessibility solutions भी reasonably simple हो जाते हैं
    मुझे लगता है Dan प्रभावी ढंग से communicate करना जानता है
    यानी चीजों को simple रखना, और यह assume न करना कि उसे जरूर आँखों से पढ़ा जाएगा
    आप display को अपने purpose के हिसाब से आसानी से बदल सकते हैं
    अगर यह display style पसंद नहीं है, तो पढ़ने से पहले खुद reformat कर सकते हैं
    एक तरह से Dan ने message को आसानी से manipulate किए जा सकने वाले simple text stream के रूप में दिया है
  • मुझे proposed change reasonable लगता है, लेकिन अगर Dan Luu ने खुद वह CSS rule डाल दिया होता, तो यहाँ low density और “excessive whitespace” पर दुख जताने वाली प्रतिक्रियाएँ आतीं
    Luu के readers कुल मिलाकर शायद अपेक्षाकृत unstyled approach पसंद करते हैं
  • सहमत नहीं हूँ
    user अपनी preference के अनुसार window size, font size, colors आदि बदल सकता है
    हर file के लिए अलग-अलग बदलना जरूरी नहीं होना चाहिए, और कई files पर लागू होने वाली user CSS file जोड़कर इस्तेमाल करने की अनुमति होनी चाहिए
  • font बहुत छोटा हो तो browser का default font size बदला जा सकता है
    यह Firefox के default settings page में है
    अगर website font-size: 18px; force करती है, तो browser में बड़ा font चुनने वाले user के लिए text उल्टा छोटा हो सकता है
  • न्यूनतम CSS जोड़नी चाहिए, इस बात से सहमत हूँ
    हालांकि browser का reader mode भी इस्तेमाल किया जा सकता है, और developer tools में कई steps करने के बजाय यह एक click में हो जाता है

• संदर्भ के लिए, Raspberry Pi 3 पर YouTube इस्तेमाल नहीं किया जा सकता
  पिछले 1 साल में ऐसा हुआ है; उससे पहले लगभग 10–15FPS पर वीडियो “देखे” जा सकते थे, जो वर्कशॉप में repair videos देखने के लिए पर्याप्त था
  जब Raspberry Pi Model B, यानी पहला मॉडल, लॉन्च हुआ था, तब वह repository में मौजूद 1080p वीडियो चला सकता था, YouTube देख सकता था और गेम भी खेल सकता था
  YouTube क्या कर रहा है, और बाकी services क्या कर रही हैं, समझ नहीं आता
  अगर जलवायु संकट और बदलाव को गंभीरता से लेना है, तो Google और Meta की ऐसी चालों को बहुत सख्ती से जांचना चाहिए
  मुनाफे के लिए CPU cycles जलाना—यानी तुरंत अंदाज़ा लगाऊं तो ad tech की वजह से low-power devices पर YouTube का खराब हो जाना—मीडिया में कड़ी आलोचना का विषय होना चाहिए, और भले ही पूरा user experience खराब हो, हमें अधिक efficient services इस्तेमाल करनी चाहिए

  • क्या यह hardware video decoding की कमी की वजह से भी हो सकता है?
    Pi3 में x264 hardware acceleration है, लेकिन YouTube ने कुछ समय पहले से दूसरा codec इस्तेमाल करना शुरू कर दिया था
  • YouTube निश्चित रूप से भारी होता जा रहा है
    2021 के शुरुआती Intel MacBook Air पर भी मध्यम load में वीडियो randomly रुक जाते हैं, जो पहले नहीं होता था
  • सारे data को देखें तो climate change में योगदान के लिहाज से client devices की energy consumption लगभग rounding error जैसी है
    climate change हल करने के लिए उस हिस्से पर हमला करना plastic straws या plastic bags पर ban लगाने जितना ही बेतुका है
  • site navigation के लिए Invidious इस्तेमाल करता हूं, और actual video एक script से देखता हूं जो obfuscation हटाकर असली stream URL निकालती है और उसे VLC को दे देती है
    एक और संदर्भ बिंदु के तौर पर, 10 साल पहले का YouTube उस hardware पर भी पूरी तरह ठीक चलता
    असली दोषी कुल मिलाकर web bloat है, और ज्यादा specific रूप से JS में आम हो चुके abstraction monsters हैं
    जो लोग “climate crisis” में बिल्कुल विश्वास नहीं करते, उनसे भी यह कहा जा सकता है कि समय के साथ craftsmanship और quality गायब हो गई है, जिससे यह अव्यवस्था पैदा हुई
    इसलिए मुझे लगता है कि political spectrum के हर हिस्से में लोग इस विषय पर सहमत हो सकते हैं
  • ऐसी watchdog संस्था चाहिए जो sites और per-user page weight को monitor करे और नाम सार्वजनिक करके शर्मिंदा करे
    यह Consumer Reports के तरीके से हो सकता है, या Nielsen ratings की तरह काम करने वाला कोई add-on हो सकता है

• वह Discourse वाला व्यक्ति इस बात का typical example है कि product को उस दुनिया के हिसाब से design किया जा रहा है जिसमें वह चाहता है कि वह मौजूद हो, न कि उस वास्तविक दुनिया के हिसाब से जिसमें हम रहते हैं
  Qualcomm SoC वाले devices अरबों की संख्या में मौजूद हैं, आगे भी मौजूद रहेंगे और बनते-बिकते रहेंगे
  जितनी भी शिकायत कर लें, यह नहीं बदलेगा
  इसे स्वीकार करना होगा और उन devices के लिए optimize करना होगा
  उन devices के users को developer की शिकायतों से कोई मतलब नहीं; software crash हुआ तो वे बस इसे अक्षम software developer मानेंगे

  • या फिर “यह आपके लिए नहीं है” कहने वाला रास्ता भी चुना जा सकता है

• आम तौर पर Dan Luu के लेख पसंद आते हैं, लेकिन यह लेख निशाने से चूकता लगा
  LCP/CPU table अच्छा था, लेकिन उसके बाद बात armchair psychology जैसी हो गई
  Discourse founder की कुछ random comments के आधार पर पाठक से software engineers के attitude की कल्पना करने को कहा गया
  Knuth को भी single-core बनाम multi-core performance वाले बयान और Itanium से जुड़े बयान के आधार पर घसीट लिया गया, जबकि वह पुरानी academic debate का मुद्दा है
  लेख बहुत ढीला लगा, और internet fights पर टिका होने की वजह से ठीक से टिक नहीं पाता

  • लेकिन वास्तव में ऐसा attitude मौजूद तो है, ऐसा लगता है
    Discourse founder की बात बस बहुत explanatory है
    अगर आपने हाल का web इस्तेमाल किया है, तो वह कल्पना से परे bloated हो चुका है, यहां तक कि Google अब Largest Contentful Paint 2.4 seconds को तेज कहता है: https://blog.chromium.org/2020/05/the-science-behind-web-vit...
    यह 4 साल पुराना data है, इसलिए अब शायद हालत और खराब हो गई हो
    desktop पर YouTube के CSS 2.5MB load करने से लेकर Vercel founder द्वारा जिस site को बहुत तेज बताकर शेखी बघारी गई, वह थोड़ी-सी throttling पर load होने में 20 seconds लेती है—उदाहरण ढूंढने दूर जाने की जरूरत नहीं: https://x.com/dmitriid/status/1735338533303259571
  • मैंने बहुत कम देखा है कि कोई company performance को गंभीरता से लेती हो
    frontend के लिए किसी simple API service का response time 500ms हो तो भी कोई उसका मजाक नहीं उड़ाता
    यह भी सवाल है कि कितने engineers को अपनी cloud cost का पता होता है और वे उसकी परवाह करते हैं
  • Knuth कुछ हद तक सही लगते हैं
    आज की parallelism software के 90% में इस्तेमाल नहीं होती, सिवाय specialized use cases या उसी single-thread program को कई data items पर चलाने के
    programming languages और hardware दोनों fine-grained parallelism को ठीक से support नहीं करते, और classic software को parallel approach से तेज बनाना बहुत मुश्किल है
  • समझ नहीं आता कि विवाद किस बात का है
    Luu ने तो बल्कि काफी उदार होकर लिखा है
    Knuth की बात कुछ वैसी थी जैसे दशकों तक चले free lunch के खत्म होने पर शिकायत करना
  • summary काफी अच्छी लगी
    Jeff Atwood को बस example के तौर पर चुना गया है
    बड़े follower base वाले मशहूर web development thinkers लगातार इसी तरह के नजरिए उगलते रहते हैं, और उनके बहुत से followers उसे बस मान लेते हैं

• सभी कंपनियों ने परवाह करना बंद कर दिया है, खासकर Google और Apple जैसी कंपनियों ने, जो कभी standards और अच्छे web design practices की अगली कतार में थीं
  Google ने हाल ही में HTML Gmail बंद कर दिया, जो 2008 के 256MB RAM वाले Android फोन और पुराने Firefox पर भी तेज़ी से और अच्छी तरह चलता था
  जाहिर है नया JavaScript वाला bloated version browser को मार देता है
  यह एक चरम उदाहरण है, लेकिन low-end फोन में 2GB RAM होती है, और अब ऐसे devices पर web browse करते हुए reasonable performance की उम्मीद करना मुश्किल है
  mobile web बेकार है, और यह users को “native” apps की ओर धकेलने के लिए जानबूझकर किया गया है
  क्योंकि Apple और Google जैसी कंपनियों के लिए data collection और ads दिखाना आसान हो जाता है

  • कुछ हद तक यह निश्चित रूप से सच है, लेकिन Amazon या Europe की बड़ी sports और outdoor chain Decathlon के बारे में पता नहीं
    उनकी sites mobile पर बहुत खराब हैं, और Decathlon तो high-performance न होने वाले desktop पर भी भयानक है
    लेकिन वे app को खास तौर पर promote भी नहीं करते, इसलिए लगता है कि इसे बस अक्षमता ही मानना चाहिए
    लगता है developers सब कुछ केवल backbone से जुड़े high-end devices पर ही test करते हैं
  • गुरुवार को Google ने अपना इकलौता usable “product” खत्म कर दिया
    RIP Google
    नया Reddit इस्तेमाल करने लायक नहीं है, और old Reddit बहुत पुराना हो चुका है
    Twitch chat और video stream issues की वजह से मुश्किल से usable है
    सूची लंबी होती जाती है
    अगर आपके पास final formula पहले से है, तो हर बदलाव job security के लिए किया गया खराब बदलाव बन जाता है
    किसी दिन इस मिट्टी के ढेले पर मौजूद बंदर समझेंगे कि jobs और money असल में मौजूद नहीं हैं, लेकिन तब तक बहुत देर हो चुकी होगी
    नहीं, वह समय अभी है
    RIP Humans