zlacker

>>jayden+(OP)
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

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

>>jshear+a7
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.

>>jmb99+gl
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.

>>jshear+Om
We lazy-load Youtube iframes, fixes the problem pretty easily.

>>lepton+Vp
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.

>>jshear+vq
>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.