How Browser Works
Simplified version of how browser works with a curated list of great resources
High Level Architecture
Chrome has a multi-process architecture. Each module executes in one or multiple separated processes. For example, each tab may have its own renderer process.
Navigate to a URL
While typing, the UI thread needs to parse and decide whether to send you to a search engine, or to the site you requested.
When you hit Enter, the network thread performs DNS lookup, TLS Connection for the request.
If server returns a 301 redirect, repeat previous steps against the new URL.
Once the response body starts to come in, the network thread check the Content-Type header or read a few bytes of the content to decide how to proceed. e.g., if text/html render as html; if image/jpeg, render as image; if application/octet-stream, download the file.
Render a Page
The renderer process’s core job is to turn HTML, CSS, and JavaScript into a web page that the user can interact with
Parse HTML to a DOM Tree
- HTML is parsed incrementally
- Stream the HTML response to the client
Parse CSS to a CSSOM Tree
- CSS is not incremental
- We must wait for the entire file
- So put css at the top of the html head
Combine DOM Tree & CSSOM Tree to a Render Tree
- A tree for rendering
- Ignore
display:none
“Layout” elements position and size (width/height/position)
- Compute geometry of each node
- Layout can be very expensive
- Change in size, position will trigger a layout update
- Sometimes “layout” or “reflow” are interchangeable
“Paint” some pixels to the users’ screens
- Composite all the elements and layers into a bitmap
- Push the pixels to the screen
- Viewport is split into rectangular tiles
- We want to update the minimal amount
JavaScript can manipulate the DOM and the CSSOM so browser must wait. It may trigger
- Style recalculation
- Layout recalculation
- Paint update
Sync scripts block the parser, therefore, always async load your script
Some great readings
