धीमे डिवाइस इस्तेमाल करने वाले उपयोगकर्ताओं पर web bloat का प्रभाव

वेब पेज के आकार का धीमे डिवाइस उपयोगकर्ताओं पर प्रभाव

• 2017 में यह जांचा गया कि वेब पेज का आकार धीमे इंटरनेट कनेक्शन वाले उपयोगकर्ताओं को कैसे प्रभावित करता है।
• अमेरिका और उसके बाहर अब भी बहुत से उपयोगकर्ताओं के पास broadband speed नहीं है, और आधुनिक वेब धीमे इंटरनेट वाले लोगों के लिए इस्तेमाल करना कठिन है।
• broadband speed बढ़ने के साथ वेब पेज के आकार की समस्या 2017 की तुलना में कुछ कम हुई है, लेकिन कम गति वाले कनेक्शन वाले लोगों के लिए यह अब भी गंभीर समस्या है।

CPU प्रदर्शन और web applications

• web applications के लिए CPU प्रदर्शन bandwidth जितनी तेजी से नहीं बढ़ रहा है।
• कम-spec डिवाइस वाले लोगों के लिए वेब accessibility बेहतर हो रही है, लेकिन साथ ही कम-spec डिवाइस वाले उपयोगकर्ताओं के लिए कई वेब पेज लगभग inaccessible होते जा रहे हैं।
• उदाहरण के लिए, Tecno Spark 8C जैसे कम-spec डिवाइस पर आधुनिक forums ब्राउज़ करने की कोशिश करने पर browser अक्सर crash हो जाता है।

कम-कीमत वाले डिवाइस का प्रदर्शन

• Tecno Spark 8C जैसे कम-कीमत वाले डिवाइस को दुनिया भर में low-end डिवाइस नहीं माना जाता।
• Itel P32 जैसे उससे भी कम-spec डिवाइस के प्रदर्शन की भी जांच की गई।
• अलग-अलग डिवाइसों (M3 Max Macbook, M1 Pro Macbook आदि) और अलग-अलग platforms (blogs, forums, small business platforms) के प्रदर्शन की तुलना की गई।

प्रदर्शन मापन तालिका

• हर वेबसाइट के लिए compressed size, original size, Largest Contentful Paint(LCP), और CPU उपयोग मापा गया।
• LCP वह metric है जो यह मापता है कि उपयोगकर्ता को कब महसूस होता है कि पेज का मुख्य content दिखाई देने लगा है।
• CPU time एक सरल metric है, जिसका उपयोगकर्ता की perceived usability से मजबूत संबंध है।

धीमे डिवाइस उपयोगकर्ताओं पर वेब पेज के आकार के प्रभाव पर अतिरिक्त टिप्पणियाँ

GN⁺ की राय

• धीमे डिवाइस उपयोगकर्ताओं पर वेब पेज के आकार के प्रभाव पर यह अध्ययन वेब developers को optimization के महत्व की याद दिलाता है।
• यह आधुनिक web development trends पर आलोचनात्मक दृष्टिकोण देता है, जो कम-spec डिवाइस उपयोगकर्ताओं के अनुभव को नज़रअंदाज़ करते हैं।
• यह अध्ययन कम-spec डिवाइसों को ध्यान में रखकर की जाने वाली web optimization तकनीकों, जैसे Progressive Web Apps(PWA), के महत्व को रेखांकित करता है।
• web optimization के लिए tools और techniques, जैसे Google का PageSpeed Insights और Lighthouse, वेब developers के लिए उपयोगी हैं।
• अध्ययन के निष्कर्ष इस बात पर ज़ोर देते हैं कि कम-spec डिवाइस उपयोगकर्ताओं के लिए web accessibility सुधारने हेतु web standards और optimization techniques का पालन करना महत्वपूर्ण है।

[GN⁺]

Hacker News राय

