YouTube embeds are heavy and it’s fixable
frontendmasters.com
frontendmasters.com
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.
Their player is also super bloated.
If a visitor has different opinions then they can implement their opinions. Webmaster didn't stop that.
Nearly every user won't care.
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.
It feels same to me (Pixel phone)
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.
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.
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.
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.
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.
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...
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.
If not for apple, I'd agree.
Why would you ever want to advertise to anyone else?
No internet = no Google.
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.
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...
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-...
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?
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.
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.
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
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.
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.
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.
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.
full-screen-api.transition-duration.enter
full-screen-api.transition-duration.leave
full-screen-api.transition-duration.timeout
full-screen-api.warning.delay
full-screen-api.warning.timeout
Any website with a video player should include a "full window" control
Theater mode (shortcut 't') is a bit better. But yes, I too would like a mode where the video fills the whole browser window.
You can also of course download and play at your leisure with ytdlp.
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.
And no, I don't think I will, I'll just use Youtube with ad blockers for as long as I can.
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'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.
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.
> 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.
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."
What I assume is the actual IBM report[0] might interest you.
[0] https://www.computerhistory.org/collections/catalog/10275139...
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.
Google takes everything that works PERFECTLY FINE and turns it into a steaming pile of … I am gonna stop right there.
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.
There is probably a lot of code sharing among all platforms such that companies don't want to support two different buffering flows.
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.
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.
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.
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!
Edit: in fact every native web video player downloads as much as possible as far as I can tell.
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)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 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.
https://music.stackexchange.com/questions/133356/what-is-the...
So from those metrics, it's pretty easy to tell those two divisions apart.
Is there any data on this?
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.
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.
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.
Example META tag:
<meta http-equiv="Content-Security-Policy"
content="default-src 'self' 'unsafe-inline' *.your-cdn-if-any.com
www.youtube.com *.googlevideo.com *.ytimg.com">
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 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.
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).
!||youtube-nocookie.com^$3p,frame,redirect=click2load.html,domain=~bing.com|~google.com|~duckduckgo.com|~video.search.yahoo.com
||youtube-nocookie.com/embed^$3p,frame,redirect=click2load.html,domain=~bing.com|~google.com|~duckduckgo.com|~video.search.yahoo.com
||youtube.com^$3p,frame,redirect=click2load.html,domain=~bing.com|~chatreplay.stream|~google.com|~duckduckgo.com|~video.search.yahoo.comAll I want is a plain link, so a while back I got fed up and wrote a short userscript to just rewrite the page. Works surprisingly well for how simple it is.
// ==UserScript==
// @name Youtube UnEmbed
// @version 0.1
// @description Converts embedded Youtube iframes into links
// @match *://*/*
// @exclude *://*.youtube.com/*
// @exclude *://*.reddit.com/*
// @exclude *://looptube.io/*
// @grant none
// @run-at document-idle
// ==/UserScript==
(function() {
'use strict';
const SITE = "https://www.youtube.com"; //m.youtube Invidious etc
const LINK_TO_TIMESTAMP = true;
const SHOW_PREVIEW_IMAGE = false;
const replaceEmbeds = () => {
document.querySelectorAll('iframe').forEach((frame) => {
const frameURL = frame.src || frame.dataset?.src;
if (!frameURL) return;
const match = frameURL.match(/(^https?:)?\/\/(www\.)?youtube(-nocookie)?\.com\/embed\/([a-zA-Z0-9\-_]{11}).*?(\?.*((t|start)=([\dsmh]*)))?/i);
if (match?.length == 9) {
const newURL = SITE+"/watch?" + ((LINK_TO_TIMESTAMP && match[8]) ? "t="+match[8]+"&" : "") + "v="+match[4];
const elem = document.createElement("a")
elem.href = newURL;
if (SHOW_PREVIEW_IMAGE) {
let img = document.createElement("img");
img.src = "https://i.ytimg.com/vi/"+match[4]+"/mqdefault.jpg";
img.alt="Preview image of Youtube video";
// 320 x 180 preview. For more resolution options see
// https://medium.com/@viniciu_/how-to-get-the-default-thumbnail-url-for-a-youtube-video-b5497b3b6218
elem.appendChild(img);
} else {
elem.innerHTML = newURL;
}
frame.outerHTML = elem.outerHTML;
// common lazyload hiding methods
elem.style.display = "block !important";
elem.style.opacity = "100% !important";
elem.style.background = "transparent !important";
const parent = elem.parentElement;
if (parent) {
parent.style.display = "block !important";
parent.style.opacity = "100% !important";
parent.style.background = "transparent !important";
}
}
});
};
replaceEmbeds();
setInterval(replaceEmbeds, 3000);
})();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.
(function() { 'use strict';
const SITE = "https://www.youtube.com";
const LINK_TO_TIMESTAMP = true;
const SHOW_PREVIEW_IMAGE = true;
const createPreviewElement = (videoId, newURL, frame) => {
const container = document.createElement("div");
container.setAttribute('data-yt-preview', 'true');
container.style.position = "relative";
container.style.width = frame.width + "px";
container.style.height = frame.height + "px";
container.style.cursor = "pointer";
const img = document.createElement("img");
img.src = `https://i.ytimg.com/vi/${videoId}/mqdefault.jpg`;
img.alt = "Preview image of Youtube video";
img.style.width = "100%";
img.style.height = "100%";
img.style.objectFit = "cover";
const playButton = document.createElement("div");
playButton.innerHTML = "▶";
playButton.style.position = "absolute";
playButton.style.top = "50%";
playButton.style.left = "50%";
playButton.style.transform = "translate(-50%, -50%)";
playButton.style.fontSize = "48px";
playButton.style.color = "white";
playButton.style.backgroundColor = "rgba(0, 0, 0, 0.7)";
playButton.style.borderRadius = "50%";
playButton.style.width = "80px";
playButton.style.height = "80px";
playButton.style.display = "flex";
playButton.style.justifyContent = "center";
playButton.style.alignItems = "center";
container.appendChild(img);
container.appendChild(playButton);
container.addEventListener("click", () => {
const iframe = document.createElement("iframe");
iframe.src = frame.src + (frame.src.includes('?') ? '&' : '?') + 'autoplay=1';
iframe.width = frame.width;
iframe.height = frame.height;
iframe.frameBorder = "0";
iframe.allow = "accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture";
iframe.allowFullscreen = true;
iframe.setAttribute('data-yt-processed', 'true');
container.parentNode.replaceChild(iframe, container);
});
return container;
};
const replaceEmbed = (frame) => {
const frameURL = frame.src || frame.dataset?.src;
if (!frameURL) return;
const match = frameURL.match(/(^https?:)?\/\/(www\.)?youtube(-nocookie)?\.com\/embed\/([a-zA-Z0-9\-_]{11}).*?(\?.*((t|start)=([\dsmh]*)))?/i);
if (match?.length == 9) {
const videoId = match[4];
const newURL = SITE + "/watch?" + ((LINK_TO_TIMESTAMP && match[8]) ? "t=" + match[8] + "&" : "") + "v=" + videoId;
const previewElement = createPreviewElement(videoId, newURL, frame);
frame.parentNode.replaceChild(previewElement, frame);
// common lazyload hiding methods
previewElement.style.display = "block !important";
previewElement.style.opacity = "100% !important";
previewElement.style.background = "transparent !important";
const parent = previewElement.parentElement;
if (parent) {
parent.style.display = "block !important";
parent.style.opacity = "100% !important";
parent.style.background = "transparent !important";
}
}
};
const observeDOM = () => {
const observer = new MutationObserver((mutations) => {
mutations.forEach((mutation) => {
if (mutation.type === 'childList') {
mutation.addedNodes.forEach((node) => {
if (node.nodeType === Node.ELEMENT_NODE) {
if (node.tagName === 'IFRAME' && !node.hasAttribute('data-yt-processed')) {
replaceEmbed(node);
} else {
node.querySelectorAll('iframe:not([data-yt-processed])').forEach(replaceEmbed);
}
}
});
}
});
});
observer.observe(document.body, {
childList: true,
subtree: true
});
};
// Initial replacement
document.querySelectorAll('iframe:not([data-yt-processed])').forEach(replaceEmbed);
// Start observing DOM changes
observeDOM();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.
I should have mentioned this is paired with uBlock Origin to block Youtube iframes (and indeed all iframes) globally. At the time I was writing it to unbreak embedded videos.
https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-qu...
https://github.com/gorhill/uBlock/wiki/Blocking-mode
https://github.com/gorhill/uBlock/wiki/Blocking-mode:-medium...
From uBO My Rules tab:
* youtube-nocookie.com * block
* youtube.com * block
* ytimg.com * block
youtube.com youtube.com * noop
youtube.com ytimg.com * noop
* * 3p-frame blockI 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
// improve styling
img.className = frame.className;
img.id = frame.id;
img.style.width = frame.width +"px";
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.
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.
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'm seeing <1% CPU on Firefox/Debian, but I have video autoplay turned off (I rarely want to watch them).
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.
Good luck with that. Not to mention WSJ and The Guardian themselves are babanas heavy for no good reason - like every other media site.
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.
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)?
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.
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.
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.
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
https://english.stackexchange.com/questions/74581/why-does-b... Has a reasonable-reading accepted answer.
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...>
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.
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.
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.
This would hurt advertising impressions.
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.
<img src="thumbnail.png" onclick="[replace image with embed]">A simple one-liner would be much better.
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.
https://paulirish.github.io/lite-youtube-embed/variants/yt.h...
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...
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.
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.
[1] https://www.tubearchivist.com/
[2] https://github.com/tubearchivist/tubearchivist-jf-pluginYouTube is so bland a brand I don't think it hurts anyone but the biggest companies.
Discussed a couple of years ago on HN: <https://news.ycombinator.com/item?id=32279897>
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.
To show their own ads next to the video?
> 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.
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
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.
I would even go further and wonder why lite-youtube still requires 100K? 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.
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/...
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.
Just turn off your computer and you’ll be using 0K.
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
So I don't know the answer to our question either but according to them we're overlooking something
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.
https://github.com/insin/astro-lazy-youtube-embed#readme
Example of a page with a dozen embedded videos:
Using the preview sounded cool so I added it. Change SHOW_PREVIEW_IMAGE to true.
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)
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.
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.
https://www.iea.org/commentaries/the-carbon-footprint-of-str...
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's a big picture look at youtube energy use, but hopefully of tangential interest.