Optimizing Interactions

[00:00:00]
>> Let's say that your website is already loaded, you are okay with it, now we will see in our example if there is anything else we can improve. We are about to hack the interaction experience. Well, first and big warning, we shouldn't do client-side rendering, I'm sorry I know it hurts, okay?

[00:00:20]
But client-side rendering for the initial load, for the content that you see initially, it's a very bad idea, it's a terrible idea for performance. And again, yeah, but we know we like React because blah-blah, I don't care, we're losing money. So it's not enough reason, whatever reason you are thinking, it's not enough reason if we are losing money.

[00:00:41]
If you are paying for ads, if my company is paying for ads, for a website that then users are not using because it's slow. And if you don't believe me, because I know that a lot of you will not, you are not really convinced that this is true, that a couple of milliseconds will make a difference.

[00:01:00]
There are a lot of research on that, but do a research on your own website. So do some A-B testing, in fact, Amazon did that and they released the research, that was a long time ago. They they were creating experiments with groups, so let's say in the next hour, we split all the Amazon visitors in 10 groups.

[00:01:21]
Group A, we won't give them any delay Group B we have 50 milliseconds delay, 100 milliseconds, 150 and then we analyze conversion. If you are large as Amazon, you will see a lot of traffic and in one hour you can get enough details to have conclusions and you will see.

[00:01:44]
Okay, what's the difference when you have delays and when you don't have delays for the same UI? And on the Amazon research, like a decade ago, they realized that they were losing 1% of sales, 1% of sales, every 100 milliseconds of delay, that's a lot, it's a lot of money, okay?

[00:02:05]
That might be different for your case, that might be not the case today, it was 10 years ago, maybe it's different but anyway, it has been proven that always, better performance leads to better conversion. How much? It depends on the case and again, you can measure that, you can do an experiment and that's why client-side rendering is a bad idea.

[00:02:24]
That's why even the React team, if you go today to the React documentation that was updated a few weeks ago, now they don't suggest client-side rendering. It's still there as one option, but it's not the recommended way to do React, the React team is recommended to do React with a framework, such as Next.js.

[00:02:46]
The framework that is server-side rendered or it's a mix, it's a start as a server-side render, and then you move to the client, which is fair and that's because of performance. Because now we know that pure client-side rendering has performance issues and pretty bad performance issues, okay? Does it make sense?

[00:03:07]
So also if you really have heavy tasks, you're gonna start thinking about moving that to WebAssembly. So if you're taking, you have a long, really long task and creating a thread is not making that better because you can create web workers as well with JavaScript. Another way is to create a module in WebAssembly, now it's compatible with every browser Squoosh, the app that we saw that is converting the apps, is making all the conversion in WebAssembly.

[00:03:36]
So it's an option, it's there for us, I know that as web developers, it feels really strange, like some strange guy there that we don't wanna see, we don't wanna touch but it's something interesting, okay? To see, we're not going to write dumb code in WebAssembly but for a lot of processing in might work.

[00:04:00]
Yeah.
>> Can you give me a real life example of something you would use WebAssembly for?
>> Well, Squoosh is one example, in that case, so processing bytes, binary data, in this case converting JPEGs into WebP files, that's a good example. Today, decoding and encoding things like Amazon Prime, video, Netflix, StarPlus, Barmah cloud, they are all using WebAssembly for decoding and encoding video, typically it's about processing data.

[00:04:33]
Of course then we have, talking about legacy, we have some interesting things going on on the web. You can run any legacy DOS application, for example or you can run Windows on top of a browser or Quake III and there are a lot of examples like that and they are using WebAssembly.

[00:04:54]
They are just taking some code written in C, 20 years ago, 30 years ago, and they're converting that into a WebAssembly module and running it in the browser. So yeah, those are very niche idea for a web app, but my thinking is that if you are parsing a lot of content, making a lot of calculations, and you see in the console or using APIs that I will mention in a minute.

[00:05:22]
That it's a long task, so it's taking too much time to execute, then you might be thinking, well, maybe we should start thinking about WebAssembly.
>> And I'll just add that we have a course by Jim Young on WebAssembly as well.
>> There you have it Frontend Master for everything, you know that.

