How does browser page lifecycle sequence work?

What you are talking about is the Critical Rendering Path.

The point 1., 3. and 4. can be resumed as such:

  1. Construction of Document Object Model(DOM)
  2. Construction of CSS object model(CSSOM)
  3. Construction of Render Tree
  4. Layout
  5. Paint.

Here is a break down of what happens behind the scene.

1. Constructing the DOM object.

The first step is creating the DOM. Indeed what you receive from the network are bytes and the browser use the so called DOM tree. Therefor it needs to convert those bytes into the DOM tree.

enter image description here

  1. You receive the page as bytes. Your browser converts it to text.
  2. Text is converted to nodes.
  3. nodes are converted to “objects”
  4. Construction of the tree, called the DOM TREE.

You can check the developer tool to see how much time it takes.

enter image description here

Here we can see it took 4.938ms.

When this process is finished the browser will have the full content of the page, but to be able to render the browser has to wait for the CSS Object Model, also known as CSSOM event, which will tell the browser how the elements should look like when rendered.

2. Handling the CSS

For the css it’s the same as above, the browser needs to convert those file into the CSSOM:

enter image description here

The css is also a tree structure. Indeed if you put a font-size to the parent element then the children will inherit it.

enter image description here

That’s called recalculate style in the developer tool

enter image description here

CSS is one of the most important elements of the critical rendering path, because the browser blocks page rendering until it receives and processes all the css files in your page, CSS is render blocking

3. Render tree

CSSOM AND DOM are combined for display.

enter image description here

4. Layout

Everything has to be calculated in pixels. So when you say an element has a width of 50%, the browser behind the scene transform that in pixels:

enter image description here

Every time an update to the render tree is made, or the size of the viewport changes, the browser has to run layout again.


The step is converting all this into pixels on screen. This is the paint step.


For the JavaScript lifecycle you can find info here.

The gist of it is that the event you most likely care about is DOMContentLoaded. This is when the DOM is ready.

When the browser initially loads HTML and comes across a
<script>...</script> in the text, it can’t continue building DOM. It
must execute the script right now. So DOM Content Loaded may only happen
after all such scripts are executed.

External scripts (with src) also put DOM building to pause while the
script is loading and executing. So DOM Content Loaded waits for
external scripts as well.

The only exception are external scripts with async and defer
attributes. They tell the browser to continue processing without
waiting for the scripts. So the user can see the page before scripts
finish loading, good for performance.

Beside that, where is JavaScript in all this ?

Well it’s being executed between the repaints. However it is blocking. The browser will wait for JavaScript to be done before repainting the page. That means that if you want your page to have good response (lots of fps), then the JS has to be relatively inexpensive.


When receiving an HTTP request, a server can send a Set-Cookie header with the response. The cookie is usually stored by the browser and, afterwards, the cookie value is sent along with every request made to the same server as the content of a Cookie HTTP header. Additionally, an expiration delay can be specified as well as restrictions to a specific domain and path, limiting how long and to which site the cookie is sent to.

For the networking stuff, this is beyond the scope of browser lifecycle, which your question is about. This is also something I’m not well versed in but you can read about TCP here . What you might be interested in is the handshake.


Leave a Comment