[iMerNibor]

What gets me the thumbnails are now so big, they're blurry since the images need to be stretched to fit now!

The preview is 530x300px on a 1920x1080 screen vs the image shown being 336x188px

How this passed any sort of QA is beyond me

[jsheard]

They clearly need to conserve bandwidth for the most important assets - the 12 whole megabytes of Javascript.

[jmb99]

Genuine question. I’m assuming that, since YouTube is owned by one of the largest tech companies in the world that they’ve optimized their delivered JS to only what is necessary to run the page.

What on the YouTube home page could possibly require 12MB of JS alone? Assuming 60 characters per line, that’s 200k lines of code? Obviously ballpark and LoC != complexity, but that seems absurd to me.

[titzer]

Webpages are dumptrucks for every bad feature anyone ever thought up and are in a constant state of trying to re-framework their way out of the complete mess of utils that get shipped by default. Need a gadget that implements eye tracking via sidechannels? Yeah, they got that. And then justify that with "analytics" or anti-fraud and abuse, and no "click jacking" or whatever crap, and roll it times 1000.

[dylan604]

>What on the YouTube home page could possibly require 12MB of JS alone?

all of the code that hoovers up your analytics on what's been looked at, what's been scrolled past, etc. maybe I'm just jaded, but I'd suspect so much of it is nothing but tracking and does little for making the site function

[jsheard]

Fun fact: Googles own web performance team recommends avoiding YouTube embeds because they're so obscenely bloated. Placing their <iframe> on a page will pull in about 4MB of assets, most of which is Javascript, even if the user never plays the video.

https://developer.chrome.com/docs/lighthouse/performance/thi...

YouTubes frontend people just don't care about bloat, even when other Googlers are yelling at them to cut it out.

[leptons]

We lazy-load Youtube iframes, fixes the problem pretty easily.

[jsheard]

Depends on how you do it, loading="lazy" helps a bit, but the iframe still gets loaded when it enters the viewport even if the user has no intention of watching the video. The best approach is to initially show a fake facade of the player and only swap in the real iframe after the user interacts with it, which is what Google recommends doing in that article.

[leptons]

>but the iframe still gets loaded when it enters the viewport even if the user has no intention of watching the video

That doesn't affect page speed scores if the video is "below the fold", and that's all that I really care about. If Google Lighthouse doesn't complain about it, then my job is done.

[jsheard]

> Assuming 60 characters per line, that’s 200k lines of code?

The code is minified so there's relatively few characters for each source line, if you run it through a pretty-printer to restore sensible formatting then it turns into well over half a million lines of code.

[ars]

That's the full YouTube player - you were assuming it just has the code for the homepage, but actually it gets the entire player right at the start.

[Mr_Minderbinder]

Meanwhile, loading up a channel page with Invidious pulls in about 700k and half of that is the banner. JavaScript was not mandatory (on public instances) but it is now due to AI scrapers.

[charlesabarnes]

I've recently noticed that the thumbnails on the homepage are higher resolution than the thumbnails on the subscriptions page

[sd9]

Same for me. How strange.

[cucubeleza]

they want more money, less videos more ads, probably the UX/UI team was against it but you know how those big techs are

[bryanhogan]

The perfect oppurtunity for more AI, image upscaling! /s

Or maybe the next step will be automated AI-generated thumbnails based on the video and the user itself, so each user will be grouped into a different category and gets served a different thumbnail accordingly.