[00:05:42]
You shouldn't be watching Netflix at all, everything should be here at Frontend Masters. Okay, so stop serving legacy code, what is that? That is unless you really have a need for that, like you're serving some customers that are still on IE for some reason, you shouldn't export ES5 content anymore.

[00:06:06]
From, if you're using a framework or library, you can change the setting, it's safe to move to ES6 today, that will ship less JavaScript and we know that JavaScript is really harming performance. If you still need to serve some old user, maybe it's better to have two versions or something like that.

[00:06:26]
Because we don't wanna have performance just for 0.1% of your users that might have a problem and you're harming performance for 99.9%, it doesn't make any sense. Reactive Web Performance is kind of an intro for the next and final part of the workshop, it's an idea. What if you can know about the context with APIs, what's the context?

[00:06:52]
The performance context, such as how's the latency, how's the bandwidth, how's the CPU and GPU? And you can make decisions about that, so using different APIs, Network Information API, it's a Javascript API that will let you know the current for example, latency. Performance observers, Save-Data, that's client hint that I mentioned before, if the user wants to save data, Device Memory and more and then based on that, you Provide a Consistent Experience.

[00:07:23]
I mentioned Netflix and other video-based apps in the past 10 minutes and we can take them as examples. So, think about this, when you're watching a TV show or a movie on Netflix, do you see a buffering a lot, like a loading spinner? Maybe the first second, but then while you're watching, you get a consistent experience even if you're having network issues.

[00:07:55]
I'm not sure if you have seen that in action, but maybe you're watching a 4k video and at one point it lowers down the quality and maybe it's very pixelated at one point and then it comes back to 4k. So that's actually providing a consistent experience, so it's not like breaking the flow of watching or having that experience, it's just changing the quality.

[00:08:20]
What if we can think for some web apps, something similar? So enable or disable Web Fonts, Change the Service Worker's cache policy to be more local or be more remote like cloud-based. Remember service worker that can serve locally? Well, maybe we can serve locally only if the latency is too high and if the latency is pretty good, well, maybe let's go to the cloud and be more updated.

[00:08:47]
Decide between server-side render or client-side render, maybe you say, you know what, I can't change this. Maybe you say I can't change this but if the user is in a mobile phone, that is a low level, low memory, maybe I'm, let's jump to server-side render. Because it's going to be really painful for the user to execute our three megabytes React application client-side.

[00:09:14]
Reduce the amount of data that we are loading by default, and even delivering a 1x image that is an image without high resolution, standard resolution image, not matter the device pixel ratio. Because maybe you are in an iPhone 17 pro ultra max, but you are in the middle of nowhere with 2G, so it's not about the phone, the context is more than the phone, the device, and the screen size.

[00:09:43]
In this case, the content is about the latency, the bandwidth, if you're in roaming and paying for the data or not, so maybe you can change the experience, okay? Makes sense? So you can define based on different situations, what are you going to send to that user? Google is using this a lot, because we need to serve users everywhere, okay?

[00:10:09]
That's one provider doing that, and even you can even set different budgets based on the context you set, so you say okay, if we are in this context we set a budget of 170k total for all the JavaScript, all the CSS. If you're in Wi-Fi on desktop, we have more batches, so let's use it, of course, this has a lot of work behind because you need to think about how we are going to do that, how you're going to create that structure, okay?

[00:10:39]
But it's possible, I'm saying that it's possible. Also today, you can get reports from the browser, I'm not sure if you know this, so you can get real user metrics from JavaScript. There is, for example, the reporting API,with the reporting API, when you are serving the user the HTML, you can add a header, it's called "Report-To".

[00:11:06]
And that header will have a server endpoint, then the browser in user's device will send you information every once in a while about what's going on with performance and other problems for that particular user. And you will receive that information at your endpoint, okay? Make sense?
>> Is there any kind of permission problem with that or-

[00:11:33]
>> It's first domain only, so it should work on the same origin, so it's your own website just giving the browser an endpoint, so you don't need a permission. And it's on a best effort scenario, so it's not guaranteed that you'll receive all the data but you will receive some and then you can gather analytics and do something with it.