Web App Performance

Browsing the Web

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
Web App Performance

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

The "Browsing the Web" 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 the entire data roundtrip from when a user enters a domain name in the browser to the content rendered on the screen. Understanding all the steps in a network request helps identify where performance bottlenecks can arise.


Transcript from the "Browsing the Web" Lesson

>> Now that we have that, let's go back to the slides, and let's understand the browser, how the browser works. I'm not going to get too deep here, but enough to understand where performance solutions, or tips and hacks. So why we are going to do some things. So what happens when we browse the web?

So we need to talk about the network layer, quickly. We're not going to get too deep into the fundamentals of networking, but at least, basic enough to understand what's going on. The parsing part when the browser is parsing the HTML, the resource discovery phase, where in this case, the browser is discovering other assets, other resources that are needed to render the page, JPEG files, JavaScript files, style sheet.

Then, the way that the browser has to prioritize elements for it needs to download 10 assets, which one should download first? Well, there is a process for that. And then, layout and paint and we won't get too deep into layout and paint that has to do with how the browser works with the GPU and measuring stuff, and things like that.

I need to get out of the slides and make a quick text file we're going to do this in a simple, easy way. So when you type www.frontendmasters.com, what's going on? Let's say it's the first time, it's the first time you're going to that website. The first step, and I'm talking about the network layer, is a DNS query.

Actually, your browser needs the IP address of the web server for front-end master. That's using a TCP connection, so you need to connect to your own DNS server that goes to check into another DNS server. There is a process there, I'm not going to get too deep here.

But that DNS query might take, without taking latency in consideration, might take 100 milliseconds. So in average, it can be more, it can be less. So 100 milliseconds without latency, so if you are in 3G, we need to have the latency, remember the latency. So when we have the IP address, we need to make a TCP connection.

Actually, we're going to start the HTTP connection. Okay, but it started the TCP connection that I'm not sure if you have experience working with the network, but there are at least, three messages that we need to send and receive from the client to the server that goes, right?

So that might take another 100, 120 milliseconds. We still didn't get any HTML, actually we didn't request yet, the HTML, we are just opening the connections. And now, we are working with TLS, what's TLS, SSL, HTTPS? So we know that today we are all going to HTTPS, right? Do you know why?

Why every website today should be HTTPS and not HTTP anymore?
>> It's encrypted by default.
>> It's encrypted by default.
>> Yeah.
>> But it was encrypted by default in the 90s as well, and we didn't push every website to be HTTPS. Is that because we didn't care about security there?

Then, so does it make sense? So the question is, yeah, it's more secure, okay, cool. But the same thing happened in the early 2000, even 10 years ago. Why is that we weren't actually pushing every website into HTTPS as today? Is today's security more important? You may say, yeah, but we have more bad actors, maybe.

But that's not actually, that's excuse, not the real reason of why we're doing this.
>> HTTPS allows for HTTP/2?
>> HTTPS allows for HTTP/2, but that's a consequence, not a cause, so the question is still there. So why HTTP/2? In fact, let me tell you this, HTTP/2, the second version of the HTTP language that we will see in a minute.

The spec doesn't require HTTPS, but all the implementation from the browser's require HTTPS. So it's not really a requirement from a spec point of view, from a protocol point of view. So what's going on? So I was simplify this really quickly, but let's take HTTP/2 as an example, and this has to do with a lot of research made by Google.

Google realized that there are a lot of actors in the current backbone of the web, that are not following the HTTP protocol rules. Example, let's say we create today HTTP/14, okay? So HTTP/14 means it's a TCP request that in the header, somewhere, it says HTTP/14. Well, the spec says, if you're making a proxy, a router, so you're making a device that receives a packet and sends the packet somewhere else.

When you receive the packet, if you wanna open, let's say you wanna open that, and you see a protocol that you don't know, the rule is to just forward the packet. You are not responsible for making a decision, but there are a lot of routers out there that says, no, HTTP/14, no, that's probably wrong.

So let's discard the packet, I'm simplifying this, but just to give you an idea. So with that in mind, we had a problem. To evolve the protocols, we need to change those routers and we don't know who owns them, where they are. They probably has written 15 years ago based on Google research on some countries.

Let's say China, there are a good amount of routers doing that. So we realized that to improve the web's protocols, we need a way to bypass that without changing those routers, and the way to do that is to encapsulate those packets into something that the router cannot read, and that's HTTPS.

