How does a web browser work?

In a previous article, I attempted to explain the principle of a web server and the features that characterize it, in an attempt to demystify how it works.

Today I'm going to do the same thing with a web browser, in a technical way, while trying not to go into too much detail so as to keep the general concept in view.

In reality, some modern browsers may work slightly differently, so we're going to imagine dissecting the workings of a basic browser, like in the 2000s!

Theory

We could start from the assumption that the most basic web browser possible only has two functions:

• Sending HTTP requests
• Displaying a graphical rendering of the HTML content returned by the web server

In principle, a piece of software that implemented these two methods could be described as a web browser without any issue. However, given the current state of the web and users' expectations, this theoretical model would no longer be sufficient to do the job today.

That said, it would still be sufficient to display the very first web page ever created by Tim Berners-Lee at CERN in 1985, which is still online!

Practice

Creation of a system process

When the browser starts, it automatically loads a new blank tab. A tab isn't only useful for users; it's also useful for the browser's technical operation.

When a tab is created, the browser actually creates a new independent (child) system process, which allows two things:

• The browser and the tabs can continue to communicate, but two tabs cannot (in theory) communicate with each other, which promotes security.
• If one of the tabs consumes too much memory and has to stop, then only that particular tab can be terminated, and there's no need to close the entire browser

DNS resolution

Once the tab is created, an address bar is made available to the user, which must contain a valid URL for the user to be able to load a site.

The URL in question can be based on:

• A domain name
• An IP address

If the user enters a domain name, the browser will have to fetch the IP address pointing to it before it can start loading the page via an HTTP request.

Since the HTTP protocol is based on the TCP/IP suite, an IP address is necessarily required so that the network can transport (route) the TCP packets.

If you're not familiar with the TCP/IP protocol suite, I invite you to read my article dedicated to it.

To retrieve the IP address, the browser will perform a DNS request (Domain Name Server, also called "domain name system"), whose sole purpose is to match a name to an IP.

DNS requests are very frequent, which is why they are subject to several levels of caching:

• First, the browser will check its internal cache to see whether it already has the domain name <> IP mapping present (and not expired)
• If not, the operating system will check its cache
• If not, the DNS request will go out onto the network and pass through a number of recursive DNS servers (which will check their respective caches, and forward the request to another DNS server if needed)

And this continues until the corresponding IP address is found, which will be returned in response to the request.

Initial HTTP request

Once the IP address corresponding to the domain name has been received, the browser can finally send an HTTP request to ask for the site's home page.

When the user wants to access the site:

google.com

The browser will therefore retrieve the IP address:

142.250.178.142

And build up the URL by adding the protocol (http://), the default port (80), and the default URI (/index.html)

http://142.250.178.142:80/index.html

The final HTTP request will therefore be as follows:

[HTTP/1.1] [GET] [142.250.178.142:80] [/index.html]

In reality, the HTTP request is indeed made with the domain name and the IP is contained in the underlying TCP packet, but the example above is more visual.

Note that I'm not covering the concepts of HTTPS and SSL here, in order to keep the article as accessible as possible.

Interpreting the HTTP response

The HTTP response contains three main elements:

• The status code
• The response header
• The response body

The status code lets you know whether the request went well.

A 200 code means that the requested resource is indeed present and can be processed. A 301 code tells the browser that it needs to send its request to another URL. A 404 code indicates that the requested resource does not exist.

If you want to learn more about HTTP codes, I invite you to read my article on the subject.

HTTP header: Storing cookies

If the HTTP response does not contain a redirect, then the data contained in the header can be processed, including cookies.

Cookies are data sent by the server that the browser must store locally and send back with every request to the server. Each cookie is stored for a particular domain and for a limited time.

These cookies are used to track the user as they navigate the site, or to offer them features that require authentication.

HTTP body: Processing

Logically, when the request has gone through correctly, the server will have returned a web page contained in the body of the HTTP response, but this web page is then in the form of a string of characters that needs to be processed.

The browser, using all the data present in the response, then has to turn this string of characters into a valid HTML document, based on the document type indicated in the first element present, called <!DOCTYPE>

confirms that the received document is indeed an HTML document, and it also indicates the version of the language to use (HTML5 by default)

The resulting DOM (Document Object Modeling) tree from this processing will then consist of 2 higher-level elements, and .

All the metadata present in the is processed first, before that of the , which is why scripts loaded during this part cannot yet access the body of the page, since it doesn't exist yet.

This is generally when part of the CSS styles are loaded, so that the content generated in the body of the page is already styled by the time it's loaded.

Once the body of the document is loaded, it goes through the browser's rendering engine so that it can be presented to the user.

Loading the page's dependencies

For each call to an external dependency (image, style sheet, script, etc.), the browser will make a new HTTP call, and each dependency will be injected (and possibly executed) into the HTML document.

It's once these calls are complete that the page load is considered "finished", but you never know if a script might dynamically inject a new dependency to fetch!

Cache management

Interpretation, execution, and compilation of scripts

In addition to the rendering engine, every browser has a JavaScript engine that will:

• fetch each script (as text)
• pass it through a syntax parser to turn it into executable code
• Execute each script
• Analyze the execution of these scripts in order to add JIT compilation (Just In Time)

For more details on how Just In Time compilation works, I recommend reading this article (in English).

And there's more

I haven't talked about the parsing and execution of CSS and its animations, the page rendering refresh cycle (repaint), and many other things, but the idea here was to give you an overview of how a web browser works.