[HN Gopher] YouTube embeds are heavy and it's fixable
___________________________________________________________________
YouTube embeds are heavy and it's fixable
Author : surprisetalk
Score : 276 points
Date : 2024-07-07 12:37 UTC (10 hours ago)
(HTM) web link (frontendmasters.com)
(TXT) w3m dump (frontendmasters.com)
| ksec wrote:
| >TL;DR: YouTube Embeds are like 1.3MB in size with no shared
| resources between multiple embeds. Using a <lite-youtube> Web
| Component is more like 100k, does share resources, and sacrifices
| no functionality.
|
| I would even go further and wonder why lite-youtube still
| requires 100K? And why they are not shared across different
| sites.
| nolok wrote:
| > And why they are not shared across different sites.
|
| Cross site resources caching has been disabled in all major
| browsers for a few years now, because it was used for tracking.
| jsheard wrote:
| The lite version still has to download the thumbnail, which is
| somewhere around 100-150k by itself for the 720p version.
| YouTube does provide smaller thumbnails you could use instead
| but with modern screen resolutions you probably want the big
| one.
| cuu508 wrote:
| Does the 100K figure include thumbnail?
|
| Edit: I guess yes, the unminified JS file here is 10KB and
| much of it is code comments
| https://github.com/paulirish/lite-youtube-
| embed/blob/master/...
| KMnO4 wrote:
| In a nutshell: You can track load time of your site. If (e.g.)
| NBC homepage has videos of X, Y, and Z on their homepage, you
| can simply embed those same videos on your site.
|
| Does your page take <0.1s to load? The cache was hit which
| means the user probably visited NBC recently.
|
| We can't have nice things because people figure out how to use
| them to track people.
| dangus wrote:
| > I would even go further and wonder why lite-youtube still
| requires 100K?
|
| Just turn off your computer and you'll be using 0K.
| justsomehnguy wrote:
| > The Solution is to Replicate the Embed Experience Another Way.
|
| No, The Solution is to publicly shame Google Inc for wasting the
| resources.
|
| When it would be on WSJ and The Guardian front page _then,
| maybe,_ you would see the result.
|
| Replacing the embed a one server/page is like pissing in the
| ocean - feels great, does nothing.
| coldtea wrote:
| > _When it would be on WSJ and The Guardian front page then,
| maybe, you would see the result_
|
| Good luck with that. Not to mention WSJ and The Guardian
| themselves are babanas heavy for no good reason - like every
| other media site.
| haliskerbas wrote:
| No one gets a promo for maintenance work. Especially at places
| like google.
| stevekemp wrote:
| "I saved XXTb of bandwidth with this one simple change!"
| popcalc wrote:
| Could be resume fodder.
| QuinnyPig wrote:
| The front page of Hacker News remains one of the only effective
| places to file bug reports against Google products.
| zinekeller wrote:
| > No, The Solution is to publicly shame Google Inc for wasting
| the resources.
|
| When a different part of Google publicly shames YT devs for
| this exact thing (https://web.dev/articles/embed-best-
| practices#use_click-to-l...), you know that there's little hope
| for change.
| veeti wrote:
| Google PageSpeed will gladly shame you for using the slow
| YouTube embed.
| troupo wrote:
| > The Solution is to publicly shame Google Inc for wasting the
| resources.
|
| They don't care/internal company policies are misaligned.
|
| Here's Chrome's engineering leader saying that 2.4 seconds to
| load a page on Reddit is fast actually:
| https://x.com/addyosmani/status/1678117107597471745
|
| Here's him also writing a huge article on using third-party
| scripts to improve Youtube embeds because that's apparently
| better than fixing actual Youtube embeds:
| https://web.dev/articles/embed-best-practices
|
| BTW, do you know that Youtube's desktop site loads an 2.5 MB
| CSS file (and 11 MB of Javascript)?
| user070223 wrote:
| User side solution click 2 load for ublock users(note that chrome
| is transitioning to manifest v3 and might not work) is the
| following thanks to yokoffing/filterlists
| https://raw.githubusercontent.com/yokoffing/filterlists/main...
| (Betterfox creator, he has other useful filters on github)
| !||youtube-nocookie.com^$3p,frame,redirect=click2load.html,domain
| =~bing.com|~google.com|~duckduckgo.com|~video.search.yahoo.com
| ||youtube-nocookie.com/embed^$3p,frame,redirect=click2load.html,d
| omain=~bing.com|~google.com|~duckduckgo.com|~video.search.yahoo.c
| om ||youtube.com^$3p,frame,redirect=click2load.html,domain=
| ~bing.com|~chatreplay.stream|~google.com|~duckduckgo.com|~video.s
| earch.yahoo.com
| schiffern wrote:
| Click2load is an improvement, but embeds still suck.
|
| All I want is a plain link, so a while back I got fed up and
| wrote a short userscript to just rewrite the page. Works
| surprisingly well for how simple it is. //
| ==UserScript== // @name Youtube UnEmbed //
| @version 0.1 // @description Converts embedded
| Youtube iframes into links // @match *://*/*
| // @exclude *://*.youtube.com/* // @exclude
| *://*.reddit.com/* // @exclude *://looptube.io/*
| // @grant none // @run-at document-idle
| // ==/UserScript== (function() { 'use strict';
| const SITE = "https://www.youtube.com"; //m.youtube Invidious
| etc const LINK_TO_TIMESTAMP = true; const
| SHOW_PREVIEW_IMAGE = false; const replaceEmbeds = ()
| => {
| document.querySelectorAll('iframe').forEach((frame) => {
| const frameURL = frame.src || frame.dataset?.src; if
| (!frameURL) return; const match = frameURL.match(/(^h
| ttps?:)?\/\/(www\.)?youtube(-nocookie)?\.com\/embed\/([a-zA-Z0-
| 9\-_]{11}).*?(\?.*((t|start)=([\dsmh]*)))?/i); if
| (match?.length == 9) { const newURL =
| SITE+"/watch?" + ((LINK_TO_TIMESTAMP && match[8]) ?
| "t="+match[8]+"&" : "") + "v="+match[4]; const elem
| = document.createElement("a") elem.href = newURL;
| if (SHOW_PREVIEW_IMAGE) { let img =
| document.createElement("img"); img.src =
| "https://i.ytimg.com/vi/"+match[4]+"/mqdefault.jpg";
| img.alt="Preview image of Youtube video"; // 320
| x 180 preview. For more resolution options see //
| https://medium.com/@viniciu_/how-to-get-the-default-thumbnail-
| url-for-a-youtube-video-b5497b3b6218
| elem.appendChild(img); } else {
| elem.innerHTML = newURL; }
| frame.outerHTML = elem.outerHTML; // common
| lazyload hiding methods elem.style.display = "block
| !important"; elem.style.opacity = "100%
| !important"; elem.style.background = "transparent
| !important"; const parent = elem.parentElement;
| if (parent) { parent.style.display = "block
| !important"; parent.style.opacity = "100%
| !important"; parent.style.background =
| "transparent !important"; } }
| }); }; replaceEmbeds();
| setInterval(replaceEmbeds, 3000); })();
| KomoD wrote:
| I suggest using MutationObserver instead of just running the
| replaceEmbeds function every 3s.
| schiffern wrote:
| Intentionally left as an exercise for the reader. ;-D If
| you do, share it back! I'll switch to your version.
|
| Remember I threw this together in about half an hour, and
| maybe that amount of cleanup to post here. "Works for me"
| is the order of the day. The extra debugging alone would be
| longer than the whole project!
|
| Besides, the function that runs is so light it doesn't
| really seem worth it. It could even make performance worse,
| since for reliability you need to observe mutations across
| the entire DOM, which could occur a lot more often. So for
| performance you want to add some debouncing too, adding yet
| more complexity to what's supposed to be a 'quick and
| dirty' fix.
| Featherknight wrote:
| Great script idea! keeping this. Note, this does not prevent
| the initial loading of the embed itself, just replaces the
| embed with the link. The total transfer size of a page is
| still the same. If only there was a way to prevent the
| loading AND keep the link replacement.
| schiffern wrote:
| Thanks. Despite being Not A Project I did edit to add
| optional image previews and reuse the regex object, so grab
| the final version if you want.
|
| I should have mentioned this is paired with uBlock Origin
| to block Youtube iframes (and indeed all iframes) globally.
| At the time I was writing it to _unbreak_ embedded videos.
|
| https://github.com/gorhill/uBlock/wiki/Dynamic-
| filtering:-qu...
|
| https://github.com/gorhill/uBlock/wiki/Blocking-mode
|
| https://github.com/gorhill/uBlock/wiki/Blocking-
| mode:-medium...
|
| From uBO _My Rules_ tab: * youtube-
| nocookie.com * block * youtube.com * block *
| ytimg.com * block youtube.com youtube.com * noop
| youtube.com ytimg.com * noop
|
| To block all iframes (except sites you whitelist, see links
| above): * * 3p-frame block
| Featherknight wrote:
| Oh wow, I was just thinking that optional image previews
| would make this great, good stuff! The preview image
| doesn't auto-fit nicely in all layouts(using
| sonyalpharumors.com to test; works great for header
| banner embeds but potentially awkward sizing for post
| embeds) but I think that's due to the fixed image size
| and you not messing with the DOM outside of adding the
| img to it. Will you post this somewhere like github or
| greasyfork?
|
| I do have the 3rd party iframes blocked globally in uBo
| Firefox and works great with your script to replace the
| placeholder elements but Safari lacks an alternative
| sadly afaik
| fallingsquirrel wrote:
| <img src="thumbnail.png" onclick="[replace image with embed]">
| phh wrote:
| And this has the extra benefit that you don't give your website
| data to Google for free
| xd1936 wrote:
| It looks like this solution is essentially this, but a little
| nicer looking (on hover animation, for example).
| ethanol wrote:
| Now we only need to force bloggers to stop using GitHub Gist
| embeds. Hugo (and probably other static site generators) has
| built-in support for code snippets with syntax highlighting, and
| more dynamic sites can rely on highlight.js which removes
| dependence on third-party services. It's just insane, using heavy
| iframes for small code snippets.
|
| https://gohugo.io/content-management/syntax-highlighting/
|
| https://highlightjs.org
| withinboredom wrote:
| I remember when I worked at Automattic and discovered that the
| gist's heart emoji was actually served by WordPress and not
| GitHub. They fixed it within a few weeks, but it was like that
| for years...
| difosfor wrote:
| Shouldn't class lty-playbtn be lyt-playbtn?
| paulirish wrote:
| lol, yes. good eye. ;) https://github.com/paulirish/lite-
| youtube-embed/issues/65
| IshKebab wrote:
| IMO YouTube embeds are a bad experience anyway, especially on
| mobile. Just put a poster image with a link to the actual YouTube
| video.
| mrkramer wrote:
| On mobile you can tap "Watch on YouTube" and it will deep link
| and open the video inside your YouTube mobile app.
| schiffern wrote:
| If your mobile browser can run userscripts I threw something
| together to rewrite Youtube embeds into links.
|
| Using the preview sounded cool so I added it. Change
| SHOW_PREVIEW_IMAGE to true.
|
| https://news.ycombinator.com/item?id=40898049
| didgetmaster wrote:
| Get the climate change activists involved. How many of these
| videos have to play before the wasted electricity is equivalent
| to a car running for a year?
| phh wrote:
| In my business area (ISP), when doing carbon accounting, we
| have "scope 3" which includes the electric consumption we incur
| the electric consumption of our devices at user's home.
|
| A first step towards reducing those externalities [1] is
| mandating that they power consumption Youtube incurs is
| accounted for. -- Another Youtube thing that made my computer
| screams is "theater mode", eating so much CPU for eye candy on
| so many devices ought to be at least declared.
|
| [1] To explain the externality: Google probably does that
| because they make maybe +0.5% revenues by click to video, at
| almost 0 cost for them. Since the whole extra cost is paid for
| by the user (by requiring a bigger computer, by consuming more
| electricity). The price for the user to view a page without the
| embed and with it can be something like +20% at no gain for
| them. It's so small than no sane user make those computations,
| but if you start accounting like a company, you would see the
| difference. (Plus obviously all the ecological externalities)
| jeffbee wrote:
| This must be intentionally hyperbolic or you have no concept of
| how much energy is needed to run a car.
| mmmmmbop wrote:
| The author says they don't believe that a lighter version has
| been shown to reduce engagement.
|
| I, on the other hand, fully believe that.
|
| The recommended lite-youtube-embed project page has a demo of
| both lite and regular players [0], and the lite version takes
| _noticeably_ longer to start playing the video.
|
| Every additional millisecond of load time will reduce engagement,
| and here the difference is more on the order of hundreds of
| milliseconds or more.
|
| [0] https://paulirish.github.io/lite-youtube-embed/
| tantalor wrote:
| Why is it slower?
|
| It feels same to me (Pixel phone)
| maxloh wrote:
| If I understand it correctly, the library displays a
| thumbnail and defers loading the YouTube embedded player
| iframe until you click on it, thus improving responsiveness
| (page load speed is not affected by its iframe however).
| dubcanada wrote:
| I don't think the point of this is to replace highly critical
| videos. It's to replace videos like installation instructions
| which may only be needed by 10% of your users.
|
| Not only that but 250ms is the average reaction time of a
| human, you don't notice an extra 5 milliseconds.
|
| If a video is required on your website for engagement you
| probably shouldn't be hosting it on YouTube anyways.
| lotsofpulp wrote:
| >Not only that but 250ms is the average reaction time of a
| human, you don't notice an extra 5 milliseconds.
|
| If this is true, then why are online first person shooters
| noticeably worse when playing with a 250ms ping connection
| compared to a 5ms ping? 250ms ping is basically unplayable.
|
| If I recall correctly. I stopped playing video games many
| years ago, because my college's internet connection didn't
| offer low enough latency to be able to play.
| thfuran wrote:
| The difference between 5 ms and 250 ms is a lot more than 5
| ms, so there's no contradiction.
| lotsofpulp wrote:
| Oops, yes I misinterpreted that. I was thinking how can
| 250ms be the average reaction time when it's too slow of
| latency to play a video game, wouldn't average reaction
| time have to be lower since people do notice lag at 250ms
| pings?
| Filligree wrote:
| Humans can notice and characterise much smaller
| intervals, down to somewhere around five milliseconds.
|
| We still aren't capable of reacting faster than about
| 250. However, if you have latency of 250ms then your
| total reaction time isn't 250, it's 500.
| LocalH wrote:
| With aids, we can perceive and notice even smaller
| intervals. I play a lot of Fortnite Festival, which is
| the Rock Band-style mode added near the end of the year.
| This game, unlike any previous game in the genre, has
| "perfect" judgements for note hits. The window for a
| perfect judgement is something around 20 or 30ms. The
| game also gives you an average offset from "dead on" for
| each song, measured in milliseconds. Since the perfect
| judgement is immediate feedback, it enables players to
| perceive when they are just a few milliseconds off and
| correct for it. I regularly get average offset results of
| +/- 3ms or better, including plenty of 0ms average
| offsets (this is of course averaged across all notes in a
| song, which I am playing on a plastic guitar on Expert
| difficulty).
|
| I'm nowhere close to the best player either, there's one
| player who recently got one of the most impressive full
| combos of the Metallica song One that could ever be done
| - they hit all notes without mistake, they got 100%
| perfect judgements, _and_ they got the #1 leaderboard
| score, meaning that not only did they hit _all_ notes
| within the 20-30ms "perfect" window, _but_ they also
| "squeezed" overdrive activations within that window to
| activate and hit the first note as late as possible, and
| hit the first note after that overdrive activation would
| end as early as possible to still get it under the extra
| 2x score multiplier that overdrive brings.
|
| The game genre also overcomes the relatively huge (in the
| context) human reaction time by providing you gems to
| read before the strikeline (or "now bar"), so that you
| can basically internally correct for your reaction time,
| similar to how people reading sheet music can perform in
| lockstep rhythm when everyone is skilled.
|
| It's amazing what different forms of augmentation can do
| to help paper over the inherent shortcomings in our
| senses.
| bongodongobob wrote:
| Rhythm is a completely different beast though because you
| can anticipate. Most musicians would be more accurate
| than the average person but wouldn't do any better in a
| "click the mouse when the screen flashes red" type test.
| mattkrause wrote:
| A key difference here is that you're able to anticipate
| and plan upcoming actions, because you're familiar with
| the general structure of music and/or the specific song.
|
| Even the experts couldn't respond to an unpredictable
| stimulus in 30ms; instead, they're choosing between (say)
| a 330 ms response and a 340 ms one. This is, of course,
| still crazy impressive.
| mattkrause wrote:
| "Reaction time" isn't really a single value: it depends
| immensely your own attributes (age, experience, level of
| alertness or fatigue), on what you're reacting to and how
| you react to it.
|
| Under certain (admittedly very specific) conditions,
| people can view an image, categorize it, and indicate the
| category with eye movements, all within 120ms. Here's one
| demonstration:
|
| https://www.sciencedirect.com/science/article/pii/S004269
| 890...
| ImprobableTruth wrote:
| Latency is magnitudes more critical when it's something
| where you have to react.
| qwery wrote:
| > Not only that but 250ms is the average reaction time of a
| human, you don't notice an extra 5 milliseconds.
|
| Please stop repeating this sort of thing as a simple fact.
| Time and latency are difficult things to reason about and
| simple explanations sound particularly convincing when one
| lacks an intuitive understanding of the subject.
|
| Perceived latency is not the same thing as "reaction time".
| What reaction was measured? How? From what stimulus? Your
| reaction time _number_ does not support your claim that
| humans can 't notice a 5ms difference in lag.
|
| In any case, you are misunderstanding and misrepresenting the
| comment you replied to.
|
| When you are talking about an organisation like Youtube
| (size, money, mercenary, malicious, etc.) and discussing
| metrics like this, individual milliseconds is not an
| unreasonable unit to use. Consider the volume of the data.
| Nobody is saying that if something takes 5ms longer to load
| that no single human being will be capable of waiting for it
| anymore.
|
| Further, your 250ms is perfectly in the range of the parent
| comment's order of magnitude of hundreds of milliseconds.
| nnf wrote:
| I would _much_ rather wait a few hundred milliseconds for a
| video to start during the few times I decide to watch an
| embedded video than to wait for the full video player to load
| every single time I visit a page with an embedded video that I
| 'm never going to watch. Similarly, I would _much_ rather have
| every stoplight I approach be green for me rather than having
| every light be red but for not very long.
| vasco wrote:
| These things are not optimized for what we prefer but for
| what leads us to behave in a way that maximizes a particular
| metric, for youtube it's global watch time.
| Retric wrote:
| Global watch time isn't something non Google website owners
| care about. Remember, Google benefits from making the web
| worse.
| FredPret wrote:
| Do they? They have the biggest browser, an online office
| suite, a cloud, and a giant ad network. They want to
| maximize internet use, or they should want to.
| kibwen wrote:
| Unfortunately no, Google wants to maximize their profit,
| and they'll enshittify the web in that pursuit until it
| collapses. They have Android, they don't need the web to
| exist.
| klyrs wrote:
| > They have Android, they don't need the web to exist.
|
| If not for apple, I'd agree.
| FredPret wrote:
| Apple sells expensive solutions to cash-rich consumers
| (some of whom are also time-poor) who are willing to
| throw money at a technical problem (setting up a device
| with an OS) to make it go away (ie, buying an iPhone,
| iPad, and Mac).
|
| Why would you ever want to advertise to anyone else?
|
| No internet = no Google.
| troupo wrote:
| > They have Android, they don't need the web to exist.
|
| In 2023 77% of Google's money came from online
| advertising. While the percentage is lower than in 2017
| when it was 86%, Google is fully dependent on the web.
| troupo wrote:
| Google makes the web better for _itself_. Which is not
| the same as making it better for everyone else. After
| all, 77% of their revenue comes from online ads.
| FredPret wrote:
| No users = no clicks = no Google. Their incentive is to
| strike a balance between profiting off users and driving
| all the users away. I'm not commenting on whether they're
| getting it right.
| moqmar wrote:
| Also, ads. I guess the shorter the time is between clicking
| the play button and the ad starting, the more people will
| have "seen" more of the ad before deciding that the video
| isn't worth watching the ad.
| kylebenzle wrote:
| Did you even try the example? Obviously not. It's closer to 4
| seconds difference, PLENTY of time for me and a lot of people
| to click away.
|
| It doesn't help a discussion to ignore the topic at hand,
| create a straw man just to easily vanquish him. Who are you
| even talking to here, just yourself?
| cornholio wrote:
| Sounds like a bug that could most likely be fixed. I don't
| see any noticeable difference, maybe one or more spins of
| the throbber, practically instant on all versions.
|
| What could possibly youtube be preloading in that 1.2MB
| that could genuinely and legitimately speed up video play
| by 4 seconds, and that can't be cached? It just stretches
| credulity.
| bcrl wrote:
| How will Google collect data about every page load then?
| lelandfe wrote:
| It also seems like it takes two clicks to start a video? Is
| that a bug?
| dangus wrote:
| This is a good point. Google doesn't care about the total page
| load time of your website, they care about the load time of
| their video.
| knome wrote:
| Does the potential lesser engagement with videos matter in the
| face of those videos causing a delay in loading the page that
| displays them? You'd need to check per-video engagement drop
| against people not bothering to engage with the site in the
| first place.
| estebank wrote:
| This is an example of the tragedy of the commons: the watch
| time effect is tracked by YouTube, which maximises for it,
| but the drop off of visitors to the site is something YouTube
| doesn't "care" about (doesn't track it directly, doesn't
| optimize for it, etc.).
| crabmusket wrote:
| In this scenario, what is the "commons"?
| qwery wrote:
| I'm not seeing such a difference, but it is there. I'd be
| surprised if it was as high as 100ms. Obviously different
| computer environments[0] will have an impact here.
|
| I would be much less likely to notice it as "slow" if it didn't
| show me a spinny-spin. It's advertising that it's slow!
|
| I agree that the click-to-playback lag time would have such an
| effect, but how significant it would be is unclear. It would
| take an entity the size of, say, Youtube, to begin to measure
| this sufficiently.
|
| [0] Firefox, 2(?) year old laptop, i7-1185G7, windows 11,
| updating Edge (in 32-bit mode) 24/7, haven't rebooted for a few
| weeks
| divbzero wrote:
| Same here: While the difference in speed is noticeable, I
| would be surprised if it's much more than 100ms on this
| specific machine (Safari, 1 year old laptop, Apple M2, macOS
| Sonoma).
| skybrian wrote:
| I suspect you're right, but on the other hand, I think it's
| useful to think critically about whether starting the video
| faster is worth it if it makes the web page that it's embedded
| in load slower. The "every millisecond counts" argument applies
| to the web page too. If the user bounces off the web page, they
| won't get to the video anyway.
|
| Also, maybe it's fine if people don't want to play the video?
| Personally, I appreciate it when a web page includes a summary,
| so that I can _avoid_ watching a video. (I prefer not using
| YouTube for anything other than listening to music or
| occasionally watching a movie.)
|
| Video can be a useful tool, but consider whose interest it's in
| for you to encourage your audience to watch more TV. Is it
| really serving your users?
|
| Even when I do want to watch a video, it's selective. One thing
| I find rather frustrating about YouTube's redesign (on desktop)
| is that it devotes so much screen real estate to promoting
| videos other than the one you're actually there to watch. I'd
| prefer fewer distractions.
| Stratoscope wrote:
| > _One thing I find rather frustrating about YouTube's
| redesign (on desktop) is that it devotes so much screen real
| estate to promoting videos other than the one you're actually
| there to watch. I'd prefer fewer distractions._
|
| The F key is your friend. It puts the video full screen. You
| don't even have to find the full screen icon at the bottom
| right of the video, just hit F.
| brookst wrote:
| But I don't want full _screen_ , I want it to take up the
| full _window_ that I have allocated to the browser, while
| still allowing me to multitask in other windows.
| nulbyte wrote:
| I love Firefox's picture-in-picture mode for this exact
| reason. I think there is an extension for Chrome also.
| hombre_fatal wrote:
| It's in Chrome natively. But in Youtube you have to right
| click on the video twice.
|
| First to trigger the Javascript context menu, and again
| to trigger the native one which will have the "Picture in
| picture" option. And there are actually two different
| native context menus, so if the PiP one doesn't pop up,
| you might have to try multiple times.
|
| Very weird UX instead of just giving us a PiP button
| under the video.
| luyu_wu wrote:
| Maybe try the T key for theater mode!
| davisoneee wrote:
| You can make firefox fullscreen _within the window_ by
| changing a flag in about:config ... full-screen-
| api.ignore-widgets (set to true)
|
| then, when you press `F` on a video, you will remove all
| firefox 'decoration', just like fullscreen mode, but
| it'll respect whatever position and size you have set for
| the browser.
| roelschroeven wrote:
| > One thing I find rather frustrating about YouTube's
| redesign (on desktop) is that it devotes so much screen real
| estate to promoting videos other than the one you're actually
| there to watch. I'd prefer fewer distractions.
|
| Theater mode (shortcut 't') is a bit better. But yes, I too
| would like a mode where the video fills the whole browser
| window.
| tjoff wrote:
| > _Every additional millisecond of load time will reduce
| engagement_
|
| This is something people believed in the 90s. None of the
| megacorps give a damn about that as is evident by their
| behavior. If it doesn't matter for them it doesn't make sense
| for you to optimize that on their behalf.
|
| It is a non-issue for this usecase.
|
| But _please_ do care about it for the rest of your stack.
| qwery wrote:
| In the 90s, there was no "engagement" and "content" just
| meant the content of the thing you were talking about, but I
| digress...
|
| > None of the megacorps give a damn about that as is evident
| by their behavior.
|
| The rumour (and extrapolation) the discussion is based on is
| that Youtube prefers their bloated player to an unknown
| alternative because it makes the videos play faster, which
| drives "engagement". That is, in this case, the "megacorp"
| literally does care about that.
|
| > it doesn't make sense for you to optimize that on their
| behalf
|
| This is certainly true, but I don't think that's what the
| parent comment was suggesting.
| froggit wrote:
| > In the 90s, there was no "engagement" and "content" just
| meant the content of the thing you were talking about, but
| I digress...
|
| Sometimes i think back at this idea from the 80s when i
| need some perspective:
|
| "Productivity soars when a computer and its users interact
| at a pace (<400ms) that ensures that neither has to wait on
| the other."
|
| https://lawsofux.com/doherty-threshold/
| qwery wrote:
| That website/page is a bit weird. It seems to be based on
| a TV show[basedon]?
|
| What I assume is the actual IBM report[0] might interest
| you.
|
| [0] https://www.computerhistory.org/collections/catalog/1
| 0275139...
|
| [basedon] https://daverupert.com/2015/06/doherty-
| threshold/
| giancarlostoro wrote:
| I remember when the old youtube player would just load and
| buffer the entire video, making replay ability very easy since
| you didnt need to redownload it. Somehow we regressed.
|
| Google takes everything that works PERFECTLY FINE and turns it
| into a steaming pile of ... I am gonna stop right there.
| marcosdumay wrote:
| It used to be that if your network was bad, you could just
| play the video once without watching, and then you could play
| it again and watch it without it locking.
|
| Nowadays, if your network is bad, you can just forget it.
| Every single media site seem to have migrated into this
| format at around the same time. It's obviously to stop
| downloaders, what it evidently didn't, but it will never
| change back.
| ric2b wrote:
| Is it to stop downloaders? I doubt it since they work just
| fine, it's probably just a way to reduce resource usage on
| more constrained platforms like low end mobile phones or
| smart tvs.
|
| There is probably a lot of code sharing among all platforms
| such that companies don't want to support two different
| buffering flows.
| chris_pie wrote:
| It also decreases bandwidth and processing server-side,
| when a user leaves before finishing the video.
| kylebenzle wrote:
| Why not just go with the flow and use/develop a downloader
| browser extension?
| marcosdumay wrote:
| I've used them a few times for dealing with a bad
| network.
|
| But this is a "me" solution, and I'd imagine those sites
| would like to be accessible for more people. (I'm
| personally a very bad "customer" for them.)
|
| Anyway, it's a mild annoyance for me (I have that "me"
| solution), and not really my problem to solve.
| froggit wrote:
| > I remember when the old youtube player would just load and
| buffer the entire video, making replay ability very easy
| since you didnt need to redownload it. Somehow we regressed.
|
| When did that change? I already considered youtube's UX to be
| so hostile I'll go for (literal, not metaphorical) years
| between intentionally watching 2 videos off there. It's also
| possible i just didn't notice as the data transfer from there
| is impressively fast via google fiber (likely not
| coincidental).
|
| > Google takes everything that works PERFECTLY FINE and turns
| it into a steaming pile of ... I am gonna stop right there.
|
| Google's SDLC in 4 steps: 1) "Acquire" software idea
| (invent/buy/steal/kill/etc). 2) Dev to critical mass
| (unlimited money cheat). 3) Enshittify (Ads team trounces Dev
| team because capitalism). 4) Sunset before mob descends with
| fire and pitchforks.
| Scaevolus wrote:
| That was the ancient flash player days, where it would buffer
| the entire FLV. One time a kid in HS Physics had 20 tabs of
| anime buffered on his absurd 17" laptop.
|
| With more bandwidth and higher resolution videos, buffering
| an entire video in RAM is no longer a great option... plus
| they can make you buy YouTube Premium for offline playback!
| giancarlostoro wrote:
| I remember even after flash player it buffered video
| though? They changed the behavior after Flash was dead
| probably as someone else suggested to not waste bandwidth
| on people closing the tab.
|
| Edit: in fact every native web video player downloads as
| much as possible as far as I can tell.
| _wire_ wrote:
| > Every additional millisecond of load time will reduce
| engagement
|
| LOL!
|
| What's engagement?!
|
| Half the embeds I see don't work because the content is
| censored or rotted.
|
| For content that plays, the rush for my attention includes an
| overwhelming dynamic of at least three parties with vested
| commercial interested in the occupation of my mind cramming
| unrequested and unwanted advertorial content into my nervous
| system.
|
| Blocking unrequested content and keeping a healthy distance
| from tracking adds many seconds of delay to access of requested
| content, and the requested content typically has a cognitive
| half-life of a few seconds to minutes.
|
| And the requested content itself typically contains order
| 10,000x milliseconds of insipid attention mgmt jingles and
| branding setup.
|
| Then to finish it off. Even the most high-minded productions
| waste minutes of egress begging for "likes, subscribe,
| comments," reading off lists of sponsors with silly handles,
| admonishments for upsells, and cappers to "hit the bell, it's
| so, so, important", immediately following which the player bot
| resets to cramming a new unrelated vid into my sockets.
|
| Engagement?! Pfft. It's an incursion.
| cogman10 wrote:
| > Every additional millisecond of load time will reduce
| engagement,
|
| I do not believe this. Humans can't tell the difference between
| 1 and 10ms. I'd love to see the study that actually proves this
| assertion. I suspect, it's never been done for embedded videos
| just webpage load time.
|
| But further, we are talking about embedded videos that you have
| to click to start anyways. Presumably, the person clicking the
| video has a desire to watch it and thus can stand that the
| video takes an extra 300ms to load.
| squigz wrote:
| > Every additional millisecond of load time will reduce
| engagement
|
| Is there any data on this?
| stemlord wrote:
| I thought we were past the era of counting in milliseconds for
| load time now that half the web insists on using cloudflare
| security checks
| II2II wrote:
| Tangent: I find tremendous irony in the video used as an example.
| It is for the remake of a game that is about problem solving and
| story telling, yet the remake requires vastly more resources than
| the original. Yes, there are reasons for the increased resource
| usage. On the other hand, there are reasons to use the more
| resource intensive version of the YouTube embed.
|
| I suppose the moral of the story is that software will grow to
| consume the resources available to it. Often, if not most of the
| time, there will be benefits to that increased resource usage.
| Yet that won't prevent people who prioritize factors like
| efficient resource usage from seeking alternatives they view as
| better.
| pacifika wrote:
| A tiny script Click to toggle the display css attribute prevents
| it loading as the page loads
| occz wrote:
| To put this into context, the player element might load 1.3 mb
| but loading a video can easily be in the range of 50 mb.
| masklinn wrote:
| Which is only relevant if 100% of users load the video every
| time they hit the page. Because the 50M is paid by those who
| watch the video while the 1.3M is paid by everyone opening the
| page.
| charrondev wrote:
| I work on a community forum platform and we detect YouTube embeds
| and replace them proxied thumbnails that don't load until
| clicked.
|
| Just because one person in a thread shares a YouTube video
| doesn't mean everyone else loading that page should have to
| download 1MB+ of YouTube's JavaScript bloat and have their IPs
| tracked by google.
| mindhunter wrote:
| Do you also cache or proxy the thumbnail? Google can also track
| them when hotlinking it.
| tczMUFlmoNk wrote:
| GP says "proxied thumbnails", so it sounds like yes.
| pier25 wrote:
| Is there a similar solution for SoundCloud?
|
| Their player is also super bloated.
| diggan wrote:
| You can basically do this with any embeds (granted they don't
| do a lot of global fuckery, which is a lot of them). Make
| sure the embed code gets evaluated within a function, then
| call that function when the user clicks on your "proxy"
| image. You might have to do a replace of the DOM elements as
| well, so the embed code gets what its expecting.
| paulirish wrote:
| There are a few "facade" solutions listed at https://develope
| r.chrome.com/docs/lighthouse/performance/thi... But.. AFAIK
| nobody has made one for Soundcloud.
| btouellette wrote:
| I've got a site that is basically infinite scroll of mostly
| YouTube, SoundCloud, and Reddit embeds and had to do this for
| YouTube for it to even be functional. Using the YouTube
| provided thumbnails though since I'm not too concerned about
| tracking.
| BodyCulture wrote:
| Please more respect for your users, as should be appropriate
| for a webmaster. If you personally do not mind tracking, OK,
| but please do respect that a visitor of your website might
| have different opinions. Thank you!
| wbobeirne wrote:
| Users are also capable of blocking traffic from their
| client if that's something they care about.
| griftrejection wrote:
| And if you know that most of them don't, then you're
| still negligent. God, this pedantry is getting so
| incredibly old.
| scrivna wrote:
| It sounds like the users visiting this site are there to
| watch YouTube videos
| donatj wrote:
| I am not understanding how Bananas play into this?
|
| Is that a term for curly braces I am unfamiliar with or something
| with? Is code being "banana heavy" a term for code having a lot
| of scopes thus being bloated? I'm grasping at straws here.
| tedunangst wrote:
| Bananas are crazy.
| poikroequ wrote:
| https://www.youtube.com/watch?v=BZ6Ev46i2to
| pseudalopex wrote:
| Why not look it up? It means crazy.
| donatj wrote:
| I googled "bananas heavy" but I didn't get much
| spencerchubb wrote:
| Perfect use case for chatgpt or other llm
| pseudalopex wrote:
| Are you serious? It's the primary use for a dictionary. And
| did you try ChatGPT? It suggested bananas heavy meant
| bananas are physically heavy because they are ripe.
| jondwillis wrote:
| dictionaries do not provide much context that would un-
| confuse someone who has not come into contact with a
| colloquialism.
| pseudalopex wrote:
| The context is bananas means crazy. Dictionaries provide
| this context.
| donatj wrote:
| It would not have helped me in this situation. My
| assumption was "bananas heavy" was a phrase I was
| unfamiliar with, so I was trying to look that up.
| "Bananas heavy" is not in the dictionary,
|
| I fully understood that bananas can mean crazy, but what
| I do not understand is the sentence and the context. I
| never would have used the word with that meaning like
| this.
|
| Who would say something like this? I still don't
| understand why a person would say "bananas heavy" to mean
| "YouTube embeds are bloated". It just sounds so awkward
| and bizarre.
| popcalc wrote:
| bananas == crazy; (x heavy) == crazy heavy
| marcosdumay wrote:
| Yet, when I put "What's the meaning of "bananas heavy"?"
| in perplexity, it explains it perfectly well.
|
| One of the easiest things for a LLM to "memorize" is the
| dictionary. And it makes for a much more flexible one.
|
| It even suggest additional queries where it explains why
| "bananas" is used on that phrase. The only problem I
| found on the query is that perplexity seems to be de-
| emphasizing its sources, what IMO is bananas. It just
| pushes the site into direct competition with ChatGPT and
| removes most of its value.
| spencerchubb wrote:
| Yes I'm serious. Here's the prompt I would use: "what
| does bananas mean in this sentence: YouTube embeds are
| bananas heavy and it's fixable"
|
| Put it in google, and it doesn't give anything useful
|
| Put it in an LLM, and you get a correct answer because
| LLMs can understand full sentences
| cricalix wrote:
| Slang for crazy or deranged. In this case, "bananas heavy"
| would probably equate to "crazily heavy", which would then
| equate to "crazily large for the functionality".
|
| https://english.stackexchange.com/questions/74581/why-does-b...
| Has a reasonable-reading accepted answer.
| Aurornis wrote:
| > I don't think we have any good answers here. In fact, I heard
| from a little birdie who ran it up the pole that they have tested
| lighter embeds and found them to reduce engagement.
|
| We're clearly missing some huge part of the story.
|
| Obviously, faster load times should improve engagement. So if
| engagement went down with lighter embeds, that implies that some
| feature or functionality had to be sacrificed. Yet this blog post
| claims nothing is sacrificed.
|
| Something is missing from this story.
| qwery wrote:
| > Obviously, faster load times should improve engagement.
|
| I don't think it's this clear-cut. People can have different
| levels of expectation and tolerance for loading times of
| different things, and the page (post/article/whatever) is a
| different thing to the video embedded in it.
|
| The load time of the rest of the page is also not necessarily
| limited by the loading time of the embed (depends what you're
| looking for). Arguably, the overall page load time will mask
| the content (embed) load time.
|
| Finally, and perhaps most importantly, the loading time of the
| embed is a different thing to the loading time of the video.
| The metric to look at may be click-to-playback lag.
| dceddia wrote:
| I recall an article where Facebook or Uber or some other big
| tech co found something similar when they added some
| optimizations, and it turned out that it was being accessed by
| an entirely new market that couldn't even load the page before.
|
| I wonder if it's a similar thing here. Maybe the lighter embed
| is small enough that a huge swath of people is actually able to
| load a video now, but they bounce because playback is too slow
| on their device/connection. It would shows as a higher
| percentage of "person stopped watching video" instead of
| (nothing, because they never fully loaded the player).
| kirubakaran wrote:
| It was actually YouTube:
| https://blog.chriszacharias.com/page-weight-matters
| dceddia wrote:
| lol amazing, thank you for finding that.
| dangus wrote:
| My favorite part of the article:
|
| > They found, quite counterintuitively, that average page load
| times went up. But with a deeper look, they found that the
| lighter page was able to reach more people, including people on
| low-power low-internet-speed devices who were able to actually
| use YouTube for the first time, and them using it much more
| slowed those averages. That's awesome! The speed of using the
| site was up relatively for everyone. The metric of the average
| page load speed was a red herring and ultimately not meaningful.
| Havoc wrote:
| I'm seriously considering just setting up a service that
| downloads everything in my preferred channels overnight and re-
| serves it locally. It'll increase their cost and decrease their
| revenue but frankly I'm just getting fed up with their UX. It's
| just sooo fuckin bad I do wonder whether YT staff actually uses
| it.
|
| e.g. lately the thumbnails have a popup overlay that pops into
| existence at last second over the thumbnail, basically hijacks
| your click and navigates you away from yt and to a
| support.google.com page that discusses paid product placement. No
| google thats not why I clicked on a video thumbnail.
| Larrikin wrote:
| How do you filter out what you actually want?
|
| There are no tools to sort through subscriptions that I know
| of. I am subscribed to some channels that put out tons of
| contents where I usually don't want to watch it, but the stuff
| that I do want to watch is high priority, channels where
| everything is priority, and channels where it's content I just
| want to watch occasionally when it happens to show up and I'm
| in the mood.
|
| I learned long ago that anything I want to watch more than once
| should be saved locally when a record label made a group I
| liked delete all their content to promote a new album, but I
| need a solution for filtering the one time views.
| Havoc wrote:
| >How do you filter out what you actually want?
|
| I wouldn't. Bulk download it all and decide locally.
|
| Not something I'd usually do because it is wasteful and not
| being a good net citizen but sufficiently annoyed that I'm
| willing to colour outside the lines here.
| l72 wrote:
| I previously used FreshRSS to follow youtube channels I was
| interested, but I've switched to Tube Archivist[1] + the
| Jellyfin Plugin [2]. Now my youtube channels are automatically
| downloaded to my server and I can watch them through Jellyfin,
| like any other show. I never have to deal with YouTube's
| terrible UX anymore. [1]
| https://www.tubearchivist.com/ [2]
| https://github.com/tubearchivist/tubearchivist-jf-plugin
| QuadmasterXLII wrote:
| yt-dl, chron, and onedrive or icloud together achieve this
| demorilo wrote:
| What is the problem of sites hosting their own videos?
| Aachen wrote:
| Tweakers.net mentioned in their podcast a few weeks back that
| they had this, but that people hated the player and it was a
| lot of work maintaining the back-end hosting thing. I don't
| understand what they need beyond Nginx with an FTP drive (or
| whatever WYSIWYG tool they also use for uploading images with
| the news article) and add `<video src=your.hls></video>` into
| the article. Browser does the rest of the work. In the Flash
| era this was different but that's been a while
|
| So I don't know the answer to our question either but according
| to them we're overlooking something
| donohoe wrote:
| One way to help reduce overall weight of embeds (and improve the
| UX imho) is to block the ads - if you are able to leverage
| "Content Security Polices" on your pages.
|
| Example META tag: <meta http-equiv="Content-
| Security-Policy" content="default-src 'self' 'unsafe-
| inline' *.your-cdn-if-any.com www.youtube.com
| *.googlevideo.com *.ytimg.com">
|
| More info: https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Headers/Co...
| 8organicbits wrote:
| That's clever, well worth its own blog post.
| qwery wrote:
| On not believing the reduced engagement rumour and the suggested
| 'lite-youtube-embed'[0]:
|
| I am not surprised to hear that a different player will be
| treated differently by users. You just need it to look slightly
| different or behave slightly differently and it's completely
| alien and not to be trusted.
|
| The lite-youtube-embed as demoed (even with the title visible)
| doesn't let me click through to the actual youtube page. There's
| no link. It could even appear as a no-right-click-esque attempt
| to _prevent_ me from going to the actual source of the "content"
| -- it's hostile. Of course, this specific feature could be added
| easily enough, but it points out a bigger issue.
|
| I almost never play embedded video, but when I do it might as
| well be the normal youtube experience. If you've wrapped it in
| what _looks like yet another layer_ (for an unknown purpose), I
| 'm going to be less likely to click on it. You're asking me to
| contend with youtube/google _and_ another unknown entity.
|
| This article's "nothing sacrificed" is an example of the mistaken
| belief that developers know how their (or other) software is used
| by users. You don't and you can't. Not really. You're always
| guessing.
|
| To be clear, I also want less videos everywhere, less google in
| everything, less megabytes of javascript in everything, etc.
| Please stop embedding youtube videos everywhere, to vote for a
| better web.
|
| [0] https://paulirish.github.io/lite-youtube-embed/
| GuB-42 wrote:
| [Ignore this, everything is ok now]
|
| For me the website is slow as to border on unusable. I have one
| core at 100% on Firefox 115 / Debian 11, I guess there is a busy
| loop somewhere in the JS.
|
| Works fine on Chrome(ium).
|
| I know it is usually frowned upon to comment on the website
| itself rather than the content, but considering the nature of the
| website, I think it is relevant.
|
| Edit: Looked in a bit more detail and it looks CSS-related, not
| JS-related as removing the main style sheet fixes the problem. It
| happens even in safe mode (no extensions). Possibly a Firefox bug
| (version is 115.12.0esr, from the Debian 11 repository), but it
| doesn't happen anywhere else.
|
| Edit2: Updated my system, rebooted, etc... it fixed the problem.
| So either I had something messed up with my system, or the author
| fixed it, anyway, everything is ok now.
| tambourine_man wrote:
| I know it's frowned upon and even in the guidelines, but I
| never understood why. This is Hacker News, the meta discussion
| on how a site works (or doesn't) is as relevant and its
| content.
| 8organicbits wrote:
| I think HN is aiming for thoughtful and novel comments on the
| content of the article; complaints like "page loaded slowly"
| are shallow. The parent comment feels more on-point since the
| article is about optimizing websites and the post is itself a
| demo.
|
| I'm seeing <1% CPU on Firefox/Debian, but I have video
| autoplay turned off (I rarely want to watch them).
| tambourine_man wrote:
| Shallow comments are always bad, but a thorough examination
| on what's triggering that infinite loop, if that's really
| type case, would be great IMO, regardless of what the
| article is discussing in the first place.
| rolobio wrote:
| The web is slowly becoming chrome only and I hate it. I
| recently had to switch to Chromium because Firefox simply did
| not work for the websites at my job.
| jeffbee wrote:
| When I navigate to the test page[1] by the author of lite-embed,
| the standard variant transfers 82k. According to browser stats,
| the largest element "base.js" has been cached for several days. I
| imagine that the authors of YouTube who are undoubtedly as
| sensitive to the costs of transferring bytes as anyone have
| analyzed the problem with browser caches taken into account.
|
| https://paulirish.github.io/lite-youtube-embed/variants/yt.h...
| divbzero wrote:
| > _The weight also grows linearly with every embed--resources are
| not shared: two embeds weigh 2.4 MB; three embeds weigh 3.6 MB
| (you get the idea)._
|
| Why aren't these resources retrieved from cache? Shouldn't the
| same-origin policy should allow for use of cached resources since
| they are all loading from _www.youtube.com_?
| ZeljkoS wrote:
| Not mentioned in the article, one of the main reasons to ALWAYS
| do this is SEO. Regardless if users will play the video or not,
| web crawlers will not play the video and Google will penalize
| your SEO ranking if you use official Google's YouTube embed :D
|
| We implemented our own thumbnail image trick on TestDome homepage
| a few years ago (https://www.testdome.com/). Thumbnail is from:
| https://img.youtube.com/vi/gPQQg4yZqt8/sddefault.jpg
| 015a wrote:
| > If I were Team YouTube, I'd get loading="lazy" on there to help
| with performance right away. No need for videos that aren't even
| visible on the page to load right away.
|
| This would hurt advertising impressions.
| knallfrosch wrote:
| The page is broken on ios/safari with text size not set to 100%
|
| I don't usually care, but when you hand out advice to other sites
| and call your little text blog "Frontend-Masters", it better
| work.
| lulzury wrote:
| If you have a small site or just don't want any requests to
| Google for privacy reasons, consider just straight-up downloading
| the video and embedding it in a video tag. There are yt_dlp
| wrappers for most popular languages (even js).
|
| I'm pretty sure even embedding their poster thumbnail results in
| them getting your IP and other information so consider
| downloading that as well (from
| https://img.youtube.com/vi/[TAG]/hqdefault.jpg).
| sva_ wrote:
| I feel like some content creators might not be very happy about
| that
| dmonitor wrote:
| doing this on a broad scale is a great way to get sued
| xigoi wrote:
| So how about disallowing YouTube embeds and requiring users
| to upload videos?
| griftrejection wrote:
| In hostile jurisdictions, maybe. But there are servers all
| around the world. Take your pick.
| userbinator wrote:
| Embedded videos could just be a <video> element pointing to the
| file on YouTube's servers (and I believe for a short time long
| ago this was actually possible), but clearly commercial interests
| got in the way.
| dewey wrote:
| And now make it seekable, dynamically adapt bitrate, add
| subtitles, have clickable areas on the video and support all
| browsers and operating systems with various kinds of DRM and
| codecs and it's not "just add a html tag" any more.
| gwern wrote:
| OP: the YT loading paradox you are thinking of is
| https://blog.chriszacharias.com/page-weight-matters
___________________________________________________________________
(page generated 2024-07-07 23:01 UTC)