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

The "Optimizing First Load" 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 explains why optimizing the first load has a significant perceived performance gain. The quicker a user sees content, the faster a site feels. One strategy for this is inlining CSS and JS code required for above-the-fold content. HSTS preloading is also discussed in this lesson.

Preview
Close

Transcript from the "Optimizing First Load" Lesson

[00:00:00]
>> Well, hacking performance. So far those are where the basic ideas. I'm are very general, but now we will get deeper into how to hack performance, how to count every millisecond for us, okay? There will be a couple of things that we will see that they are really hacking.

[00:00:19]
And they have a really cost of implementation, so it will be worth the effort on some situations only. There are other techniques that are more okay for most websites and web apps, okay? That's a warning. We're going to start hacking the first load, that is when you get into the website for the first time.

[00:00:43]
So, first, avoid more than one roundtrip. The first one is really hacky. You have the warning. So, avoid more than one roundtrip. What is this? It has to do with TCP, how TCP works. Remember I mentioned before that TCP, the low level protocol that HTTP is using, TCP will split our response in several packets, okay, remember that?

[00:01:17]
And each packet will go through the network, and sometimes. TCP will need to send another one again, because it gets lost, and things like that. But there is a hack that says, what if we try to send a response in only one packet? So the HTTP response, the first one.

[00:01:39]
What's the first one? The HTML the most important one because if the browser doesn't have the HTML, it can't move the loading process, okay? So what if we send only one packet? For that, we need to get into the TCP protocol and learn about something known as slow start.

[00:01:59]
Because what's the size of a packet? We don't know. In fact, it's dynamic. But we know about the first one. The first answer will start slowly. That means that there is something known as initial congestion window. It doesn't matter, it's too technical. But anyway, on Linux or Linux-based servers, if you don't touch that set up, it's 14.6KiB and the next question is, KiB what's that?

[00:02:32]
Well, let me ask you a question. How many bytes in a kilobyte?
>> 1,000.
>> 1,000?
>> Is that 1,024?
>> 1,024? Which one, 1,000, 1,024? It's a very basic question.
>> [LAUGH].
>> And you're giving me weird faces right now.
>> The metric prefects for kilo is 1,000.

[00:03:02]
But 2 to the 10 almost is 1000.
>> So let's say to answer the question. Well, 1KiB is 1024. That's what most people will answer. Actually, when you do a survey, I'm not saying this yet as the final statement saying, I'm saying that typically, a survey between technical people, even developers, 80 percent will respond 1,024, so 1,024.

[00:03:29]
But actually, that's wrong. I know that a lot of you, mostly here on the video, are trying to kill me at this point, but bear with me for a second. Actually, it's 1,000. Because the kilo prefix is 1000 and it's not just me, right? So you can go and ask Cindi that is asking actually, well, from Alpha, that is a scientific say website.

[00:03:57]
You can ask Google how many bytes in a kilobyte. You can ask ChatGPT if you want. I don't have the ChatGPT you think, you can have Wikipedia. It's 1000. Yeah, we were wrong. There is a history of what happened blah, the binary if I were actually that was set.

[00:04:17]
That was set legally and formally within standards in 1998. Okay, so a long time ago, 25 years ago. And we are still not sure about what kilobytes mean. Well, anyway. A kibibyte, not kilobyte kibibyte is a one that still exists for 1024, that's KiB, okay? So KiB means kibibyte.

[00:04:48]
So I'm saying this because you when we're talking about bytes and milliseconds, everything counts. So this is a KiB byte, many black or [LAUGH] maybe bytes, GB bytes. So those are the ones that are using powers of two and then the other ones legally, technically, are actually using, 1000.

[00:05:14]
The main responsible of the confusion today is Windows because Windows is not following this. Linux and the waves based in units is usually base one so the idea is it's KAB or it's KiB 1000. But Windows is using KiB for 1024. So he's not following the spec, the standards, the industry.

[00:05:43]
Anyway, going back, we were saying that 1KiB, 1 kibibyte is 1024 bytes. So going back to this idea, we were saying that on Linux. 14.6 KiB is the initial congestion window, which means if you can fit within 14.6 KiB, the HTML, it won't be split into more than one TCP packet.

[00:06:12]
So it will arrive to the client as soon as possible. Because we don't need to send more than one packet, wait for them, reorder them. See if it's there or not, blah. Thinking you have 14, yeah, it's not so good but remember that it's HTML and we are shipping the HTML.

[00:06:31]
So that's roughly 70K of HTML, which sounds better than 14. This is very hacky, okay. I know it's very hacky. And also, when we are doing with performance, typically we say now that we have something known as above the fall, ATF. And something known as below the fall BTF.

[00:06:56]
Some people deeply ask the fold, are we talking about foldables? Well, actually that these terms are coming from printed newspapers. Okay, so the idea when you are paying for an ad in a newspaper, you have above the fold, this is the fold. Above the fold below the fold below the fold is cheaper than putting an owl above the fold.

