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, 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/

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.

Theater mode (shortcut 't') is a bit better. But yes, I too would like a mode where the video fills the whole browser window.

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.

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.

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

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.

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.

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.

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.

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."

https://lawsofux.com/doherty-threshold/

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.

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)

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.

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.

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.

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 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

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.

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.

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.

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.

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 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/

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.

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 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).

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.

  !||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.com

All I want is a plain link, so a while back I got fed up and wrote a short userscript to just rewrite the page. Works surprisingly well for how simple it is.

  // ==UserScript==
  // @name         Youtube UnEmbed
  // @version      0.1
  // @description  Converts embedded Youtube iframes into links
  // @match        *://*/*
  // @exclude      *://*.youtube.com/*
  // @exclude      *://*.reddit.com/*
  // @exclude      *://looptube.io/*
  // @grant        none
  // @run-at       document-idle
  // ==/UserScript==

  (function() {
  'use strict';

  const SITE = "https://www.youtube.com"; //m.youtube Invidious etc
  const LINK_TO_TIMESTAMP = true;
  const SHOW_PREVIEW_IMAGE = false;

  const replaceEmbeds = () => {
    document.querySelectorAll('iframe').forEach((frame) => {
      const frameURL = frame.src || frame.dataset?.src;
      if (!frameURL) return;
      const match = frameURL.match(/(^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);
  })();

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

  // improve styling
  img.className = frame.className;
  img.id = frame.id;
  img.style.width = frame.width +"px";

(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();

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?

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 host your own videos and use a plain

> Or link it from a CDN

Pure insanity.

And just plain

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.

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.

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.

This would hurt advertising impressions.

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.

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

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.

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.

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.

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-plugin

I would even go further and wonder why lite-youtube still requires 100K? And why they are not shared across different sites.

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.

Cross site resources caching has been disabled in all major browsers for a few years now, because it was used for tracking.

> 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.

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.

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.

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.

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.