YouTube embed बहुत भारी हैं, और इन्हें सुधारा जा सकता है

 (frontendmasters.com)
2 पॉइंट द्वारा GN⁺ 2024-07-08 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • डिफ़ॉल्ट YouTube `` embed को खाली पेज पर सिर्फ़ एक बार जोड़ने से भी 32 requests और 1.3MB transfer होता है, जो छोटे वीडियो UI की तुलना में काफ़ी भारी है
  • कई वीडियो जोड़ने पर resources साझा नहीं होते, इसलिए भार linear तरीके से बढ़ता है; Zach Leatherman के माप में 2 embeds पर 2.4MB और 3 embeds पर 3.6MB तक पहुँचता है
  • शुरुआत में दिखने वाली functionality बस poster image, title और बड़ा play button भर होती है, इसलिए `` जैसे Web Component से वही अनुभव अधिक हल्के तरीके से दोहराया जा सकता है
  • lite-youtube-embed लगभग 100KB का है और कई embeds के बीच resources साझा करता है, जिससे बिना functionality खोए speed और efficiency बेहतर होती है
  • YouTube embeds इतने व्यापक रूप से इस्तेमाल होते हैं कि प्रति embed megabyte स्तर का data कम करना बिजली की खपत और carbon emissions तक घटाने वाला व्यावहारिक optimization बन सकता है

डिफ़ॉल्ट `` embed की लागत

  • YouTube के share menu में Embed चुनने पर `` आधारित HTML मिलता है
  • डिफ़ॉल्ट code में loading="lazy" नहीं होता, इसलिए स्क्रीन के बाहर के वीडियो भी तुरंत load हो सकते हैं
  • अगर YouTube डिफ़ॉल्ट iframe में सिर्फ़ lazy loading ही जोड़ दे, तब भी तुरंत performance सुधार संभव है
  • iframe को responsive बनाने और मूल ratio बनाए रखने के लिए CSS से YouTube embed iframe को सीधे target किया जा सकता है
iframe[src^="https://www.youtube.com/embed/";] {
  inline-size: 100%;
  block-size: auto;
  aspect-ratio: 16 / 9;
}

वास्तविक माप और linear बढ़ोतरी

  • खाली पेज पर सिर्फ़ एक YouTube embed डालने पर भी load cost काफ़ी ज़्यादा दिखती है

    • 32 requests

      • 1.3MB data transfer
      • लेखक के WiFi पर 2.76 सेकंड load time
      • Zach Leatherman ने दर्ज किया कि embeds बढ़ने पर resources साझा नहीं होते, इसलिए भार linear रूप से बढ़ता है
      • 2 embeds: 2.4MB
      • 3 embeds: 3.6MB
      • अभी आकार Zach के देखने के समय से भी अधिक बढ़ चुका लगता है

उपयोगकर्ता को शुरुआत में दिखने वाला UI सरल है

  • YouTube embed में उपयोगकर्ता सबसे पहले जिन चीज़ों से सामना करता है, वे सीमित हैं
    • वीडियो की poster image
    • वीडियो title
    • क्लिक करने पर चलने वाला बड़ा play button
  • इस स्तर का UI और behavior पूरे YouTube player resources पहले से load किए बिना भी बनाया जा सकता है
  • हल्का embed engagement कम करता है या नहीं, यह methodology और data सार्वजनिक हुए बिना तय करना मुश्किल है
  • अतीत में जब YouTube engineers ने हल्के video page का परीक्षण किया, तब औसत load time उल्टा बढ़ गया था
    • हल्का page कमज़ोर devices और धीमे internet वाले users तक भी पहुँच गया
    • नए सुलभ हुए users की usage ने average load time metric को धीमा दिखाया हो सकता है
    • सिर्फ़ average load time देखने पर हर user के लिए वास्तविक speed improvement छूट सकती है

विकल्प: `` Web Component

  • Google के performance विशेषज्ञ Paul Irish द्वारा बनाया गया lite-youtube-embed डिफ़ॉल्ट embed अनुभव को अधिक हल्के रूप में दोहराने वाला Web Component है
  • प्रोजेक्ट विवरण के अनुसार यह असली embed जैसा render करते हुए लगभग 224 गुना तेज़ है
  • user experience डिफ़ॉल्ट YouTube embed से लगभग समान है
    • poster image दिखाना
    • title दिखाना
    • बड़ा play button दिखाना
    • क्लिक पर video चलाना
  • अंतर resource usage और sharing के तरीके में है
    • डिफ़ॉल्ट YouTube embed: लगभग 1.3MB
    • ``: लगभग 100KB
    • कई embeds के बीच resource sharing संभव
    • बिना functionality खोए speed, efficiency और बुनियादी privacy protection मिल सकती है

