Using a browser to consume content is something most of us do everyday. Heck, you’re doing it right now. Recently though, I was humbled by the realization that for something I do so often, I only had a vague idea of what was happening “under the hood”. But rather than stew in my own shame and self-loathing, I decided to dive in to gain a better grasp on the complete end-to-end process, or life cycle, of a browser. While I won’t be tackling the complete complexity and hundreds of components that make up a browser, hopefully this quick guide will give you a better understanding of what’s happening the next time you navigate to a website.
- Protocol: the (network) method of access to the resource.
- Domain: the address where the resources can be accessed, these are often used in place of an IP address because they’re easier to remember.
- Path: a more precise location for accessing specific resources.
- Query string: where parameters and values are stored.
- Fragment: an internal page reference, commonly referred to as an anchor.
Once you’ve entered a URL into the address bar and struck the enter key the browser gets to work!
The Power of DNS
Pretty straight forward, right? Efficient? Not really. As you can imagine it takes time to communicate with root servers, and for data, like domain/IP mapping, that doesn’t change often so it makes sense to cache this kind of information. That’s not to say that a DNS lookup takes a long time, but it’s faster to check cache.
DNS information can be cached at four levels:
- Browser Cache
- Operating System (OS)
- CacheRouter Cache
- Internet Service Provider (ISP) Cache
The browser will start by searching its own cache. If that doesn’t exist then the cache stored by the OS will be checked. In fact, this process of checking will continue using the router then the ISP.
If the information cannot be found at any of the cache levels then a search will be conducted using the root servers previously mentioned.
Note: While HTTP isn’t the only type of request browsers support, it is a very common activity that will provide a good foundation of knowledge to expand in subsequent blog posts.
3.) Having successfully established a connection with the server, the client prepares and sends an HTTP request header that includes information like the HTTP method, path, cookies, and a variety of other details.
Sample request header
Sample (HTML) response header
Steps 5 and 6 show how the process can be repeated on an established connection. It’s important to point out that establishing a new connection can be a time-consuming process and crucial to re-use already opened connections as much as possible.
When a response from the server has been received the content is then handed off to the layout/rendering engine of the browser. There are a variety of rendering engines but they are all tasked with the same mission; to display information on the screen. While there is certainly more to unpack (see what I did there?) when it comes to the browser rendering from a workflow perspective, that’s it! The complete, high level, journey of requesting information from a web server. Keep an eye out for future write-ups where I’ll be diving deeper into the details of other types of requests (e.g. HTTPS), how browser layout engines work, and more!