49MB वेबपेज

 (thatshubham.com)
2 पॉइंट द्वारा GN⁺ 2026-03-16 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • न्यूयॉर्क टाइम्स वेबसाइट पर एक लेख पेज 422 network requests और 49MB data transfer पैदा करता है, जिससे सिर्फ़ एक साधारण लेख पढ़ने के लिए भी अत्यधिक संसाधनों की ज़रूरत पड़ती है
  • पेज लोड होने की प्रक्रिया में दर्जनों ad bidding requests और tracking scripts एक साथ चलती हैं, जिससे browser का CPU और battery खर्च होती है
  • ऐसी शत्रुतापूर्ण UX design cookie banners, subscription popups, autoplay videos और screen-occupying ads तक पहुँचती है, जो उपयोगकर्ता के पढ़ने के अनुभव में बाधा डालती है
  • ad revenue को अधिकतम करने के लिए ‘dwell time’ और ‘viewability’ पर केंद्रित business model पाठक अनुभव की कीमत पर चलता है, और engineers भी इस संरचना में बँधे हुए हैं
  • लेख text-centric lightweight news pages (text.npr.org आदि) का उदाहरण देते हुए यह रेखांकित करता है कि ऐसा सरल और सम्मानजनक web experience फिर से संभव है जिसमें पाठक और business साथ रह सकें

49MB वेबपेज की हक़ीक़त

  • न्यूयॉर्क टाइम्स वेबसाइट खोलने पर 422 requests और 49MB data उत्पन्न होता है, और पेज को स्थिर होने में 2 मिनट लगते हैं
    • यह Windows 95 के पूरे आकार (28 floppy disks) से भी बड़ा है, और 10~12 MP3 गानों के बराबर है
    • यानी कुछ ही पैराग्राफ़ का टेक्स्ट पढ़ने के लिए मानो पूरा एक album डाउनलोड करना पड़े
  • भले ही पुराने समय की तुलना में hardware performance में भारी सुधार हुआ हो, ad·tracking-केंद्रित web frameworks उस प्रगति को बेअसर कर देते हैं

CPU लोड और tracking संरचना

  • news sites programmatic ad bidding systems को browser के अंदर ही चलाती हैं
    • Rubicon Project, Amazon Ad Systems आदि की ओर asynchronous bidding requests एक साथ जाती हैं
    • browser को कई MB का JavaScript डाउनलोड, parse और compile करना पड़ता है, जो main thread load में बदल जाता है
  • उपयोगकर्ता ने टेक्स्ट माँगा था, लेकिन browser पहले 5MB tracking scripts प्रोसेस करता है, और उसके बाद ads डाले जाते हैं
  • साथ ही behavior-tracking beacons (POST requests) और invisible pixel redirects (doubleclick.net, casalemedia) काम करते हैं, जो cross-site identification करते हैं
  • यह प्रक्रिया mobile heating और battery drain पैदा करती है, और उपयोगकर्ता अनजाने में high-frequency data trading market का हिस्सा बन जाता है

शत्रुतापूर्ण UX और interaction cost

  • पेज में प्रवेश करते ही GDPR cookie banner, newsletter subscription modal, notification permission popup लगातार सामने आते हैं
    • उपयोगकर्ता को content तक पहुँचने से पहले कई बार click और scroll करना पड़ता है
    • यह NNgroup की ‘Interaction Cost’ और ‘minimalist design’ सिद्धांतों का उल्लंघन है
  • Economic Times के उदाहरण में उपयोगकर्ता को article तक पहुँचने के लिए तीन modals बंद करने और ऊपर का banner हटाने की ज़रूरत पड़ती है
  • Google के Core Web Vitals मानकों में भी ऐसे intrusive interstitials को SEO में नकारात्मक कारक बताया गया है

