Performance Optimization

[00:00:00]
>> Evgenii Ray: Now, let's move on to performance optimization section. So now we're gonna learn how to optimize our web assets to provide the best web by those metrics. And there are three main metrics that we need to track. So the first one is LCP, which is largest contentful paint.

[00:00:18]
So it measures the loading performance of your app. And ideally, this metric should be less than 2.5 seconds, and even maybe under the two seconds. The next metric is IMP, which is interaction to the next pane ,it's basically when you update your data of the app, it may take some time to refresh the UI due to flow.

[00:00:43]
So, ideally a reflow should take less than 200 milliseconds and next is a layout shifts. So generally layout shifts happens when some minor UI changes, so when you do some small animation or increase the size of some components. Then it impacts the visual stability because other elements may respect the size of the changed element and also adjust their size.

[00:01:08]
So you need to make sure that the CLS is less than 0.1. All these metrics can be governed using the Lighthouse in the browser. So we are going to focus largely on the largest content paintful, because this is one of the metric that impacts the business in terms of the results.

[00:01:30]
So the less the LCP, the better results for the business. And we start with the network performance. So as we discussed before, for HTTP, we have three versions of protocol, one is http/1, http/2 and http/3. So HTTP1 goes into legacy, so now only 20% of the servers use the HTTP1 for most of the clients now and servers use the HTTP2.

[00:01:59]
And HTTP3 probably will become a new standard in next four or five years, let's hope for that. So the first and the easiest way to optimize the performance of your web app is actually to change the server. And the reason is the HTTP1 has problems with the network performance, because HTTP1 is very limited to the number of connection.

[00:02:24]
So initially, you can make only one request in parallel. So all your resources has to be loaded one by one. So if you have the front-end master website, so first we would load our HTML, then we'll load our CSs and the our GS. The browsers found the workaround, so they basically opened the new TCP connection and right now the limit is five TCP connections.

[00:02:56]
So we could five resources in parallel. And if you have on your website hundreds of resources, then everything is getting queued, and your website loads slowly. And this is actually the reason why webpack was created. So, initially, the webpack was just merging all assets in a single bundle so it can be loaded in a single hoop.

[00:03:19]
But now it's becoming the anti-pattern, so now we actually want to split things because of HTTP2.
>> Evgenii Ray: So also the issue with HTTP1 is the data we have, because we are sending these headers all the time in non-compressed state. And the migration to HTTP2 is pretty easy infrastructure-wise because HTTP2 is backward compatible with HTT1.

[00:03:47]
And if we think about the maintaining and the migration costs, that maintaining the HTTP1 server costs more in the long run. Because to optimize the performance of the web application using the HTTP1 server, you would need to introduce additional infrastructure. The way how can you load 20 resources in parallel under the HTTP1?

[00:04:14]
So you would need to create multiple domains for your assets. So, you'll have the images domain, then you will have your JavaScript domain and so on, because the limitation is five connection per domain. This is called domain charting. And before you had to use the domain charting to improve the web application performance.

[00:04:34]
It's very expensive in terms of infrastructure. Also the thing, the benefits of HTTP2 is
>> Evgenii Ray: How it's established the connection and remember the HTTP1 do the full thing, three way handshake so it has to do free network trips every time we do a new connection. But when it comes to HTTP2 or 3, there is a feature called multiplexing.

[00:05:01]
So, we establish one single TCP connection with a server. And within this connection, we could potentially have 200 parallel streams loading the data. This is achieved because the HTTP2 is the binary protocol. So, it transfers the binary data. So, we can split our channel into the multiple streams to transfer the byte data.

[00:05:29]
Within one connection, we can load 200 resources in parallel. So, as you can see comparing to HTTP1, where its limitations just five and you had to maintain five TCP connection that would result a significant energy drain on the mobile devices. So, HTTP2 is much more efficient in this sense.

[00:05:48]
So, you don't need to build the overhead on the server infrastructure to maintain multiple domains because now the HTTP2 server could served 200 responses. And I think for any website 200 resources will be pretty good number. I don't expect that any websites to actually reach the limit.