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.
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.
> 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.
I tried the same route, but got the logs correctly. It gave me a HTTP 410 error. I wouldn't be surprised at all if VLC's youtube plugin is just too old and there's a better one somewhere else. But in the meanwhile, mpv's plugin works (if you're using yt-dlp and not youtube-dl, that is)
Logs not being directly visible in the VLC UI and not having a default log file location plus the fact that even going to advanced settings and configuring things doesn't make logs show up after the first try is not Google's fault, though.
Despite having defended FOSS and advocated VLC ... I understand your viewpoint here. Calling on people to contribute bugfixes isn't especially realistic. Filing a bug on the fact that VLC has poor debug/log tools would be helpful though.
Particularly as a useful logging / debugging capability should enable more useful bug reports specific to function.
Sorry it's not working out for you, thanks for trying regardless.
I'm just jaded at this point. FOSS won the battle and lost the war. It's been subsumed into the bowels of these corporations that are ending up mega predatory.
I've used VLC successfully in the past on Android using the "stream" option. When I want to view video (as opposed to just listen to audio, my usual Android mpv use-case) that's delivered joy. On MacOS, I'll use mpv to play either audio only or video, with joy in both cases.
Don't forget that the other side of the equation is YouTube ACTIVELY WORKING TO BREAK COMPATIBILITY, and with considerable success. E.g., Invidious and Piped had been b0rk3n for a few months, though on checking again in the past few days, Invidious at least seems to be working again. So placing the whole burden on FOSS devs is at best exceedingly biased criticism. Those are in fact your friends, not Google.
Its the nature of the beast. For a while I used a custom ublock filter to strip out the recommended videos section, the comments, whatever I considered junk pixels. Now I just pull the video to /tmp/ and don't have to deal with buffering (somehow still an issue in 2024).
> 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.
But I don’t want full screen, I want it to take up the full window that I have allocated to the browser, while still allowing me to multitask in other windows.
You can make firefox fullscreen _within the window_ by changing a flag in about:config ... full-screen-api.ignore-widgets (set to true)
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.
As an additional tip, if you want to get rid of the "You are now fullscreen" (or whatever it says) that comes across the top... you can set the following to 0
It's in Chrome natively. But in Youtube you have to right click on the video twice.
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.
It’s not weird UX when you consider why it’s so hidden: to increase “engagement” metrics (i.e. make it more likely for you to click on other videos, view/interact with ads/etc). Same reason the feature is unavailable on iOS (even though it’s been natively supported by the OS for years), unless you pay whatever google wants for a premium YouTube subscription.
That behaviour is so weird that it feels like an oversight. It's like we're not supposed to be able to access those options at all. A lot of people are explaining it by saying PIP mode lowers engagement so they hide it. But then why have that as a built in feature at all?
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?
I suspect that’s what they do already. The trouble is that it’s heavyweight speculative execution that often doesn’t pay off, but it wastes resources anyway.
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.
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.
Do they? They have the biggest browser, an online office suite, a cloud, and a giant ad network. They want to maximize internet use, or they should want to.
Google makes the web better for itself. Which is not the same as making it better for everyone else. After all, 77% of their revenue comes from online ads.
No users = no clicks = no Google. Their incentive is to strike a balance between profiting off users and driving all the users away. I'm not commenting on whether they're getting it right.
The issue is them getting it right is finding a balance point which is maximizing their profits at the expense of the general public. They are willing to make a Web Browser and Android to limit how much people can avoid being tracked etc.
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.
"According to the 160-page report, the employees found evidence that Mountain View was demoting its competitors and placing its own services on top of search results lists, even if they weren't as helpful." https://www.engadget.com/2015-03-20-ftc-report-google-search...
Unfortunately no, Google wants to maximize their profit, and they'll enshittify the web in that pursuit until it collapses. They have Android, they don't need the web to exist.
> They have Android, they don't need the web to exist.
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.
Apple sells expensive solutions to cash-rich consumers (some of whom are also time-poor) who are willing to throw money at a technical problem (setting up a device with an OS) to make it go away (ie, buying an iPhone, iPad, and Mac).
Why would you ever want to advertise to anyone else?
Also, ads. I guess the shorter the time is between clicking the play button and the ad starting, the more people will have "seen" more of the ad before deciding that the video isn't worth watching the ad.
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?
Sounds like a bug that could most likely be fixed. I don't see any noticeable difference, maybe one or more spins of the throbber, practically instant on all versions.
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.
Caching on the web has gotten worse/more difficult recently since browsers (including Chrome and Edge) have started to partition the cache by top level site. This was necessary to keep trackers from using the cache status of a resource for tracking users, but had the side effect of making common resources much less likely to be cached.
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.
>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.
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.
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.
I'm sure they do care, but they seems to care more about everything else. Or just are victims of decades of bloat. Or too many teams, where one team obliterated the tuning a hundred other teams did.
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.
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.
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!
I remember even after flash player it buffered video though? They changed the behavior after Flash was dead probably as someone else suggested to not waste bandwidth on people closing the tab.
Edit: in fact every native web video player downloads as much as possible as far as I can tell.
The native <video> and <audio> tags buffer a few megabytes at a time. This is easy to see by opening a video file in the browser (not from file://) and watching the network tab.
Depends on how you set it up apparently, I assume it changed over time:
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)
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.
Is it to stop downloaders? I doubt it since they work just fine, it's probably just a way to reduce resource usage on more constrained platforms like low end mobile phones or smart tvs.
There is probably a lot of code sharing among all platforms such that companies don't want to support two different buffering flows.
It's MPEG-DASH, and I think Apple has HLS. It's basically better by every possible metric _except_ the one you mentioned, which I'm sure you'd agree is an uncommon use-case. It's not designed to stop downloaders, it's trivial to download.
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.
> 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.
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
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).
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.
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.).
> 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.
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).
> 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.
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.
> 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.
>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.
Oops, yes I misinterpreted that. I was thinking how can 250ms be the average reaction time when it’s too slow of latency to play a video game, wouldn’t average reaction time have to be lower since people do notice lag at 250ms pings?
With aids, we can perceive and notice even smaller intervals. I play a lot of Fortnite Festival, which is the Rock Band-style mode added near the end of the year. This game, unlike any previous game in the genre, has "perfect" judgements for note hits. The window for a perfect judgement is something around 20 or 30ms. The game also gives you an average offset from "dead on" for each song, measured in milliseconds. Since the perfect judgement is immediate feedback, it enables players to perceive when they are just a few milliseconds off and correct for it. I regularly get average offset results of +/- 3ms or better, including plenty of 0ms average offsets (this is of course averaged across all notes in a song, which I am playing on a plastic guitar on Expert difficulty).
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.
A key difference here is that you’re able to anticipate and plan upcoming actions, because you’re familiar with the general structure of music and/or the specific song.
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.
Rhythm is a completely different beast though because you can anticipate. Most musicians would be more accurate than the average person but wouldn't do any better in a "click the mouse when the screen flashes red" type test.
“Reaction time” isn’t really a single value: it depends immensely your own attributes (age, experience, level of alertness or fatigue), on what you’re reacting to and how you react to it.
Under certain (admittedly very specific) conditions, people can view an image, categorize it, and indicate the category with eye movements, all within 120ms.
Here’s one demonstration:
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/