layout instability और ad insertion

  • जब पाठक कोई पैराग्राफ़ पढ़ रहा होता है, उसी दौरान ad bidding पूरी होते ही iframe ad insert हो जाता है और टेक्स्ट 250 pixels खिसक जाता है
    • इसे Cumulative Layout Shift (CLS) के रूप में मापा जाता है, और इसका सीधा संबंध bounce rate बढ़ने से है
  • Google इस समस्या पर आधिकारिक रूप से penalty देता है, लेकिन विडंबना यह है कि उसके अपने ad products भी यही समस्या पैदा करते हैं
  • autoplay videos scroll के बाद भी screen के निचले हिस्से में pinned रहकर चलते रहते हैं, और उनका close button छोटा तथा click area बहुत संकरा होता है
    • इसे Fitts’s Law के उल्लंघन के उदाहरण के रूप में बताया गया है

mobile environment में space waste

  • औसत mobile viewport 800px में logo·share bar·browser UI ही काफ़ी जगह घेर लेते हैं
    • Guardian page के आधार पर वास्तविक content सिर्फ़ 11% ही दिखाई देता है
  • ads·modals 89% बनाम content 11% का अनुपात उपयोगकर्ता की visual fatigue और scroll frequency दोनों बढ़ाता है
  • ‘X’ button को ad click area के पास रखना ताकि गलती से क्लिक हो, ऐसी ‘fat-finger tax’ रणनीति भी मौजूद है
  • Jagran जैसे कुछ भारतीय news sites app install modal और subscription popups के ज़रिए article तक पहुँचने में रुकावट डालते हैं

सुधार के सुझाव

  • content दिखाने से पहले 3~4 close actions के लिए मजबूर करने वाली संरचना उपयोगकर्ता के cognitive resources बर्बाद करती है
    • popups को 60 सेकंड रुकने या 50% scroll के बाद ही दिखाया जाना चाहिए
    • cookie consent और newsletter subscription को नीचे non-blocking section में जोड़ा जा सकता है
  • ad slots को fixed-height containers के रूप में reserve करना चाहिए ताकि layout shift रोका जा सके
    • उदाहरण: min-height: 250px; background: var(--skeleton-loader);
    • ad load न होने पर ResizeObserver के ज़रिए केवल non-visible area में shrink किया जा सकता है

lightweight news sites का अस्तित्व

  • text.npr.org, lite.cnn.com, cbc.ca/lite जैसी साइटें tracking और modals के बिना lightweight versions देती हैं
    • RSS feed-आधारित news consumption भी अब भी सक्रिय है
  • ये उदाहरण दिखाते हैं कि सरल और content-centric web experience की माँग अभी भी बनी हुई है

निष्कर्ष: पाठक का ध्यान एक संसाधन है

  • मौजूदा news UI पाठक को एक capture target की तरह देखता है और ad exposure को अधिकतम करने वाली संरचना में डिज़ाइन किया गया है
  • लेकिन profitability और accessibility साथ-साथ संभव हैं, और engineers भी इस संरचना से असंतुष्ट हैं
  • समस्या की जड़ short-term CPM-केंद्रित business incentives हैं
  • एक ऐसी प्रणाली बन चुकी है जो पाठक के ध्यान को निकाले जा सकने वाले resource की तरह मानती है, और
    RSS का उपयोग, tab बंद करना, और bounce rate बढ़ना इसके विरुद्ध सबसे शक्तिशाली प्रतिरोध के रूप में सामने आते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2026-03-16
