Web Dev Part 4: Back To The Browser

Welcome to part 4 of a multi-series post. If you did not read the last entry, you could find it here. For a quick recap:

In Part 1, We Covered:

• How elements are displayed on the page
• The way a page gets its look and feel
• How a page becomes searchable by bots
• The way a page gets its functionality to perform tasks

In Part 2, We Covered:

• How your browser finds the real address of a website
• How your browser requests a website
• The journey of a request from your browser to its destination

In Part 3, We Covered:

• How backend systems can handle millions of requests
• Why an app needs many clones of themselves to scale
• What is a Load Balancer

Continuing from where we left off, the request has made it way back to your browser, and now it’s time for your browser to read and make sense of the data sent back. Like a human reading a document, your browser will start at the top and read its way down, line by line. As it read each line, it will render to the screen what is written in your document. Note that your document may not just be filled with content tags, such as Heading, <h1>, and paragraph text, <p>. There may be images or links to a CSS file or Javascript file. 

As we explained in part 1, these are the essential building blocks of every document. As the browser reads down your document and encounters one of these: images, CSS, or javascript files, it will pause the printing of the document to the screen and request that file. Once that extra file is downloaded, the browser will resume rendering the original document.

<link rel="stylesheet" href="/css/dist/block-library/style.min.css">
<h1> Hi there </h1>

If the above document were returned to you, your browser would not show you “Hi There” until the style.min.css file was downloaded. If large files are included like this, it can be a poor user experience as they will have to wait for all files to be downloaded. There is a way to tell the browser to keep printing the document and download the included files in the background by using an async attribute. This can have other side effects, so it needs to be used with caution. 

Once the browser is finished printing and downloading all the files written in the document, you can interact with the page. This generally happens within milliseconds to seconds, so the amount of work the browser does goes unnoticed. On any given page, the original document could request countless images and files that your browser can download and interpret to understand how to handle how the page looks and works. At this point, the browser downloads tracking scripts that keep track of who you are and what you’re looking at. The site can then capture this information and relay it to other companies for advertisements.

Now let’s say you start scrolling down the page after being loaded and see a link or a post. After you go to click it, the same request cycle is undergone by the browser. The browser will request the page from Facebook’s server. Then when that data comes back, the browser will print it to your screen. In web development today, there is something known as a SPA, a single page application. The above explanations hold true for SPAs when you initially load the page, but as you navigate to a new page, it’s slightly different. I won’t be going too deep in this post about SPAs, but if you want to know more, check out our post on Single Page Applications.

Thank you for reading this intro to Web Development Architecture, and if you have any questions or want us to go deeper into an area, please let us know in the comments below. As always, please subscribe if you want to stay up to date with our latest post and projects.