Gregory's ServerStarting today, https://tonsky.me/talks/ is completely JS-free.
I removed all the YouTube embeds (1 embed == 3 MB !!! of JavaScript) and self-host all the videos.
Should help with preservation, too.
 22 comments
 Я все себе никак не прикручу ytp-dl для выкачивания вставляемых видео. И чтобы для сохранения на будущее, и для уменьшения JS. Ну и поставить себе preload=none потому что preload=metadata все равно почему-то выкачивает все видео Ж)  @nikitonsky К сожалению в ФФ видео запускается без звука и попытки его включить нажанием на перечёркнутый значок динамика, ничего не дают.  @nikitonsky all that's left is to recode all those into resolutions that are more acceptable to streaming on imperfect connections. And add audio-only options - those are podcasts, after all. And set up a CDN so it loads faster. YouTube is not just a distributor of megabytes of JS, for better or for worse. Please at least leave links to YouTube near each video. Right now, many of them are _literally_ unwatchable for me - short of downloading whole files, of course. @nikitonsky the first talk on the page, for example, is a 4+ GB video. On Firefox on my phone right now, it manages about 1 FPS. @nikitonsky also, not defending YouTube here, but still: does the "3 MB per embed" figure account for caching? I may be wrong, but I'd imagine it being more like 3 MB overall. Haven't actually tested that, though. @nikitonsky I tested it. Did an empty HTML page with 8 YouTube embeds in <body>. Used a more realistic metric of download size - private mode, but cache enabled. Meaning that only the first load of each script would trigger a network request. It came to slightly less than 1 MB of JS downloads for the whole page. Including other data - about 2 MB. @iliazeus you probably count compressed size? But your browser executes uncompressed one @nikitonsky the browser caches and executes compiled bytecode and/or machine code, AFAIK. You're probably looking for a "CPU time spent on page load" metric. Code size is irrelevant for what you (probably) want to measure. @nikitonsky more <video> elements _also_ take more time to process, though :) Your initial "3 MB per video" just sounds a bit like (unintentional) fear-mongering - it's easy to misunderstand it as "the browser downloads that much more data". And also, I just wanna ask you to consider if the tradeoff you're making here is worth it. Considering the issues I described in a neighboring thread. @nikitonsky also, if I'm being a pedant, your statement is false :) while (true){} takes infinitely more time to execute than veryveryverylongname=1, for example @nikitonsky this exaggerated example might be surprisingly relevant, since the code might just detect it's being loaded more than once, and skip all the initialization steps on subsequent runs. Embedding several videos into a single page is a common use case, after all. But I've not tested that, so I can't say for sure. @iliazeus I can see the time it takes to initialize code _every time you scroll past it_ with my naked eye. That’s definitely a sign of a computer doing crazy amount of work @nikitonsky that's a completely different website Again, I was talking specifically about YouTube embeds, and how simply changing them all to <video> elements might not reduce the computer's work by that much, while introducing other complications and edge cases along the way. @iliazeus Yes, that’s the one from the post about JS bloat Anyways, if Google can’t reduce their embed down from 3 MB (while other people can) and also recommend to use 3rd-party embeds, I don’t trust them no to waste CPU, too @nikitonsky can you please at least add links to YouTube videos? As I wrote in a neighboring thread, the <video>s are way too big to comfortably watch on a phone, or with a less-than-ideal connection. And hard to skim through to find a part I'm interested in, because of lack of chapters or a transcript. (as it turns out, _some_ of the things a YouTube embed does are actually useful, after all :) @nikitonsky thank you Sorry if my comments came of as too aggressive btw, I didn't mean that. Still having some difficulty expressing my thoughts correctly, especially in English. @cba85 Yes I forgot about Mobile Safari being an absolute drag. I’ll re-encode the videos, stay tuned |
@nikitonsky Nice! This is absolutely impressive how many public talks you gave Niki! Wow! 🤯