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.
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.
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!
This is not something they should have to care about. And once you leave the tech savvy community then can not take care of it via content-blockers... You should do the correct thing by default, which is not supporting adtechs' psychological warfare agains the population imho.
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.
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.
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.
> 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.
I tried the same route, but got the logs correctly. It gave me a HTTP 410 error. I wouldn't be surprised at all if VLC's youtube plugin is just too old and there's a better one somewhere else. But in the meanwhile, mpv's plugin works (if you're using yt-dlp and not youtube-dl, that is)
Logs not being directly visible in the VLC UI and not having a default log file location plus the fact that even going to advanced settings and configuring things doesn't make logs show up after the first try is not Google's fault, though.
Despite having defended FOSS and advocated VLC ... I understand your viewpoint here. Calling on people to contribute bugfixes isn't especially realistic. Filing a bug on the fact that VLC has poor debug/log tools would be helpful though.
Particularly as a useful logging / debugging capability should enable more useful bug reports specific to function.
Sorry it's not working out for you, thanks for trying regardless.
I'm just jaded at this point. FOSS won the battle and lost the war. It's been subsumed into the bowels of these corporations that are ending up mega predatory.
I've used VLC successfully in the past on Android using the "stream" option. When I want to view video (as opposed to just listen to audio, my usual Android mpv use-case) that's delivered joy. On MacOS, I'll use mpv to play either audio only or video, with joy in both cases.
Don't forget that the other side of the equation is YouTube ACTIVELY WORKING TO BREAK COMPATIBILITY, and with considerable success. E.g., Invidious and Piped had been b0rk3n for a few months, though on checking again in the past few days, Invidious at least seems to be working again. So placing the whole burden on FOSS devs is at best exceedingly biased criticism. Those are in fact your friends, not Google.
Its the nature of the beast. For a while I used a custom ublock filter to strip out the recommended videos section, the comments, whatever I considered junk pixels. Now I just pull the video to /tmp/ and don't have to deal with buffering (somehow still an issue in 2024).
> 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.
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.
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.
As an additional tip, if you want to get rid of the "You are now fullscreen" (or whatever it says) that comes across the top... you can set the following to 0
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.
It’s not weird UX when you consider why it’s so hidden: to increase “engagement” metrics (i.e. make it more likely for you to click on other videos, view/interact with ads/etc). Same reason the feature is unavailable on iOS (even though it’s been natively supported by the OS for years), unless you pay whatever google wants for a premium YouTube subscription.
That behaviour is so weird that it feels like an oversight. It's like we're not supposed to be able to access those options at all. A lot of people are explaining it by saying PIP mode lowers engagement so they hide it. But then why have that as a built in feature at all?
Why not load the minimal required content for it to look right first (e. g. thumbnail, video controls) and load everything else once the rest of the page has been loaded (e. g. buffer the first few seconds of the video), somewhat similar to hydration?
I suspect that’s what they do already. The trouble is that it’s heavyweight speculative execution that often doesn’t pay off, but it wastes resources anyway.
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.
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.
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.
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.
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.
The issue is them getting it right is finding a balance point which is maximizing their profits at the expense of the general public. They are willing to make a Web Browser and Android to limit how much people can avoid being tracked etc.
We get a free search engine, map, office suite, email, the best browser, and video platform.
And while some here will say it’s enshittified beyond hope, it’s just not. Their products are great, I use them every day, and every now and then I click on an ad for something I like.
"According to the 160-page report, the employees found evidence that Mountain View was demoting its competitors and placing its own services on top of search results lists, even if they weren't as helpful." https://www.engadget.com/2015-03-20-ftc-report-google-search...
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.
> 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.
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?
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.
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?
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.
Caching on the web has gotten worse/more difficult recently since browsers (including Chrome and Edge) have started to partition the cache by top level site. This was necessary to keep trackers from using the cache status of a resource for tracking users, but had the side effect of making common resources much less likely to be cached.
Which is to say that if it's the first time you load a resource on a page, it most likely is not in cache. Sorry for inconvenience.
>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.
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.
Heh. I'm doing work for a "MegaCorp" right now trying to shave a few milliseconds off of ad render times. We have metrics that show milliseconds do matter. Especially since a few milliseconds on desktop can translate to hundreds of milliseconds on mobile.
I'm sure they do care, but they seems to care more about everything else. Or just are victims of decades of bloat. Or too many teams, where one team obliterated the tuning a hundred other teams did.
Because the end result is typically something that takes orders of magnitude more than you'd imagine physically possible on todays hardware.
1.3 MB on every embed? Is that the best the brightest engineers can come up with?
Or maybe the goal is to slow down the entire internet so that their own sites don't seem so slow in comparison?
I know it's easy for me to talk shit, but have you actually used the web lately? It is a miserable experience.
I'm probably misremembering the details because I can't find it but didn't Netflix have an absolutely enormous favicon or something that went unnoticed for a really long time. Feels like there are a few of those in any big codebase. Question is whether the codebase really needs to be big.
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.
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!
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.
The native <video> and <audio> tags buffer a few megabytes at a time. This is easy to see by opening a video file in the browser (not from file://) and watching the network tab.
Depends on how you set it up apparently, I assume it changed over time:
preload= "metadata" - is the default which is 2-3% of the video.
preload="none" - no video will be downloaded on page load
preload="auto" - the entire video is downloaded. (Some browsers do not do this, and only download partial videos anyway)
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.
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.
It's MPEG-DASH, and I think Apple has HLS. It's basically better by every possible metric _except_ the one you mentioned, which I'm sure you'd agree is an uncommon use-case. It's not designed to stop downloaders, it's trivial to download.
If you really want to play things multiple times, you can probably muck with your browser's cache settings, just tell it to cache a ton. I used to do that in Firefox when my mobile connection sucked, so I could buffer it all up and then just watch. Or easier yet, just use a download tool.
> 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.
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
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).
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.
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.).
> 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.
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).
> 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.
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.
> 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.
>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.
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?
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.
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.
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.
“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:
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.
Huh, even YouTube's official embed UI didn't make the "Watch on YouTube" button obvious enough for me to click on it, so I always hit play, paused the video, and clicked the "YouTube" button in the bottom right instead. Now that I'm aware of it, I wish it was in these lite players, though at least this one doesn't completely bar you from an easy way to get the link.
Likewise, the Save to Watch Later button is also missing from lite-youtube-embed, which is a feature I use a lot.
Yes, you can get to it by playing the video, but that defeats the point. I don't want to play the video, I don't want to wait for the video to load only to pause it and click the Save to Watch Later button.
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.
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...
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.
PSA: Try not to chuck 'unsafe-inline' into your Content-Security-Policy thoughtlessly--it disables the anti-injection protections of CSP. There are safe ways to permit inline scripts, if you even need them.
This seems to be allowing unsafe script injection from ONLY certain whitelisted urls, presumably excluding the url globs required for the ads. Haven't tested it, and not sure the full extent of pshc's sibling response either.
> 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.
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).
> 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.
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)
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.
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.
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.
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
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.
here it is. i am however showing the preview image and replacing it with the iframe on click. basically click2load. by using mutationobserver it seems i don't need ublock to block the iframe, because as soon as the browser tries to include it on the page it gets replaced anyway
For sonyalpharumors.com, the image preview extends into the side panel for post embeds, do you have a fix?
Edit: On line 21 & 22, I changed the container width to grab `frame.parentNode.width` instead and did the same for height. Seems to work better for that site at least.
> 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?
> 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.
Back in the day I had a Firefox extension that would replace all YouTube embeds with a thumbnail that when clicked would just open YouTube.
I originally wrote it because my phone didn't have flash and flash embeds were common. But it was nice to extend it to cover iframe embeds as well which were much faster and opening the embed in a full YouTube website or app was better UX than a tiny embed window in most cases.
I never migrated it to a WebExtension after being annoyed that I wrote it to the new high-level extension API at the time that was supposed to be supported across browser versions. But this post makes me want to port it.
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).
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.
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.
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).
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.
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.
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)?
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.
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".
The story of bananas is a lot shorter and more mysterious. Here the OED can reliably get us back only to 1968, when a University of South Dakota publication called Current Slang reported that Kentucky college students (of “both sexes”) were using bananas to mean “excited and upset; ‘wild.’”
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.
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.
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.
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.
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.
Seekability, bitrate adaptability, and subtitles are all built in to properly crafted video files. Codec support is handled with multiple source elements inside the video element.
> The YouTube player is, at its core, a video tag.
Nobody is disputing that.
I'm disputing that "they could just use a video tag" to get the same functionality and I'm sure that anyone body working on a video player at any streaming service could instantly give you a list why it's not something that's only there for evil tracking or business reasons.
It could be if browser vendors actually implemented that functionality for the video element. Shame that a certain large browser vendor has a slight conflict of interest problem with that.
And just plain <video> elements are seekable just fine as long as the server supports good old HTTP range requests. Dynamic bitrate is an issue but as a desktop user I'd just set it to max anyway. Clickable arease are pure cancer - just put links below the video.
> Dynamic bitrate is an issue but as a desktop user I'd just set it to max anyway. Clickable arease are pure cancer - just put links below the video.
You know that Desktop users account for < 10% of YouTube? Users on smartphones account for 70%-90% of usage based on some easy to find device statistics. Many of these are probably using cellular networks, so dynamic bitrate isn't just a "nice to have" feature.
Most of the time interpolating data from the developer / HN bubble to rest of the internet is not a good idea.
> 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.
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.
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.
Privacy Badger can replace YouTube embeds with "click to activate" placeholders. Faster browsing, better privacy, easy-to-use controls (when the replacement works properly ...).
I spent a year creating a web template system that scores 100/100/100/100 on Google's Lighthouse test, with all kinds of dynamic content. Video backgrounds and embeds were a huge problem for us, but it can be solved.
It's really pretty simple. Any video embed must be "below the fold", and the iframe must be lazy-loaded. Now our pages don't see any page speed hit from video embeds, they only get loaded when the page is scrolled and the video is in view. Any other solution that isn't lazy-loaded will still impact page speed, and if that's important to the client, then don't load anything that isn't absolutely necessary to display what appears "above the fold".
For video backgrounds, our pages make a call to one of our APIs that gets the media URL from Youtube or Vimeo, and we then play that in a standard HTML 5 video player. It works great, and our Google Lighthouse score is above 95 even on pages with above-the-fold HD video that auto-plays. Loading a JS library from anywhere just to play a video is going to hurt page speed a bit no matter what.
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.
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.
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.
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.
I continue to be baffled how many websites rely on YouTube embeds to show videos, especially marketing/brand websites where you don't usually want other unrelated logos on the page. It's really not that hard to self-host and embed videos, there has been native support since HTML5.
Until you miss audio, the playback isn't hardware accelerated and the phone gets hot, the video is broken, there's no thumbnail, you don't have access to a web dev and and and..
YouTube is so bland a brand I don't think it hurts anyone but the biggest companies.
Lite YouTube Embed requires me to "start" the video twice - once click on embed, then another start on youtube loaded. However I'd like to see it fixed (if possible) because I find the lack of website load time optimization disturbing
What I wonder is why some youtube embeds don't allow full screen (while being very small in the website so hard to watch), if you press full screen it then says something like "this website doesn't allow you to watch this video full screen". But on youtube this same video works fullscreen.
Are those websites themselves choosing that in a setting of their embed?
But why? It actually makes me navigate away from your website as I go to youtube instead to find the video there to view it properly there.
> fs
> Setting this parameter to 0 prevents the fullscreen button from displaying in the player. The default value is 1, which causes the fullscreen button to display.
Not sure if that's the one actually... it only says "disables the fullscreen button", it doesn't even specify whether it will actually prevent fullscreen through e.g. the 'f' shortcut
Also, the kind of site I'm talking about has a fullscreen button visible, only when you press it it says it's disallowed
But I see no other fullscreen related settings (other than the keyboard shortcut related one partially) so it could be this one of course but its description didn't catch up with reality
> The Solution is to Replicate the Embed Experience Another Way.
No, the solution is to host your own videos and use a plain <video> element. Or it would be if Browser vendors would add native DASH/HLS-like adaptive streaming support to it, but even without that the user experience is much better with a <video>.
>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.
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.
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.
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
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
How about needing to store your video in a variety of resolutions for users on different levels of connections (or have the CPU capacity available to transcode live for every single simultaneous viewer)? Also, streaming video requires higher bandwidth than text/images; where you may be able to get away with a single server for text/images, you might find a CDN (with the cost & complexity it brings) is more necessary for video delivery.
The client-side player isn't an out-of-the-box thing, either-- solutions like Video.js and MediaElement.js need a myriad of plugins to approach the YouTube player's functionality, and default browser players get nowhere close. But it's the smaller part of the story, imo, because at least it's just JavaScript & CSS to deliver.
i shared my solution here for anyone who wants an alternative to lite youtube embed (worked on it before knowing about paul's solution, has perhaps better tradeoffs with regards complete customizability)
I made a component for Astro sites which uses the <iframe srcdoc> solution. As a bonus you get a typed interface to the embed parameters when you need to use them:
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.
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?
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)
> 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.
Do you mean ambient mode, that adds the faded light around the video (which looks awful, but is supposed to mimic behind-screen synced backlighting)? Theater mode mainly just makes the video bigger and moves other stuff lower down on the page, so I can't imagine how it "eats CPU" any more than simply making the window bigger would.
I have an electric car and was not trying to be hyperbolic. The article is about wasting resources (and electricity is one of them) because the embedded videos are not tuned to be efficient.
Certainly, one person would never be able to download enough videos to waste a car's worth of electricity; but across several million people doing it, it would add up.
You're technically correct, it would add up to be equivalent with enough scale. However, given the stats I've seen from solar panel owners about how much electricity their computers/phones actually use compared to charging up their car (with the former basically being a surprisingly tiny drop in the bucket compared to the latter), the number you're looking for to make a comparison might still be at least an order of magnitude higher than you expect.
My point really was about scale. Put some wasteful code in some rarely used application and it means nothing (the proverbial drop in the bucket). Put the same thing in a very popular app or library which is used by millions (or even billions); then it is a whole different story. It seems YouTube fits this bill. But because the collective cost is spread across all the users; no one is pressed to fix it.
Another recent claim [..] estimated that 7bn YouTube views of “Despacito” [..] had consumed 900 gigawatt hours (GWh) of electricity, or 1.66 kWh per viewing hour.
At this rate, YouTube – with over 1 billion viewing hours a day – would consume over 600 TWh a year (2.5% of global electricity use), which would be more than the electricity used globally by all data centres (~200 TWh) and data transmission networks (~250 TWh).
It is clear that these figures are too high – but by how much?
It should be perfectly clear that the client-side impact of this transfer is not important, since a mobile device still loads YouTube embeds instantly, but does not burst into flames while doing so, as it necessarily would if the energy cost was as high as the other person is suggesting.
Sure, TBH I was inspired by your comment that "there is a person whose full-time job is to consider the energy usage of YouTube in all its aspects" and figured I'd throw in an IEA commentary from someone who watches the watchers.
It's a big picture look at youtube energy use, but hopefully of tangential interest.
This is not one of those things where a long tail dominates. You could transfer a megabyte of data over Wi-Fi to a portable device 20 million times with the same energy that you need to charge a standard range Tesla once. Furthermore, I can assure you that there is a person whose full-time job is to consider the energy usage of YouTube in all its aspects.
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.
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.
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!
It sounds like the users visiting this site are there to watch YouTube videos
Users are also capable of blocking traffic from their client if that's something they care about.
This is not something they should have to care about. And once you leave the tech savvy community then can not take care of it via content-blockers... You should do the correct thing by default, which is not supporting adtechs' psychological warfare agains the population imho.
[flagged]
[flagged]
God this comment is obnoxious.
If a visitor has different opinions then they can implement their opinions. Webmaster didn't stop that.
Nearly every user won't care.
Is there a similar solution for SoundCloud?
Their player is also super bloated.
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.
There are a few "facade" solutions listed at https://developer.chrome.com/docs/lighthouse/performance/thi... But.. AFAIK nobody has made one for Soundcloud.
Any tips or examples you are able to point for on this solution? I am coincidentally working on this exact problem at the moment.
Yes! @OP, would love to hear more on how you’ve done this.
Do you also cache or proxy the thumbnail? Google can also track them when hotlinking it.
GP says "proxied thumbnails", so it sounds like yes.
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/
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.
> 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.
Use an external video player. mpv and VLC are my usual go-to's. Both will stream straight from a URL (and both handle far more than just YT).
You can also of course download and play at your leisure with ytdlp.
<https://mpv.io/>
<https://www.videolan.org/vlc/>
<https://github.com/yt-dlp/yt-dlp>
I just tried VLC.
Media - From Network Stream - pasted Youtube URL.
Nope, error message, said check the logs.
Searched the UI for an entry for the logs, found nothing.
Googled for "vlc logs". Found a guide. Configured the path to be on the desktop.
Restarted VLC.
Tried again, same error message.
No log file created and of course no log file entries.
The joys of FOSS.
I tried the same route, but got the logs correctly. It gave me a HTTP 410 error. I wouldn't be surprised at all if VLC's youtube plugin is just too old and there's a better one somewhere else. But in the meanwhile, mpv's plugin works (if you're using yt-dlp and not youtube-dl, that is)
Logs not being directly visible in the VLC UI and not having a default log file location plus the fact that even going to advanced settings and configuring things doesn't make logs show up after the first try is not Google's fault, though.
It's hardly a fault though. And if you need this feature go ahead and implement it.
The first part is a feature, the second one is a bug.
And no, I don't think I will, I'll just use Youtube with ad blockers for as long as I can.
Despite having defended FOSS and advocated VLC ... I understand your viewpoint here. Calling on people to contribute bugfixes isn't especially realistic. Filing a bug on the fact that VLC has poor debug/log tools would be helpful though.
Particularly as a useful logging / debugging capability should enable more useful bug reports specific to function.
Sorry it's not working out for you, thanks for trying regardless.
I'm just jaded at this point. FOSS won the battle and lost the war. It's been subsumed into the bowels of these corporations that are ending up mega predatory.
TBH I almost always use mpv or ytdl these days.
I've used VLC successfully in the past on Android using the "stream" option. When I want to view video (as opposed to just listen to audio, my usual Android mpv use-case) that's delivered joy. On MacOS, I'll use mpv to play either audio only or video, with joy in both cases.
Don't forget that the other side of the equation is YouTube ACTIVELY WORKING TO BREAK COMPATIBILITY, and with considerable success. E.g., Invidious and Piped had been b0rk3n for a few months, though on checking again in the past few days, Invidious at least seems to be working again. So placing the whole burden on FOSS devs is at best exceedingly biased criticism. Those are in fact your friends, not Google.
Its the nature of the beast. For a while I used a custom ublock filter to strip out the recommended videos section, the comments, whatever I considered junk pixels. Now I just pull the video to /tmp/ and don't have to deal with buffering (somehow still an issue in 2024).
If I’m watching a video longer than 10 minutes or so I usually use a Firefox popout window.
> 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.
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.
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.
That's a truly excellent tip, I definitely need to go tweak that setting.
As an additional tip, if you want to get rid of the "You are now fullscreen" (or whatever it says) that comes across the top... you can set the following to 0
these are all involved in the popup when you fullscreen a videoWhat a wonderful but bizarrely named feature flag. Thank you!
I love Firefox's picture-in-picture mode for this exact reason. I think there is an extension for Chrome also.
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.
It’s not weird UX when you consider why it’s so hidden: to increase “engagement” metrics (i.e. make it more likely for you to click on other videos, view/interact with ads/etc). Same reason the feature is unavailable on iOS (even though it’s been natively supported by the OS for years), unless you pay whatever google wants for a premium YouTube subscription.
There’s a great app called PiPifier, which allows you to use PiP for free on iOS.
That behaviour is so weird that it feels like an oversight. It's like we're not supposed to be able to access those options at all. A lot of people are explaining it by saying PIP mode lowers engagement so they hide it. But then why have that as a built in feature at all?
Windowed - floating Youtube/every website' avail for firefox or chrome. https://addons.mozilla.org/en-US/firefox/addon/windowed/ https://chromewebstore.google.com/detail/windowed-floating-y...
For me, this extension works quite well https://addons.mozilla.org/en-US/firefox/addon/bettertheatre...
Maybe try the T key for theater mode!
this is my greatest nitpick.
Any website with a video player should include a "full window" control
Why not load the minimal required content for it to look right first (e. g. thumbnail, video controls) and load everything else once the rest of the page has been loaded (e. g. buffer the first few seconds of the video), somewhat similar to hydration?
I suspect that’s what they do already. The trouble is that it’s heavyweight speculative execution that often doesn’t pay off, but it wastes resources anyway.
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.
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.
Global watch time isn’t something non Google website owners care about. Remember, Google benefits from making the web worse.
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.
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.
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.
The issue is them getting it right is finding a balance point which is maximizing their profits at the expense of the general public. They are willing to make a Web Browser and Android to limit how much people can avoid being tracked etc.
How is it at the expense of the public?
We get a free search engine, map, office suite, email, the best browser, and video platform.
And while some here will say it’s enshittified beyond hope, it’s just not. Their products are great, I use them every day, and every now and then I click on an ad for something I like.
> How is it at the expense of the public?
"According to the 160-page report, the employees found evidence that Mountain View was demoting its competitors and placing its own services on top of search results lists, even if they weren't as helpful." https://www.engadget.com/2015-03-20-ftc-report-google-search...
Then there's search results which are mostly ads and sponsored listings, not actual search results, and that's deliberate: https://www.wheresyoured.at/the-men-who-killed-google/
And search results from content farms are prioritized at the expense of actual results: https://www.niemanlab.org/2024/02/google-promotes-sketchy-pr...
Ands a decade of AMP hurt the web, and publishers, and sites, and... https://wptavern.com/amp-has-irreparably-damaged-publishers-...
If you clicked on an ad ever you're a different sort.
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.
> 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.
> They have Android, they don't need the web to exist.
If not for apple, I'd agree.
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.
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.
How will Google collect data about every page load then?
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?
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.
Caching on the web has gotten worse/more difficult recently since browsers (including Chrome and Edge) have started to partition the cache by top level site. This was necessary to keep trackers from using the cache status of a resource for tracking users, but had the side effect of making common resources much less likely to be cached.
Which is to say that if it's the first time you load a resource on a page, it most likely is not in cache. Sorry for inconvenience.
>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.
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.
> 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/
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/10275139...
[basedon] https://daverupert.com/2015/06/doherty-threshold/
Heh. I'm doing work for a "MegaCorp" right now trying to shave a few milliseconds off of ad render times. We have metrics that show milliseconds do matter. Especially since a few milliseconds on desktop can translate to hundreds of milliseconds on mobile.
I'm sure they do care, but they seems to care more about everything else. Or just are victims of decades of bloat. Or too many teams, where one team obliterated the tuning a hundred other teams did.
Because the end result is typically something that takes orders of magnitude more than you'd imagine physically possible on todays hardware.
1.3 MB on every embed? Is that the best the brightest engineers can come up with?
Or maybe the goal is to slow down the entire internet so that their own sites don't seem so slow in comparison?
I know it's easy for me to talk shit, but have you actually used the web lately? It is a miserable experience.
I'm probably misremembering the details because I can't find it but didn't Netflix have an absolutely enormous favicon or something that went unnoticed for a really long time. Feels like there are a few of those in any big codebase. Question is whether the codebase really needs to be big.
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.
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!
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.
The native <video> and <audio> tags buffer a few megabytes at a time. This is easy to see by opening a video file in the browser (not from file://) and watching the network tab.
Depends on how you set it up apparently, I assume it changed over time:
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.
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.
It also decreases bandwidth and processing server-side, when a user leaves before finishing the video.
It's MPEG-DASH, and I think Apple has HLS. It's basically better by every possible metric _except_ the one you mentioned, which I'm sure you'd agree is an uncommon use-case. It's not designed to stop downloaders, it's trivial to download.
If you really want to play things multiple times, you can probably muck with your browser's cache settings, just tell it to cache a ton. I used to do that in Firefox when my mobile connection sucked, so I could buffer it all up and then just watch. Or easier yet, just use a download tool.
Why not just go with the flow and use/develop a downloader browser extension?
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.
> 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.
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
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).
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
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.
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.
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.).
In this scenario, what is the "commons"?
everyone else’s engagement except Google’s will be degraded by the increased page load times
> 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.
Drummers can discern down to 6ms, this producer states they can barely discern 3ms.
https://music.stackexchange.com/questions/133356/what-is-the...
So from those metrics, it's pretty easy to tell those two divisions apart.
It also seems like it takes two clicks to start a video? Is that a bug?
Why is it slower?
It feels same to me (Pixel phone)
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).
> Every additional millisecond of load time will reduce engagement
Is there any data on this?
> 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.
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.
> 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.
>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.
Latency is magnitudes more critical when it's something where you have to react.
The difference between 5 ms and 250 ms is a lot more than 5 ms, so there's no contradiction.
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?
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.
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.
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.
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.
Minor detail: the Beatmania game series has had "perfect" timing judgements for a long time, that's not exactly new.
“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/S004269890...
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/
Huh, even YouTube's official embed UI didn't make the "Watch on YouTube" button obvious enough for me to click on it, so I always hit play, paused the video, and clicked the "YouTube" button in the bottom right instead. Now that I'm aware of it, I wish it was in these lite players, though at least this one doesn't completely bar you from an easy way to get the link.
Likewise, the Save to Watch Later button is also missing from lite-youtube-embed, which is a feature I use a lot.
Yes, you can get to it by playing the video, but that defeats the point. I don't want to play the video, I don't want to wait for the video to load only to pause it and click the Save to Watch Later button.
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
> force bloggers to stop using GitHub Gist embeds
Or maybe just let people do what they want on their own site, even though you or I might not like it?
"Forcing" people to change their sites to suit your preferences is ridiculous.
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...
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:
More info: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...PSA: Try not to chuck 'unsafe-inline' into your Content-Security-Policy thoughtlessly--it disables the anti-injection protections of CSP. There are safe ways to permit inline scripts, if you even need them.
https://content-security-policy.com/
That's clever, well worth its own blog post.
can you tldr it? just one little meta tag defeats google's ad services? why dont we all slap it on our html templates?
This seems to be allowing unsafe script injection from ONLY certain whitelisted urls, presumably excluding the url globs required for the ads. Haven't tested it, and not sure the full extent of pshc's sibling response either.
> 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.
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).
It was actually YouTube: https://blog.chriszacharias.com/page-weight-matters
lol amazing, thank you for finding that.
> 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.
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)
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.
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.
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:
To block all iframes (except sites you whitelist, see links above):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
Yeah I should put this somewhere! In the meantime, right after img.alt =... you can add
That last line is a hack (eg resizing), but it's required to make the test website work since annoyingly their CSS uses :is(frame).I suggest using MutationObserver instead of just running the replaceEmbeds function every 3s.
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.
here it is. i am however showing the preview image and replacing it with the iframe on click. basically click2load. by using mutationobserver it seems i don't need ublock to block the iframe, because as soon as the browser tries to include it on the page it gets replaced anyway
(function() { 'use strict';
})();For sonyalpharumors.com, the image preview extends into the side panel for post embeds, do you have a fix?
Edit: On line 21 & 22, I changed the container width to grab `frame.parentNode.width` instead and did the same for height. Seems to work better for that site at least.
> 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?
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.
Back in the day I had a Firefox extension that would replace all YouTube embeds with a thumbnail that when clicked would just open YouTube.
I originally wrote it because my phone didn't have flash and flash embeds were common. But it was nice to extend it to cover iframe embeds as well which were much faster and opening the embed in a full YouTube website or app was better UX than a tiny embed window in most cases.
I never migrated it to a WebExtension after being annoyed that I wrote it to the new high-level extension API at the time that was supposed to be supported across browser versions. But this post makes me want to port it.
Please do it!
I'm unlikely to. But the Apache 2.0 source is here. Seems like it should still fairly easy to convert as all of the work happens in a content script.
https://github.com/kevincox/youtube-e2l/
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).
I feel like some content creators might not be very happy about that
doing this on a broad scale is a great way to get sued
So how about disallowing YouTube embeds and requiring users to upload videos?
In hostile jurisdictions, maybe. But there are servers all around the world. Take your pick.
username does not check out
[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.
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.
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).
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.
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.
> 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.
> 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.
The front page of Hacker News remains one of the only effective places to file bug reports against Google products.
> 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)?
No one gets a promo for maintenance work. Especially at places like google.
"I saved XXTb of bandwidth with this one simple change!"
Could be resume fodder.
Google PageSpeed will gladly shame you for using the slow YouTube embed.
>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.
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.
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.
Straight Dope also has a good 'splainer:
The story of bananas is a lot shorter and more mysterious. Here the OED can reliably get us back only to 1968, when a University of South Dakota publication called Current Slang reported that Kentucky college students (of “both sexes”) were using bananas to mean “excited and upset; ‘wild.’”
<https://www.straightdope.com/21344487/how-did-em-nuts-em-and...>
Bananas are crazy.
https://www.youtube.com/watch?v=BZ6Ev46i2to
Why not look it up? It means crazy.
I googled "bananas heavy" but I didn't get much
Perfect use case for chatgpt or other llm
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.
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.
dictionaries do not provide much context that would un-confuse someone who has not come into contact with a colloquialism.
The context is bananas means crazy. Dictionaries provide this context.
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.
bananas == crazy; (x heavy) == crazy heavy
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
LLMs don't actually "understand" anything. They're just better at parsing and manipulating language.
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.
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.
Seekability, bitrate adaptability, and subtitles are all built in to properly crafted video files. Codec support is handled with multiple source elements inside the video element.
The YouTube player is, at its core, a video tag.
> The YouTube player is, at its core, a video tag.
Nobody is disputing that.
I'm disputing that "they could just use a video tag" to get the same functionality and I'm sure that anyone body working on a video player at any streaming service could instantly give you a list why it's not something that's only there for evil tracking or business reasons.
It could be if browser vendors actually implemented that functionality for the video element. Shame that a certain large browser vendor has a slight conflict of interest problem with that.
And just plain <video> elements are seekable just fine as long as the server supports good old HTTP range requests. Dynamic bitrate is an issue but as a desktop user I'd just set it to max anyway. Clickable arease are pure cancer - just put links below the video.
> Dynamic bitrate is an issue but as a desktop user I'd just set it to max anyway. Clickable arease are pure cancer - just put links below the video.
You know that Desktop users account for < 10% of YouTube? Users on smartphones account for 70%-90% of usage based on some easy to find device statistics. Many of these are probably using cellular networks, so dynamic bitrate isn't just a "nice to have" feature.
Most of the time interpolating data from the developer / HN bubble to rest of the internet is not a good idea.
> 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.
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.
It looks like this solution is essentially this, but a little nicer looking (on hover animation, for example).
And this has the extra benefit that you don't give your website data to Google for free
yeah this is the reason I don't understand the "lite-youtube-embed" project.
A simple one-liner would be much better.
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.
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...
(I develop Privacy Badger.)
Privacy Badger can replace YouTube embeds with "click to activate" placeholders. Faster browsing, better privacy, easy-to-use controls (when the replacement works properly ...).
See "Pro tip #1" in https://www.eff.org/deeplinks/2024/01/privacy-badger-puts-yo...
I spent a year creating a web template system that scores 100/100/100/100 on Google's Lighthouse test, with all kinds of dynamic content. Video backgrounds and embeds were a huge problem for us, but it can be solved.
It's really pretty simple. Any video embed must be "below the fold", and the iframe must be lazy-loaded. Now our pages don't see any page speed hit from video embeds, they only get loaded when the page is scrolled and the video is in view. Any other solution that isn't lazy-loaded will still impact page speed, and if that's important to the client, then don't load anything that isn't absolutely necessary to display what appears "above the fold".
For video backgrounds, our pages make a call to one of our APIs that gets the media URL from Youtube or Vimeo, and we then play that in a standard HTML 5 video player. It works great, and our Google Lighthouse score is above 95 even on pages with above-the-fold HD video that auto-plays. Loading a JS library from anywhere just to play a video is going to hurt page speed a bit no matter what.
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.
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.
>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.
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.
Sounds absolutely goated.
yt-dl, chron, and onedrive or icloud together achieve this
I continue to be baffled how many websites rely on YouTube embeds to show videos, especially marketing/brand websites where you don't usually want other unrelated logos on the page. It's really not that hard to self-host and embed videos, there has been native support since HTML5.
Until you miss audio, the playback isn't hardware accelerated and the phone gets hot, the video is broken, there's no thumbnail, you don't have access to a web dev and and and..
YouTube is so bland a brand I don't think it hurts anyone but the biggest companies.
Lite YouTube Embed requires me to "start" the video twice - once click on embed, then another start on youtube loaded. However I'd like to see it fixed (if possible) because I find the lack of website load time optimization disturbing
OP: the YT loading paradox you are thinking of is https://blog.chriszacharias.com/page-weight-matters
An absolute classic.
Discussed a couple of years ago on HN: <https://news.ycombinator.com/item?id=32279897>
What I wonder is why some youtube embeds don't allow full screen (while being very small in the website so hard to watch), if you press full screen it then says something like "this website doesn't allow you to watch this video full screen". But on youtube this same video works fullscreen.
Are those websites themselves choosing that in a setting of their embed?
But why? It actually makes me navigate away from your website as I go to youtube instead to find the video there to view it properly there.
https://developers.google.com/youtube/player_parameters#Para...
> fs > Setting this parameter to 0 prevents the fullscreen button from displaying in the player. The default value is 1, which causes the fullscreen button to display.
So yes, these website chose to do this.
Not sure if that's the one actually... it only says "disables the fullscreen button", it doesn't even specify whether it will actually prevent fullscreen through e.g. the 'f' shortcut
Also, the kind of site I'm talking about has a fullscreen button visible, only when you press it it says it's disallowed
But I see no other fullscreen related settings (other than the keyboard shortcut related one partially) so it could be this one of course but its description didn't catch up with reality
> But why?
To show their own ads next to the video?
> The Solution is to Replicate the Embed Experience Another Way.
No, the solution is to host your own videos and use a plain <video> element. Or it would be if Browser vendors would add native DASH/HLS-like adaptive streaming support to it, but even without that the user experience is much better with a <video>.
> Or link it from a CDN
Pure insanity.
>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.
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.
> 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.
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.
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/...
> I would even go further and wonder why lite-youtube still requires 100K?
Just turn off your computer and you’ll be using 0K.
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
Why would you not use YoutubeLite for this? Just thumbnail loading then embed / play on click. You are reinventing the wheel for no reason.
What is the problem of sites hosting their own videos?
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
How about needing to store your video in a variety of resolutions for users on different levels of connections (or have the CPU capacity available to transcode live for every single simultaneous viewer)? Also, streaming video requires higher bandwidth than text/images; where you may be able to get away with a single server for text/images, you might find a CDN (with the cost & complexity it brings) is more necessary for video delivery.
The client-side player isn't an out-of-the-box thing, either-- solutions like Video.js and MediaElement.js need a myriad of plugins to approach the YouTube player's functionality, and default browser players get nowhere close. But it's the smaller part of the story, imo, because at least it's just JavaScript & CSS to deliver.
i shared my solution here for anyone who wants an alternative to lite youtube embed (worked on it before knowing about paul's solution, has perhaps better tradeoffs with regards complete customizability)
https://swyxkit.netlify.app/faster-youtube-embeds
I made a component for Astro sites which uses the <iframe srcdoc> solution. As a bonus you get a typed interface to the embed parameters when you need to use them:
https://github.com/insin/astro-lazy-youtube-embed#readme
Example of a page with a dozen embedded videos:
https://jbscript.dev/notes/undefined/the-banterbox
IMO YouTube embeds are a bad experience anyway, especially on mobile. Just put a poster image with a link to the actual YouTube video.
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
On mobile you can tap "Watch on YouTube" and it will deep link and open the video inside your YouTube mobile app.
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.
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.
A tiny script Click to toggle the display css attribute prevents it loading as the page loads
Shouldn't class lty-playbtn be lyt-playbtn?
lol, yes. good eye. ;) https://github.com/paulirish/lite-youtube-embed/issues/65
[dead]
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?
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)
> 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.
Do you mean ambient mode, that adds the faded light around the video (which looks awful, but is supposed to mimic behind-screen synced backlighting)? Theater mode mainly just makes the video bigger and moves other stuff lower down on the page, so I can't imagine how it "eats CPU" any more than simply making the window bigger would.
This must be intentionally hyperbolic or you have no concept of how much energy is needed to run a car.
I have an electric car and was not trying to be hyperbolic. The article is about wasting resources (and electricity is one of them) because the embedded videos are not tuned to be efficient.
Certainly, one person would never be able to download enough videos to waste a car's worth of electricity; but across several million people doing it, it would add up.
You're technically correct, it would add up to be equivalent with enough scale. However, given the stats I've seen from solar panel owners about how much electricity their computers/phones actually use compared to charging up their car (with the former basically being a surprisingly tiny drop in the bucket compared to the latter), the number you're looking for to make a comparison might still be at least an order of magnitude higher than you expect.
My point really was about scale. Put some wasteful code in some rarely used application and it means nothing (the proverbial drop in the bucket). Put the same thing in a very popular app or library which is used by millions (or even billions); then it is a whole different story. It seems YouTube fits this bill. But because the collective cost is spread across all the users; no one is pressed to fix it.
The carbon footprint of streaming video: fact-checking the headlines
https://www.iea.org/commentaries/the-carbon-footprint-of-str...
It should be perfectly clear that the client-side impact of this transfer is not important, since a mobile device still loads YouTube embeds instantly, but does not burst into flames while doing so, as it necessarily would if the energy cost was as high as the other person is suggesting.
Sure, TBH I was inspired by your comment that "there is a person whose full-time job is to consider the energy usage of YouTube in all its aspects" and figured I'd throw in an IEA commentary from someone who watches the watchers.
It's a big picture look at youtube energy use, but hopefully of tangential interest.
This is not one of those things where a long tail dominates. You could transfer a megabyte of data over Wi-Fi to a portable device 20 million times with the same energy that you need to charge a standard range Tesla once. Furthermore, I can assure you that there is a person whose full-time job is to consider the energy usage of YouTube in all its aspects.