Readit News logoReadit News
charrondev · a year ago
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.

btouellette · a year ago
I've got a site that is basically infinite scroll of mostly YouTube, SoundCloud, and Reddit embeds and had to do this for YouTube for it to even be functional. Using the YouTube provided thumbnails though since I'm not too concerned about tracking.
BodyCulture · a year ago
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!
pier25 · a year ago
Is there a similar solution for SoundCloud?

Their player is also super bloated.

diggan · a year ago
You can basically do this with any embeds (granted they don't do a lot of global fuckery, which is a lot of them). Make sure the embed code gets evaluated within a function, then call that function when the user clicks on your "proxy" image. You might have to do a replace of the DOM elements as well, so the embed code gets what its expecting.
paulirish · a year ago
There are a few "facade" solutions listed at https://developer.chrome.com/docs/lighthouse/performance/thi... But.. AFAIK nobody has made one for Soundcloud.
ttymck · a year ago
Any tips or examples you are able to point for on this solution? I am coincidentally working on this exact problem at the moment.
bfelbo · a year ago
Yes! @OP, would love to hear more on how you’ve done this.
mindhunter · a year ago
Do you also cache or proxy the thumbnail? Google can also track them when hotlinking it.
tczMUFlmoNk · a year ago
GP says "proxied thumbnails", so it sounds like yes.
mmmmmbop · a year ago
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/

skybrian · a year ago
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.

roelschroeven · a year ago
> 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.

Stratoscope · a year ago
> 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.

Talinx · a year ago
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?
nnf · a year ago
I would much rather wait a few hundred milliseconds for a video to start during the few times I decide to watch an embedded video than to wait for the full video player to load every single time I visit a page with an embedded video that I'm never going to watch. Similarly, I would much rather have every stoplight I approach be green for me rather than having every light be red but for not very long.
vasco · a year ago
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.
bcrl · a year ago
How will Google collect data about every page load then?
kylebenzle · a year ago
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?

tjoff · a year ago
>Every additional millisecond of load time will reduce engagement

This is something people believed in the 90s. None of the megacorps give a damn about that as is evident by their behavior. If it doesn't matter for them it doesn't make sense for you to optimize that on their behalf.

It is a non-issue for this usecase.

But please do care about it for the rest of your stack.

qwery · a year ago
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.

IX-103 · a year ago
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.
giancarlostoro · a year ago
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.

Scaevolus · a year ago
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!

marcosdumay · a year ago
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.

froggit · a year ago
> 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.

qwery · a year ago
I'm not seeing such a difference, but it is there. I'd be surprised if it was as high as 100ms. Obviously different computer environments[0] will have an impact here.

I would be much less likely to notice it as "slow" if it didn't show me a spinny-spin. It's advertising that it's slow!

I agree that the click-to-playback lag time would have such an effect, but how significant it would be is unclear. It would take an entity the size of, say, Youtube, to begin to measure this sufficiently.

[0] Firefox, 2(?) year old laptop, i7-1185G7, windows 11, updating Edge (in 32-bit mode) 24/7, haven't rebooted for a few weeks

divbzero · a year ago
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).
stemlord · a year ago
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
dangus · a year ago
This is a good point. Google doesn’t care about the total page load time of your website, they care about the load time of their video.
knome · a year ago
Does the potential lesser engagement with videos matter in the face of those videos causing a delay in loading the page that displays them? You'd need to check per-video engagement drop against people not bothering to engage with the site in the first place.
estebank · a year ago
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.).
cogman10 · a year ago
> 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.

57FkMytWjyFu · a year ago
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.

lelandfe · a year ago
It also seems like it takes two clicks to start a video? Is that a bug?
tantalor · a year ago
Why is it slower?

It feels same to me (Pixel phone)

maxloh · a year ago
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).
squigz · a year ago
> Every additional millisecond of load time will reduce engagement

Is there any data on this?

Deleted Comment

_wire_ · a year ago
> 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.

Deleted Comment

dubcanada · a year ago
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.

qwery · a year ago
> 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.

lotsofpulp · a year ago
>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.

qwery · a year ago
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/

creatonez · a year ago
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.
X-Cubed · a year ago
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.

ethanol · a year ago
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

arp242 · a year ago
> 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.

withinboredom · a year ago
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...
donohoe · a year ago
One way to help reduce overall weight of embeds (and improve the UX imho) is to block the ads - if you are able to leverage "Content Security Polices" on your pages.

Example META tag:

  <meta http-equiv="Content-Security-Policy" 
  content="default-src 'self' 'unsafe-inline' *.your-cdn-if-any.com 
  www.youtube.com *.googlevideo.com *.ytimg.com">
More info: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...

pshc · a year ago
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/

8organicbits · a year ago
That's clever, well worth its own blog post.
swyx · a year ago
can you tldr it? just one little meta tag defeats google's ad services? why dont we all slap it on our html templates?
Aurornis · a year ago
> 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.

dceddia · a year ago
I recall an article where Facebook or Uber or some other big tech co found something similar when they added some optimizations, and it turned out that it was being accessed by an entirely new market that couldn’t even load the page before.

I wonder if it’s a similar thing here. Maybe the lighter embed is small enough that a huge swath of people is actually able to load a video now, but they bounce because playback is too slow on their device/connection. It would shows as a higher percentage of “person stopped watching video” instead of (nothing, because they never fully loaded the player).

kirubakaran · a year ago
qwery · a year ago
> 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.

user070223 · a year ago
User side solution click 2 load for ublock users(note that chrome is transitioning to manifest v3 and might not work) is the following thanks to yokoffing/filterlists https://raw.githubusercontent.com/yokoffing/filterlists/main... (Betterfox creator, he has other useful filters on github)

  !||youtube-nocookie.com^$3p,frame,redirect=click2load.html,domain=~bing.com|~google.com|~duckduckgo.com|~video.search.yahoo.com
  ||youtube-nocookie.com/embed^$3p,frame,redirect=click2load.html,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

schiffern · a year ago
Click2load is an improvement, but embeds still suck.

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

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

  (function() {
  'use strict';

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

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

Featherknight · a year ago
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.
KomoD · a year ago
I suggest using MutationObserver instead of just running the replaceEmbeds function every 3s.
divbzero · a year ago
> 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?