• Tecno Spark 8C की समीक्षा में यह बात बताई गई कि PUBG जैसे 3D गेम ठीक-ठाक performance के साथ चल सकते हैं, लेकिन इसका यह मतलब नहीं है कि यह आधुनिक text-centric social media platforms या web forums पर पोस्ट पढ़ने के लिए पर्याप्त तेज़ है। PUBG में 40fps मिल सकता है, लेकिन ऐसे sites पर scroll करते समय यह 0.4fps से भी नीचे गिर सकता है.
  • इस बात पर सावधान रहने की ज़रूरत बताई गई कि जब marketing team frontend team से नया tracking script लागू करने को कहे, तो यह मान लेना गलत है कि users को कोई फ़र्क महसूस नहीं होगा.
• दुनिया में असमानता के अलग-अलग स्तरों को समझना ज़रूरी है, और इसमें middle-income countries, खासकर Latin America और Southeast Asia के देश भी शामिल होने चाहिए.
  • उदाहरण के लिए, जिन users के पास महीने भर के लिए single-digit GB data plan है, और जिनके devices का RAM/CPU profile लगभग 10 साल पुराने US flagship smartphone जैसा है, वे Discourse इस्तेमाल तो कर सकते हैं, लेकिन उनका अनुभव धीमा और परेशान करने वाला हो सकता है.
  • यह माना गया कि users की यही श्रेणी Dan के उस अवलोकन का मुख्य कारण है कि CPU/RAM/disk में क्रमिक सुधार engagement को स्पष्ट रूप से बेहतर बनाता है.
• Dan के chart से दिखता है कि सबसे निचले स्तर के devices इस्तेमाल करने वालों के लिए incremental optimization शायद मददगार न हो.
  • इसका एकमात्र समाधान पूरी तरह अलग client architecture हो सकता है, जिसमें features और polish की क़ुर्बानी देकर जितना संभव हो उतना lean code दिया जाए, यानी एक 'light/basic' mode.
  • दुर्भाग्य से, यह approach कम ही सफल साबित हुई है, और US-आधारित developers अक्सर performance के लिए क्या बचाना है और क्या हटाना है, इस बारे में गलत फ़ैसले लेते हैं.
• अपेक्षाकृत धीमे Android phone के हालिया अनुभव के आधार पर, सिर्फ text और images दिखाने वाले कुछ web pages को load करना भी बेहद मुश्किल हो सकता है.
  • यह समस्या कई कारणों से और जटिल हो जाती है। उनमें से एक यह है कि पुराने या धीमे phones कई बार Firefox mobile जैसे full-featured browser भी नहीं चला पाते। App खुद website खोलने से पहले ही बहुत resources खा लेती है.
  • इसकी वजह से Firefox Focus जैसे simplified browser पर जाना पड़ता है, लेकिन उसमें extensions इस्तेमाल नहीं किए जा सकते। यानी ublock origin नहीं होता, जिससे web experience और खराब हो जाता है.
  • एक और समस्या यह है कि अगर "standard" browser इस्तेमाल न किया जाए, तो कुछ sites unusable हो सकती हैं.
  • ऐसी स्थिति में कंपनियाँ अक्सर app थोपने की कोशिश करती हैं। लेकिन वह app कम storage वाले device में कितनी जगह घेरेगी या कितनी खराब चलेगी, यह पता नहीं होता.
  • कई companies/sites पहले धीमे devices या connections को ध्यान में रखकर simplified versions देती थीं, लेकिन हाल के समय में ये versions धीरे-धीरे गायब हो रहे हैं और ढूंढना भी मुश्किल हो गया है.
• 6 साल पुराने LG flagship phone से नए Galaxy पर हालिया बदलाव में performance का फ़र्क बहुत बड़ा था.
  • वह अपने समय में बहुत high-end phone था, इतना पुराना भी नहीं है, और अब भी नए जैसा काम करता है.
  • यह भी पता है कि code testing के लिए इस्तेमाल किया जाने वाला Galaxy S9 भी वही समस्या झेल रहा है.
  • यह राय दी गई कि testing में Amazon को शामिल किया जाना चाहिए था। Amazon की website लगभग 4 साल या उससे पुराने mobile devices पर सबसे खराब अनुभवों में से एक है.
