Journey of a web page - A mind map !

Ever wondered what happens when you hit enter after typing a url in the browser’s address bar? 🤔

Oh, I wish!😨
The browser BTS does so many things for this to appear so seamless. And understanding those are very important to make our applications highly performant.

Let's understand these one by one -

1. You enter some input

2. Browser parses the input to check if its a url or a search query.
   For search query => it redirects to the search engine.

3. For URL, it -
   
   💡 In the n/w response, we can see vast differences between 14kb and 15kbs response size, but not between 15 and 16 kbs. Knowing which all Kbs are more critical than others can give you a big time TTFB benefit. More details here.

4. Once the response is fetched, it -
   

5. Once renderer process receives the IPC and data stream, it -

   • Starts parsing the HTML received. HTML received is in bytes format.
   • DOM (the data structure browsers use to process html into web pages) - it contains all the nodes of HTML and their relationships.
   • When parser comes across downloading resources(like css, js, assets like fonts, image, video), it sends requests to the network thread in the browser process.
   • Preload scanner is a browser optimisation technique to speeden up this process. It peaks at the tokens generated by parsers and sends requests to the network thread in the browser process.
   • CSS, JS are render blocking resources. They stop html parsing and block page rendering, thus creating more delays and worsening the page load times.
   • 💡 This is why we use techniques like preloads, preconnects, async, defer, splitting CSS into critical and non critical and defer the non critical one etc wherever suitable.

6. Once the DOM is constructed, the main thread parses the CSS to create CSSOM - the data structure similar to DOM, but containing the computed styles for each node in the DOM.
   

7. Now the browser creates an accessibility tree - AOM - semantic version of DOM - to be used by screen readers and other accessibility devices.
   

8. Now to render the page, the browser needs to know the exact positions of the nodes. So, it creates the render/layout tree, containing the coordinates information for the nodes which are to be shown on the page, considering all line breaks, height and width of elements.
   
   🤔 Why do we need it, if we have dom and cssom?
   Because CSS is mighty 💪🏻 It can hide elements from the web page even if they are present in DOM. Vice versa, it can add info(using the pseudo classes), even if they are not present in DOM. It can make the elements float to one side, mask overflow items, and change writing directions.

   • Subsequent calculation of these positions is called reflow.
   • 💡 If for elements like image, we can provide dimensions before loading, reflow can be saved improving the CLS.

9. Next it creates paint records - to add z-index and determine orders in which to paint.

10. Now comes the step where we actually see something on the screen - rasterization - transforming the images created into actual pixels using GPUs.
    To optimise this, the browser creates layers of the page (based on video, canvas, 3d transform, will-change css property). These layers are individually rasterized and then composited to form the actual page.
    

    • The first occurrence of this marks the FCP.
    • Also, the entire time duration from when the DNS lookup started to here, marks our TTI.
    • 💡 When we encounter janky scrolls and animations, we should check reflows and repaints, it must be skipping some frames.

11. It is now that the renderer process sends a message back to the browser process to replace the spinner with reload icon. And all onload events are fired.

This is how eventful and expensive a web page’s journey is. So, be mindful of the renders next time you code an application.