Web App Performance

GZIP, Cookies, & Redirects

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
Web App Performance

Check out a free preview of the full Web App Performance course

The "GZIP, Cookies, & Redirects" Lesson is part of the full, Web App Performance course featured in this preview video. Here's what you'd learn in this lesson:

Max covers some basic server-related performance techniques that developers should verify are in place. Checking response headers for text-based files will indicate GZIP is enabled. Leveraging cookieless domains and reducing redirects will also increase performance.


Transcript from the "GZIP, Cookies, & Redirects" Lesson

>> Now we finally start talking about, now that we understand, how if everything work, how important performance is, it's time to start optimizing performance. So first, basic things that you have to check. We need to enable as GZIP on text-based files, this is typically happening everywhere. But if you are setting up your server yourself and you're not using a cloud-based service like GitHub or, I don't know, Vercel or something like that, maybe you have to check how it's set up.

I'm pretty sure that for HTML, CSS, and JavaScript, you are serving those with Zip. But what about SVG? What about APIs and JSON? Because that's text also, you don't wanna compress JPEG files to font files, no, just text-based files, okay? This is very basic, okay, it is from the beginning of web performance.

But just have in mind that you are doing, how do you know if your server is doing that? Well, Lighthouse, the tool that will give you the score, will give you a hint, but if not, you can just click on any text-based file here and check the headers.

In the response headers you can check if it's compressed or not, and also you will see in the request that the browser is accepting GZIP, deflate, and we don't know what that is, I will explain what that is later, okay? So that's how you check if it's compressed or not, and you can also see that on the main HTML file, okay?

So looking at the headers, you can detect that. We have already mentioned this, make static content expire late in the future. I know it sounds scary, but for those of you that are creating React applications, Angular applications, you're already doing this. I'm not sure if you know that, but if you have your app.js, your bundle.js that the output of your react application typically has a hash, have you seen that?

It's not app.js, it's app.059D8.js, why? Because every time you change the build process, there is something new in the build, you change the hash. And why it's doing that? The idea is to make all that files expire late in the future, because if you change a bit, you know it's going to be a different file name, a different URL.

Use a CDN for a static content. This is all, but the CDN will actually get closer to the user. So the CDNs, they have mirrors all over the world. So then it will serve your content closer to the user. So the latencies will be shorter and that will lead to better experience.

You can see that so far, these are not yet things that have to do with frontend. It's more about the server and yeah, there are a couple of, the first thing that we are seeing are more related to the network layer, to infrastructure, to settings in your servers.

Well, consider moving to HTTP/2. You must move to HTTP/2, we know that. Cookie-less domain, do you know how cookies work? They are being stored in local storage, yes. What else? First, are cookies client side or server side?
>> They live on the client and tell the server's status about the client's browser?

>> Correct, so they live on the client, but both the client and the server have access to them, how? How does the server knows what you have on the client?
>> You have to send it there.
>> You have to send it, how? Who is you?
>> I mean, the browser sends-

>> Browser or the developer?
>> The browser.
>> The browser, the browser sends cookies to the server on every request. On every request, it sends all the cookies. So for example, if you have cookies storing 2K of data and then you have a website with 50 assets, you will send 50 times over the uplink, 2K.

100K of data that you are sending on every request, even if you're not using that cookie on the server. So using cookie-less domains means that for your assets, it may be a good idea sometimes to create another domain, maybe can be also CDN that will give you a different domain, and that again will be cookie-less, so the cookie won't travel to the server.

Does it make sense?
>> Can you set up the cookies so that there are some that don't always send to the server as well?
>> Cookies by default are sent per origin. So every request, you can set an expiration date, so it can expire, but you cannot say, I want cookies per, so only for that HTML.

No, it's per origin. So all the origin will get all the cookies. Anyway, cookies are maybe getting away in the future. So they have problems everywhere, so try not to use cookies. But anyway, have that in mind. Even if you have cookies, try to reduce cookie size. For example, this is delta time.

If your cookie is 3k, it might add on HTTP/1.1, or HTTP/2 it's a little better because it's compressed. Remember, the cookie goes in the header. And HTTP/2 is compressing headers. On HTTP/1.1 it was adding 78 milliseconds per request, per request, okay? This one is interesting, reduce redirects. So a redirect is a stop sign, okay?

And for those of you in different countries, I'm using the definition of a stop sign of US, Canada and Europe. Because there are many countries where the stop sign is mostly a suggestion for slow down, okay? No one actually stops them. In Argentina, we don't stop. There is a stop sign, but actually, you don't stop.

It's more a warning, be careful, than a stop. Anyway, so the stop sign here is the one where you actually stop, see, both ways, and restart, okay? When you have a redirect, that's what's going on. What's a redirect? You go to a website, and the website says, you know what, it's not here, it's there.

Go there. So remember that all the process that we mentioned that we have when we are browsing the web, When you make a redirect, at one point, actually here, the browser says, no, it's not here, we need to go somewhere else. So we just start again from 1 to 7.

And there are situations where this can be really complicated. I remember one airline, I'm not gonna say which airline, let's say aa.com, just a generic airline, that they were doing this. You are on a mobile device, you are going to aa.com and they were saying, you're on an iPhone or an Android.

You need to go to mobile.aa.com. Then when you get there, when your browser gets there, they will say, no, it's mobile.aa.com/default. And then it's mobile.aa.com/Page.aspx, something like that, but probably slash default actually. And then you say, but no, you have an iPhone, right? No, we have a special version for iPhone that is just for iPhone.

So it's iPhone dot blah, blah, blah. And the problem is that every redirect, it's a stop sign and we start again. We stop, we start again. And the user is seeing nothing in the meantime. Make sense? So we should avoid redirects, and sometimes you have redirects that you don't realize.

For example, if I type frontendmasters.com, maybe redirects should www.frontendmasters.com, that's a redirect. www dot is another DNS query. So we also have a DNS query that was taking 150 milliseconds. So then you have 150 milliseconds of, let's say 100 of DNS. Then 150 of TCP. Then, let's say, if I simplify it, 150 for SSL.

And then the HTTP request. Finally to realize that it wasn't there, so I need to start again. And we haven't seen a pixel yet. So we need to avoid redirects as much as possible. And the redirect look like this. The redirect is pushing all your diagram to the right, and with that, all the metrics.

Does it make sense? So each redirect will consume between 100 milliseconds and 1 second. It depends on the latency and it depends on if you're redirecting to the same origine or if it's a different domain, a different origin. So there is a lot of possible differences there, but it's really, really expensive.

And also social networks will typically use one, such as bit.ly, t.to, when you are publishing on Twitter, so that's a redirect. You don't manage that, but you know that there will be one redirect, where at least don't add more on your own side. Typically, there is a question, but I need to go to another server because I first detect the language and the country based on the country well do that server side.

Don't send that navigation path to the client. Find a way to do everything within your boundaries, and then just answer with the HTML the user wants. Don't send HTTP redirects, they're really, really expensive.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now