So HTTPS, because it's encrypted, any proxy in the middle cannot actually open the package and see what's inside, and they just forward, the packet. So that's the reason why we are pushing this harder, or we have been pushing this harder in the past six years. Not because of security, yeah, we have a nice thing saying, hey, this is more secure, but it was before as well.

But that's why browsers today, if you're in a website that is not secure, will give you a warning. Hey, this is still in HTTP, we have a problem, you don't send any form. Yeah, that's a security thing, but there is another problem behind, and it was performance because we couldn't move the protocols further if we left them as they were, okay?

Does it make sense? So that's actually the reason why we need HTTPS. And why not every website 10 years ago were HTTPS? You know one reason? There is one big reason of why. 10 years ago, only 5% of the websites were HTTPS. Changing protocols is hard?
>> No, because you're not actually changing protocol, you're just adding something on your web server.

What's that something? A certificate.
>> Certificate.
>> And that certificate was expensive. Originally, I remember in the 90s, my first HTTPS certificate that I bought for a customer, it was if I remember correctly $950 per year. So yeah, when I do that, yeah, maybe 10 years ago, that was better.

We had other companies offering also certificates, maybe you can get one by $30 per year, but still it's something you need to pay. But because that was a problem and we all wanted to push HTTPS, that's why there was a new organization that you probably know, it's called let's encrypt, it's a nonprofit organization created by the browsers and other companies to push HTTPS, those are the founders and sponsor chip.

They wanna push HTTPS so they provide you with a free SSL certificate that wasn't possible before. Now, that was a parenthesis to understand why we need to move to HTTPS. Anyway, because we need to move to HTTPS, let's go back here. We also need to make a process to negotiate public keys and private keys.

That might also take 150, and it depends on your servers. So far, we haven't even request the file, that's the next step, an HTTP request. That is to, hey, I'm the browser, now we are securely connected. I have your IP address, I have a TCP connection open with you, now I'm gonna request a document, like your default document in the route the index html.

So what's the problem with that? So far, we have spent without taking latency in consideration, we have spent how much? 350, almost 400 milliseconds. For our Largest contentful paint, we have a budget of 2.5 seconds, so yeah, that's a lot, we're taking a lot from our budget, 10%.

We have just wasted, invested 10% of our budget just in the network layer. So now that you understand that we have a budget, there is a limited budget as any budget, how important is just 100 milliseconds because sometimes, you say well, 100 minute segments. Yeah, but now we are adding more handy 150, 100 from here, from there, from there a way to reach our goal.

The user should see the largest contentful paint within 2.5 seconds, and this is without taking cellular network latencies in consideration. If you are on a 4G network or a 3G network, you may add 80 milliseconds on each of those requests. Okay, makes sense? Well, what else? We made the request and then the server has to process, that is what is known as the backend time.

If you are just requesting a static HTML, that's easy. The server just goes to the file system, gets the file and gives you the file. But anyway, that might take 200 milliseconds. If you have a server side library, PHP, Java, node.js, next.js, well, that may take 500, 600 just to get the final HTML that we are still using from our budget.

When the server is ready and he has the string or the bytes that it wants to send, it creates an HTTP esponse that goes over the downloading. In fact, we didn't mention this but this is using the uplink of your connection, and this is your downlink. You know that when you have a network connection, you have an uplink and a downlink connection.

Typically, the uplink is slower in terms of bandwidth, it has less bandwidth, okay? So that's another thing to have in mind, so then, the HTTP response appears and then the browser, it starts the HTML parsing, the document parsing. So it start reading the HTML, we have a tag, a head tag, we have a title tag, and it's creating the DOM on the fly.

And while it's finding some other resources, it's creating that idea of it's, we've mentioned here is the discovery phase. So it's a resource discovery, so it's discovering resources. I need CSS, I need a web font, I need an icon, I need a PNG. Okay, and it's creating a table, and on that table, it's also adding a priority, it's setting a priority for each resource, okay?

And after that, at one point, the browser decided to render. That inside, it has more steps such as layout and paint that we won't get too deep today. But that means that a lot is happening here, and when we understand what's going on, we can make better decisions on what to do and how.

Remember, my goal is for you to feel bad today about how you're doing things and you need to feel the pain that is here to get. We have a very limited budget and we need to achieve the goal that in our website, we are not achieving because when I'm, let me close this, when we are here, let me see if this lighthouse is still there.

Yeah, we are not achieving largest contentful paint in 2.5 seconds. In fact, it says 7.5 seconds, so this is pretty bad even with a simple website. Yeah, I pushed a couple of weird things in that code on purpose that we will see in a minute, but that's the goal, okay?

Once we understand the process, we can make things better.

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