How does browser page lifecycle sequence work?

Question

Would like to create a presentation on how the browser work, does anybody know the exact lifecycle sequence which happen whenever a browser URL is requested?

What are the steps which happen after a response is received from the server in terms of :

1. Rendering - CSS filters application, webkit etc...
2. Javascript - Loading and running
3. CSS Application
4. DOM Construction / at which point is the DOM written and how?
5. Cookies
6. Other network related activities etc.

-- not quiet sure if this is even the right order...

is it the same in all browsers or different browsers have different lifecycles?

Note - a well written answer with details explaining each step by Ced below. what I was actually looking for was "Critical Rendering Path" - the general stages of the process are well explained by other good answers.

Thank God, and good job everyone!

Answer 1

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.

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.

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:

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

That's called recalculate style in the developer tool

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.

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:

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

5.Paint

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

---

Javascript

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.

---

Cookies

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.

---

Sources:

• Critical rendering path

• critical rendering path

• Cookies

• js lifecycle

• tcp

• http

Answer 2

You can find many explanations on this topic, but I guess following is the easiest explanation to understand how browser(s) renders a web page.

1. You type an URL into address bar in your preferred browser.
2. The browser parses the URL to find the protocol, host, port, and path and it forms a HTTP request (that was most likely the protocol).
3. To reach the host, it first needs to translate the human readable host into an IP number, and it does this by doing a DNS lookup on the host
4. Then a socket needs to be opened from the user’s computer to that IP number, on the port specified (most often port 80)
5. When a connection is open, the HTTP request is sent to the host
6. The host forwards the request to the server software (most often Apache) configured to listen on the specified port
7. The server inspects the request (most often only the path), and launches the server plugin needed to handle the request (corresponding to the server language you use, PHP, Java, .NET, Python?)
8. The plugin gets access to the full request, and starts to prepare a HTTP response.
9. To construct the response a database is (most likely) accessed. A database search is made, based on parameters in the path (or data) of the request
10. Data from the database, together with other information the plugin decides to add, is combined into a long string of text (probably HTML).
11. The plugin combines that data with some meta data (in the form of HTTP headers), and sends the HTTP response back to the browser.
12. The browser receives the response, and parses the HTML (which with 95% probability is broken) in the response.
13. A DOM tree is built out of the broken HTML and new requests are made to the server for each new resource that is found in the HTML source (typically images, style sheets, and JavaScript files). Go back to step 3 and repeat for each resource.
14. Stylesheets are parsed, and the rendering information in each gets attached to the matching node in the DOM tree.
15. Javascript is parsed and executed, and DOM nodes are moved and style information is updated accordingly.
16. The browser renders the page on the screen according to the DOM tree and the style information for each node and you see the page on the screen.

Source

Answer 3

I'd like to suggest the following for anyone who would like to watch what happens, it's a cheap answer but it might be useful to explain how the browser retrieves it's cascade of files to construct the contents of a URL (in this case an html).

1. Browse to a page you want to use to demonstrate in Chrome (or use this page for a fairly complex example)
2. Open the console (Ctrl + Shift + i)
3. Select "Network" from the options
4. Hit F5

Play with the settings. You should also look at the timeline created in the Performance tab

5. Select "Performance" from the options
6. Hit F5

It may be useful here to throttle back the performance, so you can watch it in real time (slow) if that's something you want to demonstrate.

The important thing is (using an HTML page as an example), the order of rendering/applying css/running javascript, depends on where it appears in the DOM. It's possible to execute a script at any point after it's loaded, subject to the required resources being available. Css could be part of the HTML document (inline) or it might be coming from a very busy server and take 10-20 seconds before it can be applied. Hope this is of some help -R

Answer 4

1. The answer to all most of your questions "What happens when we search Google".
2. The browser renders HTML to the page by following html syntax standard. Remember that browsers are very forgiving and there is such thing as invalid HTML.
3. Css is applied to the page by following css grammar.
4. All browsers have to implement js according to ECMA Script standards.

Some other useful resources:

1. Firefox 3D tilt plugin help visualise webpages and how they are rendering content in different layers.

2. Chrome's performance tab a good visualisation of what happens during a page load and how the dom tree is constructed. It helps in identifying the bottlenecks in the render process.

3. You can see a lot of backend functionality of your browser like the cached HTML content, cached images, dns cache, open ports etc. by opening chrome://net-internals/.