Optimizing Data Transfer

[00:00:00]
>> Another section is hacking data transfer. Well first, HTTP/3, we have already mentioned this, but try to enable HTTP/3. We already mentioned it's the transport protocol over UDP that will reduce latency and connection messages. It's the same HTTP/2, so no different API. It's not gonna add you a lot of overhead.

[00:00:25]
So this is roughly how it works. By the way, it says QUIC, because QUIC was the, let's say the draft name of HTTP/3, but it's HTTP/3. So on a normal TCP + TLS, so that's HTTPS, you have all these handshakes, you need to go back, go back, go back, go.

[00:00:46]
And, of course, that has a latency. With HTTP/3, you just go. Okay, so even it's called, for the second communication, there is a zero latency. Zero RTT, round-trip time. So on Google, it improved 3%. On YouTube, it has reduced the buffering of video by 30%. And Facebook is using a similar protocol on their native app.

[00:01:21]
And it has improved 2% performance. Just by enabling something in your server or using tools such as Cloudflare, that will do that for you. I'm saying all the time Cloudflare because it's the one that has a free trial that you can apply on free websites pretty quickly. If not, there are a lot of other providers that you have to pay for.

[00:01:40]
Also, Cloudflare has a premium account, but Cloudflare is used a lot on many websites because it has a free trial. And according to Google, 75% of requests that are happening on the web can be optimized if HTTP/3 is enabled.
>> So the difference between, what is it, UDP and?

[00:02:02]
>> TCP.
>> TCP, is with UDP, it allows you to sort of, you don't retry any failed packets? What are the, I guess I don't quite understand. Sounds like that would be a bad thing with web tracking.
>> I know, yeah. It sounds like that. For live video, it sounds okay because, okay, if you have to load some frames, well, okay, let's move on.

[00:02:26]
With data, you want all the data. So it feels dangerous, you're losing packets. But actually, HTTP/3 is using UDP and adding a control thin layer on top of that. So HTTP/3 is guaranteeing that the packets will be received, and they will retry packets if they are lost. But it's a thin layer written from a scratch in the latest five years, three years actually.

[00:02:55]
It's not the original TCP protocol that was written like 30 something years ago. And they created that thin layer, that control layer, specifically targeting HTTP-based messages, which means that it's much more efficient than TCP. Does it make sense? So with UDP alone, yeah, we will lose the quality of the content, right?

[00:03:23]
But it's not UDP alone. HTTP/3 uses UDP, but also it has its own algorithm on top of UDP.
>> Okay, yeah, no, that makes sense. I can imagine with TCP there was sort of old spec and baggage you had to deal with-
>> Something like that. Yeah, it has to do with that.

[00:03:42]
>> iiii On top, it works so much faster.
>> Something like that.
>> That makes sense.
>> Okay, use Zopfli. What's Zopfli? It can save you data over GZIP. Remember that we mentioned that we can use GZIP. Well, Zopfli, it's a new algorithm. It's recent over GZIP, okay?

[00:04:05]
So it's still using the same ZIP container, but it's using a different algorithm to compress the data. The problem is that 80 times slower for compression, not for decompression. So it's more time on your server, not on users' devices, which is not so bad, okay? Anyway, I will go really quickly over this because there is a better one, Brotli.

[00:04:33]
Brotli is a completely new encoding format that replaces completely GZIP, and it can save on text-based files up to 50% of data. So if you compress with Brotli, the amount of data that you are sending is 20% smaller. And if that happens, the file will be on users browsers before and it will help everyone.

[00:05:02]
Today, Brotli is compatible with every browser. But anyway, if a browser is not supporting it, the server typically checks the encoding header and if it works, it will return Brotli. I'm not sure if you remember that before I checked into the headers here. And there was one header, request header, that says Accept-Encoding, gzip, deflate, and br.

[00:05:28]
Br is Brotli. In this case, the browser was telling the server, hey server, I accept Brotli, okay? So then the server can decide to return a Brotli-based file. Brotli, it has the disadvantage of consuming more CPU as well. So most of the time you wanna cache it. That's done by the server.

[00:05:51]
The server typically caches the Brotli file of resource. So it's not compressing the file on every request, okay? And LinkedIn has saved 4% in load time. Facebook savings on CSS and JavaScript files. And yeah, that's a lot because we know that those resources are also the ones that are blocking rendering or blocking parsing.

[00:06:19]
So we wanna get them as soon as possible on users' browsers. So just check that you have that enabled. Again, if you are setting up your own web server, it's something you need to add. It's a module in Apache. It's something you need to enable on IaaS, if you're on the Microsoft side.

[00:06:37]
And if you're using the Cloud, typically, it's a setting that you have to enable, and sometimes it's already enabled if you are starting now, setting up those things. So have in mind, and now we can serve content using Brotli.