Describe the page rendering process in a browser?

Question

First of all, I am not interested in the entire request-response process as addressed by this question

What is the complete process from entering a url to the browser's address bar to get the rendered page in browser?

I want to know what goes on inside a browser, once it receives the html response from the server. The intent behind asking this question is to understand the inner details of client side scripting. Also it would be beneficial if you can explain in abstract concepts what a web browser comprises of. You may call them as CSS engine, javascript engine etc.The goal is to precisely visualize the web development I am doing.

Unfortunately, I did not find any web resources addressing this issue. Please forgive me if there are resources out there which explain these concepts. You may point to the resources (books, etc) if this question is too exhaustive to answer.

Hannelorehanner

webkit source code / mozilla source code – Califate

I am looking for some abstract description that helps an average web developer visualize the client side scripting process. I am sure even if one writes mozilla from the ground up would also visualize this in some abstract way. – Hannelorehanner

Your best bet is to read How Browsers Work by Tali Garsiel. – Fibril

@Anatoni Papirovski, when parse html and encounter <script>, will browser halts until script executed? – Rondure

@pphanireddy, I have read the "How Browsers Work", and wonder when parse html and encounter <script>, does browser halts until script execute complete? – Rondure

@Rondure By default JavaScript blocks DOM construction and thus delays the time to first render (render-blocking). Whenever the parser encounters a script it has to stop and execute it before it can continue parsing the HTML. In the case of an external script the parser is also forced to wait for the resource to download. Scripts that are not critical to initial render should be made asynchronous or deferred until after the first render. More info: asynchronous-and-deferred-javascript-execution-explained – Happygolucky

@jason, the reason for blocking on <script> tags (that are not marked asynchronous) is that they may change the DOM and thus what is going to be rendered. IE6 would often start drawing early, hence those "jumps" in the page of modern websites. Note that the entire DOM is read from the page you are accessing. Tommy says "DOM construction", it's already fully constructed by the time you hit any scripts. What he meant is more "DOM execution/interpretation". Also, it is a good idea to have CSS files before scripts otherwise the width/height will be wrong. – Kendo

Answer 1

Please go through below steps and you should be clear with request lifecycle and how response is rendered.

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.

3. It forms a HTTP request (that was most likely the protocol)

4. 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

5. Then a socket needs to be opened from the user’s computer to that IP number, on the port specified (most often port 80)

6. When a connection is open, the HTTP request is sent to the host 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

14. 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).

15. Go back to step 3 and repeat for each resource.

16. Stylesheets are parsed, and the rendering information in each gets attached to the matching node in the DOM tree

17. JavaScript is parsed and executed, and DOM nodes are moved and style information is updated accordingly

18. The browser renders the page on the screen according to the DOM tree and the style information for each node

19. You see the page on the screen

20. You get annoyed the whole process was too slow.

Notch

The browser starts rendering the page right after the first HTML element is parsed. It certainly doesn't wait for the DOM tree to be completed, far less for all the external resources to load. Perhaps you can edit your answer to clarify that at least some of steps among 13-18 happen as a pipeline (one element at a time?), rather than sequentially. – Minus

Answer 2

An excellent talk by Mozilla's David Baron discusses this in detail. It's a video entitled Faster HTML and CSS: Layout Engine Internals for Web Developers, and it walks you through the five steps of rendering a DOM tree to the screen:

1. Construct the DOM
2. Calculate styles
3. Construct the rendering tree
4. Compute layout
5. Paint

Wilful

Answer 3

I will try to explain the page rendering process in depth. Kindly note that I am not focusing on the request-response process as the OP has asked in the question.

Once the server supplies the resources (HTML, CSS, JS, images, etc.) to the browser it undergoes the below process:

Parsing - HTML, CSS, JS
Rendering - Construct DOM Tree → Render Tree → Layout of Render Tree → Painting the render tree

1. The rendering engine starts getting the contents of the requested document from the networking layer. This will usually be done in 8kB chunks.
   
2. A DOM tree is built out of the broken response.
   
3. 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).
   
4. At this stage the browser marks the document as interactive and starts parsing scripts that are in "deferred" mode: those that should be executed after the document is parsed. The document state is set to "complete" and a "load" event is fired.
   
5. Each CSS file is parsed into a StyleSheet object, where each object contains CSS rules with selectors and objects corresponding CSS grammar. The tree built is called CSSCOM.
   
6. On top of DOM and CSSOM, a rendering tree is created, which is a set of objects to be rendered. Each of the rendering objects contains its corresponding DOM object (or a text block) plus the calculated styles. In other words, the render tree describes the visual representation of a DOM.
   
7. After the construction of the render tree it goes through a "layout" process. This means giving each node the exact coordinates where it should appear on the screen.
   
8. The next stage is painting–the render tree will be traversed and each node will be painted using the UI backend layer.
   
9. Repaint: When changing element styles which don't affect the element's position on a page (such as background-color, border-color, visibility), the browser just repaints the element again with the new styles applied (that means a "repaint" or "restyle" is happening).
   
10. Reflow: When the changes affect document contents or structure, or element position, a reflow (or relayout) happens.
    

What is the internal structure of a web browser?
To understand the page rendering process explained in the above points we also need to understand the structure of a web browser.

User interface: The user interface includes the address bar, back/forward button, bookmarking menu, etc. Every part of the browser display except the window where you see the requested page.
Browser engine: The browser engine marshals actions between the UI and the rendering engine.
Rendering engine: The rendering engine is responsible for displaying requested content. For example if the requested content is HTML, the rendering engine parses HTML and CSS, and displays the parsed content on the screen.
Networking: The networking handles network calls such as HTTP requests, using different implementations for different platforms behind a platform-independent interface.
UI backend: The UI backend is used for drawing basic widgets like combo boxes and windows. This backend exposes a generic interface that is not platform specific. Underneath it uses operating system user interface methods.
JavaScript engine: The JavaScript engine is used to parse and execute JavaScript code.
Data storage: The data storage is a persistence layer. The browser may need to save all sorts of data locally, such as cookies. Browsers also support storage mechanisms such as localStorage, IndexedDB, WebSQL and FileSystem.

Note:
During the rendering process the graphical computing layers can use general purpose CPU or the graphical processor GPU as well. When using GPU for graphical rendering computations the graphical software layers split the task into multiple pieces, so it can take advantage of GPU massive parallelism for float point calculations required for the rendering process.

Useful Links:
1. https://github.com/alex/what-happens-when
2. https://codeburst.io/how-browsers-work-6350a4234634

Fourfold