• Raspberry Pi 3 पर YouTube के unusable होने का एक data point दिया गया.
  • यह समस्या पिछले साल शुरू हुई; उससे पहले इसे लगभग 10-15FPS पर "देखा" जा सकता था। उदाहरण के लिए, workshop में repair videos देखने भर के लिए यह काफ़ी था.
  • जब Raspberry Pi Model B लॉन्च हुआ था, तब वह storage से 1080p video चला सकता था, YouTube देख सकता था और games भी चला सकता था.
  • YouTube क्या कर रहा है, यह स्पष्ट नहीं है, लेकिन इस समस्या को गंभीरता से लिया जाना चाहिए। खासकर अगर climate crisis/change को गंभीरता से लिया जाए, तो Google और Meta जैसी कंपनियों को low-power devices पर CPU cycles बर्बाद करने के लिए मीडिया में कड़ी आलोचना मिलनी चाहिए, और कुल UX थोड़ा खराब होने पर भी ज़्यादा efficient services का उपयोग किया जाना चाहिए.
• 48 साल के एक user ने कहा कि desktop पर articles पढ़ना मुश्किल हो गया है.
  • developer tools में body पर नीचे दिया गया style जोड़कर readability बेहतर की गई:

    font-size: 18px;
    line-height: 1.5em;
    max-width: 38rem;
    

  • इस बात पर ज़ोर दिया गया कि pages को ज़्यादा readable बनाने के लिए developers को जो चीज़ जोड़नी है, वह सिर्फ 64 bytes है.
• यह बताया गया कि design का झुकाव बहुत तेज़ और high-quality connectivity के हिसाब से ज़्यादा है.
  • उदाहरण के लिए, airplane Wi‑Fi पर Google products इस्तेमाल करने पर, सिर्फ chat भी कई मिनट ले सकती है या कभी load ही नहीं होती, और बार-बार crash होकर महंगे दाम पर फिर से load करनी पड़ती है.
  • यह इच्छा जताई गई कि software engineers ideal conditions के बाहर भी testing में रुचि लें। कम speed, intermittent connectivity, और packet loss वास्तविक स्थितियाँ हैं.
• यह कहा गया कि "slow devices वाले users" का मतलब अक्सर "वे लोग जो अपना hardware कई साल तक बनाए रखना चाहते हैं" होता है.
  • यह सुझाव दिया गया कि developers को users के hardware का survey करना चाहिए, और सबसे धीमे common systems को हफ़्ते में एक दिन इस्तेमाल करने के लिए मजबूर किया जाना चाहिए। अगर efficiency में रुचि नहीं है, तो शायद पर्याप्त तकलीफ़ होने पर रुचि आ जाए.
• आम तौर पर Dan Luu की writing पसंद आती है, लेकिन इस बार लगा कि लेख अपने लक्ष्य से चूक गया.
  • LCP/CPU table अच्छा है, लेकिन उसके बाद लेख थोड़ा armchair psychology में बदल जाता है। Discourse के founder की कुछ random comments के आधार पर, readers से कहा जाता है कि वे software engineers के कथित रवैये के बारे में एक विचार बना लें.
  • यह लेख बहुत नरम है और internet arguments पर ज़्यादा टिकता है, इसलिए यह वास्तव में ज़्यादा persuasive नहीं लगता.
• यह कहा गया कि अगर website की accessibility धीमे devices वाले लोगों, खासकर developing countries में रहने वालों, के लिए बेहतर बनानी है, तो और भी बातें ध्यान में रखनी होंगी.
  • ज़्यादा स्पष्ट English और सरल sentence structure का उपयोग करने से content उन लोगों के लिए अधिक accessible हो सकता है, जो शिक्षित अमेरिकियों की तरह धाराप्रवाह English नहीं पढ़ पाते.
  • Page load करने के लिए ज़रूरी requests की संख्या कम करना अच्छा होगा, क्योंकि latency काफ़ी अधिक हो सकती है, और उदाहरण के लिए सबसे नज़दीकी Cloudflare edge node तक की latency भी फिर भी ऊँची रह सकती है.