What happens when you click a link in the browser?

Tara Ojo
3 min readJul 7, 2017

I was recently asked this question in an interview and in sheer panic I realised I didn’t have a clue. Not just about this specific question but also about how the web works in general. I’ve managed to get away without knowing for the last few years because, to be honest, I didn’t have to.

In the crazy world of programming, there is always something new to be learned, it’s just knowing where to start. I once heard a person at a conference say “Learn what you need, when you need it”. Well, now I need it. I’ve scoured the web for resources, some more boring than the other, but I’ve managed to get some basic understanding of how browsers work and I’ve put it together in this sketch-note type thing:

So, in simple English, when you want to go to a website, you type it into a browser, or click a link in Google. The process that follows is called DNS lookup. Basically each web address that makes sense to us (i.e. www.google.com), is mapped to an IP address that makes sense to your computer, in Google’s case, that’s 8.8.4.4.

So, DNS lookup = www.google.com → 8.8.4.4

Simple. Well, not simple, this process is actually a lot more complicated, I didn’t get too much into the nitty gritty when I researching it, but I found a great video on YouTube that explained it amazingly.

Now we have the IP address of the website we want to go to, we can start making requests. We need to make requests for the files that allow the browser to display the page you want to see. This could include HTML files, CSS, JavaScript, images, videos, loads of different things.

When your browser sends a request, it includes a number of headers. Headers are just information to let the server know what you need. In the case of rendering a web page, the request is usually a GET request, the other common one would be POST. Then you wait for a response…

If there is an issue with the address you are requesting, in my example the address isn’t quite right, you can get a number of different negative responses. In the response header you can get some information about what went wrong, especially in the response status. You’ve probably seen some of these before, like 404 Not found or 500 Server error 0r, back to my example again, 301 Moved permanently. The 301 status triggers a redirect which in essence goes through the request process again with a new address. Instead of http://google.com, it’s going to http://www.google.com.

Now this is the right address, the server needs to decide what request handler to use, is it a Ruby application? Or maybe it’s in PHP? When the server figures this out it’s ready to send the page content back in the response.

Everything works so we get a 200 OK response status. Great! The browser can now start rendering the page we want to see. Rendering another complex process, that I haven’t really gone into, although there is a great and detailed article on HTML5 Rocks.

As it renders, the browser comes across a number of other assets required to complete the page. This could be images, CSS files or JS files. The browser doesn’t get all of this in the original request, so now it needs to send out more requests for each individual asset it needs. As the browser starts to get responses it can continue rendering the page.

When all the responses are back in the browser finishes rendering the page. Hopefully it managed to find everything, otherwise you’ll see some weird things start happening. Missing images or even content that isn’t styled, in my example, I’m completely ignoring that scenario!

So that’s it! 🎉

Obviously, this is the bare minimum of how browsers and the web works, but I reckon it’s a good starting point to build upon. I just won’t know what to learn next until I realise I need to learn it. 😄

Find me on Twitter for more tech musings 😁

--

--

Tara Ojo

Software engineer @ Google. She speaks and writes about career progression and front-end development. @tara_ojo