उपयोग का तरीका और संबंधित implementations

  • JavaScript से Web Component register करने के बाद `` element इस्तेमाल किया जाता है
  • npm install, direct copy और CDN link — तीनों तरीके संभव हैं
import "https://esm.sh/lite-youtube-embed";;
  • README की सिफ़ारिश HTML को पहले रखने और script को asynchronous रूप से load करके progressive enhancement लागू करने की है
  • JavaScript load होने से पहले भी सही दिखे, इसके लिए background-image को HTML के भीतर रखा जा सकता है

  [Play Video: Keynote (Google I/O '18)](https://youtube.com/watch?v=ogfYd705cRs)

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

2 टिप्पणियां

 
GN⁺ 2024-07-08
Hacker News की राय

  • कम्युनिटी फोरम प्लेटफॉर्म पर YouTube embeds को detect करके, क्लिक से पहले load न होने वाले proxy thumbnail से बदल दिया गया है
    सिर्फ इसलिए कि thread में किसी एक व्यक्ति ने YouTube वीडियो शेयर किया है, उस page को खोलने वाले हर व्यक्ति को 1MB+ JavaScript डाउनलोड करने और Google द्वारा IP tracking झेलने की जरूरत नहीं है

    • मैं एक infinite scroll site चलाता हूं जहां ज्यादातर YouTube, SoundCloud, Reddit embeds होते हैं, और YouTube को इसी तरह handle करने पर ही वह मुश्किल से usable हुआ
      Tracking की मुझे ज्यादा चिंता नहीं है, इसलिए YouTube द्वारा दिए गए thumbnails वैसे ही इस्तेमाल कर रहा हूं
    • जानना चाहता हूं कि SoundCloud के लिए भी कोई मिलता-जुलता solution है या नहीं
      SoundCloud player भी बहुत भारी है
    • संयोग से मैं भी इसी समस्या पर काम कर रहा हूं, इसलिए इस approach पर कोई tips या examples हों तो जानना चाहूंगा
    • जानना चाहता हूं कि thumbnails को भी cache या proxy करते हैं या नहीं
      अगर thumbnail hotlink किया जाए, तो Google वहां से भी track कर सकता है

  • लेखक ने कहा कि वह इस evidence पर भरोसा नहीं करते कि हल्का version engagement घटाता है, लेकिन मुझे लगता है कि ऐसा काफी संभव है
    सुझाए गए lite-youtube-embed project demo में light player और normal player दोनों हैं, और light version में video playback शुरू होने में साफ तौर पर ज्यादा समय लगता है
    Load time में हर 1 millisecond की बढ़ोतरी engagement घटाती है, और यहां difference सैकड़ों milliseconds या उससे ज्यादा दिखता है
    https://paulirish.github.io/lite-youtube-embed/

    • ऐसा होने की संभावना ज्यादा है, लेकिन यह भी देखना होगा कि video को जल्दी start करवाना embedded webpage को ही धीमा बनाने की कीमत चुकाने लायक है या नहीं
      हर millisecond मायने रखता है वाली बात webpages पर भी लागू होती है। अगर user page छोड़ देता है, तो वह video तक पहुंचेगा ही नहीं
      और यह भी ठीक हो सकता है कि user video देखना न चाहता हो। व्यक्तिगत रूप से, अगर webpage पर summary हो तो मुझे video avoid कर पाना अच्छा लगता है
      YouTube के desktop redesign से भी शिकायत है; जिस video को देखने आया हूं उससे ज्यादा screen space दूसरे videos promote करने में खर्च होता है। काश distractions कम हों
    • Embedded video को सच में देखने की rare situation में कुछ सौ milliseconds इंतजार करना, उन embedded players को हर page visit पर load करने से कहीं बेहतर है जिन्हें मैं देखूंगा भी नहीं
      Traffic light से तुलना करें तो सभी signals का थोड़ी देर लाल रहना बेहतर नहीं, बल्कि मेरे पहुंचने वाला signal green हो तो बेहतर है
    • “Load time में हर 1 millisecond की बढ़ोतरी engagement घटाती है” 90s वाली belief जैसी बात है
      बड़ी companies के actual व्यवहार को देखें तो साफ है कि वे ऐसी चीजों की परवाह नहीं करतीं, और अगर उनके लिए यह important नहीं है तो हमारे पास उनके लिए optimize करने की वजह भी नहीं है
      इस use case में यह बड़ी समस्या नहीं है, लेकिन बाकी stack में performance पर ध्यान देना चाहिए
    • पुराने YouTube player में पूरा video load और buffer हो जाता था, इसलिए दोबारा देखने पर re-download की जरूरत नहीं पड़ती थी और सुविधा रहती थी
      समझ नहीं आता कि हम यहां तक पीछे कैसे चले आए, और लगता है Google उन चीजों को धीरे-धीरे खराब कर रहा है जो पहले ठीक-ठाक काम करती थीं
    • फर्क है, लेकिन इतना बड़ा नहीं लगता; अगर यह 100ms तक भी जाए तो मुझे हैरानी होगी
      Environment के हिसाब से बदल सकता है: Firefox, करीब 2 साल पुराना i7-1185G7 laptop, Windows 11, 32-bit mode Edge लगातार update हो रहा है और कई हफ्तों से reboot नहीं हुआ
      Slow होने का impression ज्यादातर घूमते loading indicator की वजह से है। यह खुद ही अपने slow होने का विज्ञापन कर रहा है
      Click के बाद playback तक की delay असर तो डालेगी, लेकिन उसे सही से measure करने के लिए YouTube जितनी scale वाली entity चाहिए

  • हल्के embed से engagement घटने की अफवाह और सुझाए गए lite-youtube-embed के बारे में, users player के जरा भी अलग दिखने या अलग behave करने पर उसे अजनबी और अविश्वसनीय मान सकते हैं
    Demo का lite-youtube-embed title दिखाने के बावजूद actual YouTube page पर जाने का link नहीं देता, जिससे ऐसा hostile feel भी होता है मानो original “content” तक जाने से रोका जा रहा हो
    बेशक वह feature आसानी से add किया जा सकता है, लेकिन यह एक बड़ी समस्या दिखाता है
    मैं embedded videos शायद ही कभी play करता हूं, लेकिन अगर करूं तो मुझे बस normal YouTube experience काफी है। अगर उसे किसी और unknown layer में wrap कर दिया जाए तो click करने की संभावना घट जाती है
    इस लेख में “कुछ sacrifice नहीं होता” वाली phrasing developer के इस भ्रम का example है कि उसे पता है users software का इस्तेमाल कैसे करते हैं। असल में यह हमेशा अनुमान ही होता है
    उम्मीद है videos कम होंगे, हर जगह Google पर dependency और JavaScript के ढेर कम होंगे। बेहतर web के लिए YouTube videos को हर जगह embed न किया जाए
    https://paulirish.github.io/lite-youtube-embed/

    • YouTube के official embed UI में भी Watch on YouTube button पर्याप्त prominent नहीं है, इसलिए मैं हमेशा पहले play दबाता था, फिर pause करके bottom-right का YouTube button दबाता था
      अब पता चल गया है, तो अच्छा होगा कि ऐसे light players में भी वह button हो। फिर भी यह implementation link पाने का आसान तरीका पूरी तरह block नहीं करता
    • lite-youtube-embed में बाद में देखने के लिए video save button भी नहीं है, जो मैं अक्सर use करता हूं
      Video play करने पर उसे access किया जा सकता है, लेकिन वह मकसद के खिलाफ है। मैं video play नहीं करना चाहता, और न ही load होने का इंतजार करके pause करने के बाद save button दबाना चाहता हूं

  • अब बस ब्लॉगर्स को GitHub Gist embed इस्तेमाल करने से रोकना बाकी है
    Hugo और शायद दूसरे static site generators syntax highlighting वाले code snippets को default रूप से support करते हैं, और ज़्यादा dynamic sites भी highlight.js से third-party service dependency हटा सकती हैं
    छोटे code snippet के लिए भारी iframe इस्तेमाल करना सच में अजीब है
    https://gohugo.io/content-management/syntax-highlighting/
    https://highlightjs.org

    • लोगों को अपनी site पर जो चाहें करने देना चाहिए, ऐसा लगता है
      मुझे पसंद न भी हो, तो भी मेरी पसंद के हिसाब से site बदलने के लिए “मजबूर” करना बेतुका है
    • Automattic में काम करते समय एक बार पता चला था कि Gist का heart emoji GitHub नहीं, WordPress serve कर रहा था
      कुछ हफ्तों में ठीक हो गया, लेकिन यह हैरानी की बात थी कि वह स्थिति कई सालों तक बनी रही थी

  • अगर page पर Content Security Policy का इस्तेमाल किया जा सके, तो ads block करके embed का कुल वजन घटाया जा सकता है और user experience भी सुधर सकता है
    संबंधित जानकारी: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

    • Content-Security-Policy में unsafe-inline को यूँ ही डालना ठीक नहीं है
      क्योंकि इससे CSP की injection attack protection बंद हो जाती है। अगर सच में ज़रूरत हो, तो inline scripts allow करने के ज़्यादा सुरक्षित तरीके मौजूद हैं
      https://content-security-policy.com/

  • “हल्के embed ने engagement घटा दी” वाली बात में लगता है कोई बड़ा हिस्सा गायब है
    जाहिर है, load time तेज़ होने पर engagement बेहतर होनी चाहिए। लेकिन अगर हल्के embed में engagement गिर गई, तो इसका मतलब है कि कोई feature या behavior कुर्बान किया गया
    मगर यह लेख कहता है कि कुछ भी कुर्बान नहीं हुआ, इसलिए कहानी में कहीं कुछ छूटा हुआ है

    • याद है कि Facebook या Uber जैसी बड़ी tech companies ने optimization जोड़ा था और similar result मिला था; बाद में पता चला कि ऐसे नए markets से access शुरू हो गया था जहाँ पहले page तक खुल नहीं पाता था
      यहाँ भी ऐसा हो सकता है। हल्के embed की वजह से बहुत से लोग पहली बार video load कर पाए, लेकिन device या connection slow होने के कारण playback stage पर छोड़ गए होंगे
      तब जो लोग पहले player को पूरी तरह load ही नहीं कर पाते थे और कोई data नहीं छोड़ते थे, वे अब “video देखने के दौरान drop-off” rate बढ़ाते हुए दिख सकते हैं
    • “load time तेज़ हो तो engagement बेहतर होती है” इतना simple नहीं है
      user की loading time expectations और tolerance target के हिसाब से अलग-अलग होती हैं, और page व उसके भीतर का video अलग-अलग targets हैं
      पूरी page load time हमेशा embed load time से बंधी भी नहीं होती, और full page load content load time को छिपा भी सकता है
      ज़्यादा अहम metric embed load time नहीं, बल्कि click के बाद playback शुरू होने तक की delay हो सकती है

  • uBlock users के लिए user-side solution के तौर पर click2load filter इस्तेमाल किया जा सकता है
    हालांकि Chrome Manifest V3 पर shift हो रहा है, इसलिए यह काम न भी करे। yokoffing/filterlists के filter को reference के तौर पर देख सकते हैं
    https://raw.githubusercontent.com/yokoffing/filterlists/main...
    Betterfox का creator है और GitHub पर दूसरे useful filters भी हैं

    • Click2load improvement है, लेकिन embeds फिर भी अच्छे नहीं हैं
      जो चाहिए वह बस एक साधारण link है, इसलिए पहले page के YouTube iframe को link में बदलने के लिए एक छोटी user script बनाई थी
      simple implementation के हिसाब से यह हैरान करने लायक अच्छी तरह काम करती है। यह youtube.com/embed और youtube-nocookie.com/embed iframe ढूंढकर उन्हें watch?v= link में बदलती है, timestamps भी बनाए रखती है, और चाहें तो thumbnail image भी जोड़ सकती है

  • “embed की संख्या बढ़ने पर वजन भी linear तरीके से बढ़ता है। दो 2.4MB, तीन 3.6MB” वाला हिस्सा अजीब है
    सोच रहा हूँ कि ये resources cache से क्यों नहीं आ रहे। अगर सभी www.youtube.com से load होते हैं, तो same-origin policy के हिसाब से cached resources इस्तेमाल हो पाने चाहिए, है न

  • लेख में सबसे अच्छा हिस्सा वह था जहाँ हल्के page पर बदलने के बाद average page load time उल्टे बढ़ गया
    ज़्यादा detail से देखने पर पता चला कि low-end devices और slow internet वाले users भी पहली बार YouTube को सच में इस्तेमाल कर पा रहे थे, और उनके ज्यादा इस्तेमाल से average धीमा दिखने लगा
    असल usage speed सबके लिए तुलनात्मक रूप से तेज़ हुई, और average page load speed नाम का metric आखिरकार एक बेकार चारा था—यह बात प्रभावशाली लगी

  • पहले मैंने Firefox extension बनाया था जो सभी YouTube embeds को thumbnail में बदल देता था, और click करने पर YouTube खोलता था
    मूल रूप से इसलिए बनाया था क्योंकि phone में Flash नहीं था और Flash embeds आम थे, और बाद में इसे iframe embeds तक handle करने के लिए extend किया
    ज़्यादातर मामलों में छोटे embed window के बजाय YouTube website या पूरे app में खोलना user experience के लिए भी बेहतर था
    उस समय इसे नए high-level extension API के हिसाब से लिखा था, फिर भी browser versions के बीच support उम्मीद के मुताबिक जारी नहीं रहा, जिससे चिढ़कर मैंने इसे WebExtension में migrate नहीं किया। यह लेख देखकर फिर से port करने का मन हो रहा है