Hacker News की राय
  • हमारे डेवलपर्स जब भी एक वेबसाइट खोलते थे, लगभग 750MB इस्तेमाल हो जाता था
    सर्वर धीमा है ऐसी टिकट आई, जाँच करने पर पता चला कि पेज के सभी वीडियो पहले से ही थोड़ा-थोड़ा preload हो रहे थे
    ऑफिस का डेटा सेंटर से optical cable के ज़रिए सीधा कनेक्शन था, इसलिए किसी तरह यह सहन हो पा रहा था
    मेरा मानना है कि वेब डेवलपर्स को 128kbit से ज़्यादा नेटवर्क स्पीड नहीं देनी चाहिए। उसके ऊपर जाते ही सब कुछ बिगड़ जाता है
    • Chromium या Firefox आधारित ब्राउज़र के Network tab में 3G या 4G स्पीड simulate की जा सकती है
      CPU throttling फीचर के साथ इस्तेमाल करें तो low-end environment में साइट की performance जाँचने के लिए अच्छा है
    • 128kbit की सीमा marketing department पर भी लागू होनी चाहिए। tracking scripts के असली दोषी वही हैं
    • भले ही development तेज़ कंप्यूटर पर करें, testing Chromebook जैसे low-end device पर करनी चाहिए
    • mcmaster.com जैसी sites, जहाँ context-aware prefetching अच्छी तरह लागू है, उनसे सीखने लायक है
      अगर development server धीमा हो, तो स्वाभाविक रूप से अनावश्यक resources घटाने की आदत पड़ती है
    • पहले text.npr.org जैसे text web को Lyx के साथ इस्तेमाल करता था
      यह Gopher, Gemini, IRC आधारित Bitlbee जैसे ultra-low-speed environment में भी अच्छी तरह चलता था
      Electron app developers को भी 2GB RAM और पुराने Celeron स्तर के PC पर test करना चाहिए, तभी किसी app को सच में पूरा हुआ कहा जा सकता है
  • प्रयोग के तौर पर nytimes.com खोला, और tracking pixels व ad scripts वाकई भयानक थे
    फिर भी data transfer के हिसाब से देखें तो 44.47MB में से 36.3MB journalism videos थे
    यानी समस्या सिर्फ़ ज़रूरत से ज़्यादा ads नहीं, बल्कि video-केंद्रित content structure भी है
    • लेकिन हर पेज पर autoplay video क्यों होना चाहिए, यह समझ से बाहर है
      user के click करने से पहले ही 36MB ज़बरदस्ती download करवा देना उचित नहीं लगता
  • आजकल NYT पूरी तरह गिरावट पर है
    ads और JavaScript के बोझ की वजह से मैं उसे पढ़ता ही नहीं। सिर्फ़ headlines copy करके किसी दूसरी साइट पर पढ़ लेता हूँ
    मूल रूप से JavaScript बंद रखकर browsing करता हूँ, और ads लगभग देखता ही नहीं
    JS बंद करने पर पेज बहुत तेज़ हो जाते हैं, और privacy leak का जोखिम भी घटता है
    मुझे यह तरीका अनैतिक नहीं लगता। पहले साइटों ने ही अनुचित व्यवहार किया है
    • lite.cnn.com, text.npr.org, newsminimalist.com जैसी lightweight news sites कहीं ज़्यादा आरामदायक हैं
    • NYT जानता है कि ऐसे users revenue में योगदान न देने वाला छोटा समूह हैं
      शायद हमारा आना ही उनके लिए फ़ायदेमंद नहीं है
    • ज़्यादातर लोगों को JS या megabytes की कोई परवाह नहीं होती
      content दिखे और काम करे, उनके लिए वही काफ़ी है
      NYT ऐसे ही ‘तकनीक में रुचि न रखने वाले बहुमत’ को target करता है
    • आगे YouTube alternative clients की अनुमति देता रहेगा या DRM से रोक देगा, यह जानना दिलचस्प होगा
  • 2005 में हमारे परिवार के पहले broadband plan में महीने की 400MB सीमा थी
    समाचार उद्योग की मूल समस्या ad-based economic model का टूटना है
    पहले पाठकों से सिर्फ़ printing cost ली जाती थी, बाकी सब ads से निकल आता था
    लेकिन अब Facebook Marketplace, Craigslist वगैरह वह सारा ad revenue ले गए हैं
    नतीजतन news now niche product बन गई है, और reader data बेचना आख़िरी छटपटाहट जैसा है
    • 2010 में 120MB का game update डाउनलोड किया था और माता-पिता से डाँट खाई थी
      महीने की 250MB सीमा थी, आज सोचो तो यक़ीन करना मुश्किल है
  • आज की web development सच में ads और tracking का नर्क है
    HN जैसी sites, जो JS की हर line बहुत सोच-समझकर इस्तेमाल करती हैं, किसी वरदान जैसी लगती हैं
    web को कम bloated बनाना चाहिए
    • सिर्फ़ इसलिए कि कोई website सारी memory खा सकती है, इसका मतलब यह नहीं कि उसे ऐसा करना ही चाहिए
    • कई बार पेज के ऊपर तरह-तरह के popups और overlays छा जाते हैं, और content देखना भी संभव नहीं रहता
      ऐसे UX से पैसे बनेंगे, यह मानना मुश्किल है, फिर भी यह चलता रहता है
  • Windows 95 install size (लगभग 40MB) से तुलना करना मज़ेदार है
    कभी Win95 को भी ‘bloated’ कहा जाता था, लेकिन आज के web pages उससे कहीं बड़े हैं
    ads से ज़्यादा समस्या resource waste और distraction है
    JS चालू होते ही अगर स्क्रीन पर शोर-शराबा शुरू हो जाए, तो मैं तुरंत निकल जाता हूँ
    • ad industry की economic structure को लेकर जिज्ञासा है
      users को चिढ़ाकर मिलने वाले कुछ cents सच में क़ीमती हैं या नहीं, इस पर शक है
      लगता है ज़्यादातर लोग इसे बस उदासीनता से स्वीकार कर लेते हैं
      मैं तीसरे दशक के अंत का developer हूँ, ‘free internet’ generation से, इसलिए ads के लिए धैर्य लगभग नहीं है
  • airline websites तो ख़ास तौर पर भयानक हैं। Air Canada जैसी साइटों में साधारण booking process भी कई MB के JS से ढकी होती है
    पुराने Amadeus terminal जैसे command-line interface की याद आती है
    web को फिर से user-centric बनाने के लिए क्या किया जाए, यही सोचता हूँ
    • China Southern website सबसे खराब थी
      field label errors, कटे हुए placeholders, चीनी भाषा में दिखने वाला date picker,
      seat चुनने के बाद “चयन संभव नहीं” संदेश—UX पूरी तरह टूटा हुआ था
    • Big Tech के trends की अंधी नकल में फँसे developers की आलोचना होनी चाहिए
      साधारण HTML form से भी काफ़ी उपयोगी site बनाई जा सकती है
      JS का दुरुपयोग किसी तरह की conditioning का नतीजा लगता है
    • आजकल web ऐसा लगता है जैसे developer résumé भरने के लिए बनाया जा रहा हो
    • ad clicks के अलावा नए revenue model की ज़रूरत है, लेकिन अभी विकल्प समझ नहीं आता
  • अफ़सोस है कि लेख में DNS blocklists का ज़िक्र नहीं था
    मैं Hagezi ultimate list से लगभग सारे ads रोकता हूँ, और desktop पर uBlock से बारीक tuning करता हूँ
    Google और Adobe font domains को भी सीधे block किया है, जिससे speed और privacy दोनों बेहतर हुई हैं
    • मैंने सटीक testing नहीं की, लेकिन filters की वजह से traffic 1/10 से भी कम हो गया हो, ऐसा महसूस होता है
  • websites पर scripts चलाने की अनुमति देना 90 के दशक की सबसे बड़ी ग़लतियों में से एक था
    user द्वारा verify न किए गए programs का मेरे कंप्यूटर पर चलना मूल रूप से ही गलत संरचना है
    JS बंद करने पर साइटें टूट जाती हैं, तो यह developers की खराब design का परिणाम है
    अगर HTML और executable code अलग-अलग होते, तो दुनिया कहीं बेहतर होती
    • सिर्फ़ read-only content देखने के लिए executable code download करना बेतुका है
      server पर render करके सिर्फ़ result भेजना ही काफ़ी है
    • लेकिन users interactive web चाहते थे, इसलिए scripting शायद किसी न किसी रूप में आती ही
      49MB का page बस priorities का प्रतिबिंब है
      अब जबकि तेज़ internet आम हो चुका है, ज़्यादातर users को यह समस्या महसूस ही नहीं होती
  • विडंबना यह है कि ऐसी आलोचनात्मक पोस्ट भी Cloudflare Insights जैसे 3rd-party resources को बेवजह लोड करती है
    मैं uBlock Origin hard mode से ऐसे resources पूरी तरह block कर देता हूँ