As pointed out in the same event, the iframe of YouTube has a huge payload, they not only load the scripts for the video itself, but for the ad network, for the tracking they needed, and other kind of tasks they had to run on the main thread and this puts a lot of heavy load on the single thread and slows down the website completely, even the place we were putting in our homepage.
And in the same event they were presenting these web components they called Light YouTube. Light YouTube was a way to provide videos with really focused on performance. It was more than 200 times faster than the load of the page with the use of this custom element.
What it does? In fact, what it does is take the image for a video ID, because you can get statically the image for a video if you know the ID, and it only places the image and only loads the iFrame when the users want to interact with it, going with the mouse and the play. So when the user starts these actions, in the background it starts to load the iFrame and presents to the user the video they want to see. But all the URIs are loaded with the Per-Load directive, which is way leaving the single thread free for your page load faster.
And because of that, since I got back to Brazil, I started porting to React, because for me was really a kind of thing that was bugging me. And I think it would be really great to also share with other people this kind of work. That presentation from Paul Irish was really great for me, and showed me, you know, the way to open source. Since then, I was only working on some minor issues from packages from other people, but since I published this little library, I started more and more creating my libraries and components.
And why it's so important I'm talking about? I think one of the things I since the beginning, I placed in the library was to, you know, enforcing some kind of best practice, like, you know, I had id for get the id for the video that uses both in the and the image reference, the path, and title, because to generate and to the image be more more accessible, it needs to be an outtest. So, I made purposefully required to put not only the ID but also the title because I think when we put in place this kind of wide rails, we move a dent in the way that developers approach their implementations.
Some months after my first release, I got this pull request that one user put this option to use a privacy enhancement mode. It uses a no-cook ROI that, YouTube provides, to people decide if they wanted or not, that their iFrame is getting or no information from you in that place because you are in someone's website and you don't want that, you know, Google skip tracking of people there or the person that was in our website in that moment don't want to be tracked. It's an option that people should have, right? And I didn't know that even this kind of option existed before this pull request.
But since I received that, I saw not only as a good option, but months later we decided to put this not only as an option, but purposely defined as a privacy by default. Because there is this book, Noti, that talks about how people react in a React conference. It's a funny thing to say. But Noti talks about how little defaults can help people take a better choice for the community as a whole. Like, if people donate blood by default, or their organs, for that matter, in fact, the country will have more donors because, if people had to practically say, I want to be an organ donator, they will not do that and they will less say, I don't want to be a donor. So only people that are really strong about not being an organ donor will be able to have this option. But, nudge people to make better decisions for the whole, is the purpose of creating this kind of guardrails.
And another thing, was an issue that a user opened that, you know, he found an SSS bleach error in the library that I was using a GV when I needed to use a button, is a very common problem. And I always use the right element and I have to, you know, put something in place to, you know, the container was not interactable and for me it was really great to see the feedback from the community after fixed issue, because not only people, not only one people was, you know, complaining about and how can with little effort sometimes we can make a huge difference in someone's experience.
And for me to show how this phrase is really great to think about every decision we make in our components, in our applications and how we can start to think in better ways to provide better user experience from the ground up, from straight from our components, like in TIS library. Good intentions never work. You need good mechanism to make anything happen. I think this is a great quote by Jeff Bezos, because it talks about we all have good intentions, right? I didn't create my library thinking I will just use Jib because whatever, I don't want to be accessible for people. No, I just don't know better at the time.