[00:07:18]
Okay, so that's we are using those terms here as well. On the web of course, we don't have a phone even if you have a foldable device. We're talking about the scroll actually, so above default is the first scroll, okay? Everything that goes below what you see without scrolling, that's below default.

[00:07:38]
So when we're talking about 14.6 KiB bytes, maybe we don't need to serve the whole HTML. We can serve just above default. Because what we need is to achieve user's perception of performance, that that is, for example, largest contentful pane, remember? So if you achieve that, then maybe we can fit in 70K of HTML the code necessary to render the above default.

[00:08:10]
So what can you add that there? If you can embed CSS and JavaScript much better. And if there is a space, you can even embed the logo in SVG. Everything that you can fit within 70K. We worth the effort who is going to use this technique today this technique is being used a lot on some special regions of the world.

[00:08:36]
Africa some countries in South Asia where they have a really performance penalty for example they have 30% of users on 2G. We have a really, big latency problem there. So we don't want to have a lot of TCP packets, okay? Make sense? In fact, I'm not saying that they're using this technique today.

[00:08:59]
They used to use that. Google.com, the mobile version you should have some of this technique in action. So if I enable the mobile user agent, so I simulate, Galaxy, the mobile version, let's see now, because I don't know what's going on, but yes, they have CSS, inline. So it's not an external file.

[00:09:24]
Can you see that CSS there? In fact, let's see the source code like so. We have JavaScript. That's JavaScript. Let me increase the font size JavaScript. That's more JavaScript. We need to have CSS somewhere. And sometimes, I'm not sure right now if I'm going to find it. Yeah, I have sometimes images, everything embedded in the HTML why?

[00:09:54]
To avoid more TCP rounds. So avoid more HTTP requests. So then the content can be as fast as possible, really fast. It's really hacky, yes, it is.
>> So that's all become like that in that file during whatever your build is for whatever your.
>> Yeah, you can have a build process, your development process.

[00:10:14]
It can be server-side rendering as well that is merging all these files into just one.
>> kinda like tailwind I guess.
>> Yeah but if you can fit this in 1406 compressed then everything was reading one TCP packet. Okay, hacky yeah but yeah we're hacking by performance, right, [COUGH] this one is interesting.

[00:10:37]
You should avoid http to httpS resurrect. Fortunately for us, this is being replaced on many browsers. So, here is a view what happens when you type a URL, right? You see an ad on TV, okay? Buyme.com. So, you go and type buyme.com. You don't type https:, you just type buyme.com.

[00:10:58]
So easy trying http or httpS. Typically originally it was http and then the server was saying no we have we have a redirect to httpS. So for that for a long time browsers were using something known as HSTS HTTP is Strict Transport Security, which is just a header that you can add in your website and you can opt in within that URL.

[00:11:28]
Let me explain what that is [COUGH]. When you go to that website, hstspreload and you have a website, You can add a URL. Let's add, I don't know, New York times.com. Let's check. And it says now it's not supporting the standard so it's not supporting it, maybe CNN.

[00:11:53]
Now you can see there are a lot of websites that are still not using this technique was the google.com no say what's going on well what's this it saying that you don't have the header. And what's the deal with this is just this header that you need to have when you're responding with Eurasia man that header will say to the browser hey browser what here in this website, we always support HTTPS on every URL.

[00:12:22]
So it's safe from now on to always go to HTTPS first. That's HSTS. So in that case when your user is typing your URL it will go directly to HTTPS. It's avoiding one redirect. Does it make sense? And if you log in your website here, whitehouse.gov. I don't want to try gov.

[00:12:51]
That's green. So white house. It's actually preloaded. That means if you try whitehub.gov in your browsers without the protocol, it will go directly to HTTPS.
>> How many milliseconds does that save?
>> That's going to save one TCP connection, and it can be around 150-200 milliseconds. Which is, again, 5% of our budget, so it's not bad.

[00:13:23]
So again, what do you need to do? You need to set up this in your server. It's a header. And of course, for that, every URL in your domain must be served with HTTPS. And today there are a couple of domains that you can buy, such as .app.

[00:13:39]
Have you seen the .app? .app or .web? And those domains are HSTS by default, actually, you cannot serve HTTP over those domains you cannot. Is it gonna work?
>> Do you need a certificate or anything like that?
>> You need the same certificate as https so you don't need a special certificate.

[00:14:07]
You need to send the header and then add your domain in this website And you will get into a wide list, that's the name, and allow list that then you can remove if you want. Several browsers, Firefox and Chrome are using the list from this website. It's kind of a standard.

[00:14:29]
Anyway some browsers today are changing the algorithm and they're trying HTTPS first and only if it's returning an error it's going to HTTP. Fortunately they're changing the algorithm.

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