Navigation process
What happens when the browser enters the URL and displays the page? This is a very classic front-end interview topic, this topic is very test front-end skills, the whole process involves network request and rendering process two large chunks of content, then we first review the navigation process.
1. The browser process builds the complete URL
- The browser process checks the entered URL, assembles the protocol, and builds the complete URL
- Browser processes send URL requests to network processes via interprocess communication (IPC)
2. The network process initiates the URL request
- Find if the local cache is valid, and if so, use the local cache. If not, the network request process is entered
- The first step in a network request is DNS resolution to get the IP address of the requested domain name
- Establish a TCP connection with the server and build the request message
- After the server receives the request, it constructs the response information
- After the browser receives the response, the network process parses the response information. If the status code is 301/302, the browser redirects to the new ADDRESS and initiates a new URL request
- The browser processes the response based on the content-Type
3. The browser process submits the document to the renderer
- When the browser process receives the response, it prepares the renderer process, which is reused by the same site (same root domain, same protocol)
- When the renderer process is ready, the browser process communicates with the renderer process to transfer documents
4. The rendering process starts parsing the page and loading sub-resources to complete the rendering of the page
This process is called the rendering process. Let’s look at this process in detail.
Rendering process
Build a DOM tree
Why build a DOM tree? Because browsers don’t recognize HTML, you parse the HTML into a browser-recognized data structure, the DOM tree. The following figure shows a DOM tree.
2. Build the CSSOM tree
Similarly, browsers don’t recognize CSS, so browsers first parse CSS into browser-aware data structures called styleSheets.
The browser then converts the style’s attribute value to a standard value. Standard values are easier for rendering engines to understand and use.
Finally, the style of each node in the DOM tree is computed to generate the final CSSOM tree. This process involves CSS inheritance and cascading rules.
3. Build the layout tree
Now that we have DOM and CSSOM as separate objects, the browser combines the two object models to build the layout tree.
First, the browser iterates through all visible elements (invisible tags like head or elements with Dispaly set to None are excluded from the layout tree), and then finds the style that the node fits and applies it.
At this point, the browser does not know the location of each node, so the browser traverses the layout tree to calculate the location of each node, which is the computed layout.
4. Layering and drawing
After calculating the layout, instead of drawing it immediately, layers are created for nodes with complex effects such as 3D or perspective transformation, z-sorting, and layer trees are created to make it easy to achieve complex effects. The browser page is actually divided into many layers, which are superimposed to create the final page. In general, not every node in the layout tree contains a layer, and if a node has no corresponding layer, then the node is subordinate to the layer of the parent node.
So when do you create layers?
- Cascading context (elements with explicitly positioned attributes, elements with transparent attributes defined, CSS filters used)
- Need to crop (Overflow: hidden; The overflow part is clipped)
With the layer tree in place, the next step is to draw layers.
The browser will break up a layer into small draw instructions, and then arrange the instructions in a list in order. The drawing process is similar to drawing with canvas.
The browser then divides the layer into blocks. This is done because the viewport has a limited amount of content to display. Drawing the entire structure directly is too expensive, so the browser preferentially converts the blocks inside the viewport into bitmaps, a process called rasterization.
Finally, the bitmap is composited and the browser displays it.
summary
The overall flow from entering the URL to rendering the page:
- The browser process builds the complete URL and submits it to the network process through interprocess communication
- Network process:
- Check the cache
- The DNS
- Establishing a TCP connection (three-way handshake)
- Send request data
- The response data is received and parsed according to the response data type
- The web process submits the processed data to the browser process, which prepares the render process
- Render process:
- Parsing the HTML into a DOM tree
- Parse the CSS into a CSSOM tree
- Build the DOM tree and the CSSOM tree into the layout tree
- Layering and drawing
As shown below, the HTML rendering process is as follows:
Characteristics of the rendering process
Refluxing and repainting
These two concepts are important in the rendering process, and understanding them and applying them properly can improve performance.
backflow
This process is called backflow when an element’s geometry (size), hidden attributes, and so on change to trigger a rendering of the layout. Backflow requires updating the complete rendering process (layout – layering – drawing – block – Rasterization – composition – display), so it is expensive and should be avoided as much as possible.
Property that triggers backflow
- Box model-related attributes (width, padding, margin, display, border, etc.)
- Locate properties and floats (position, top, float, etc.)
- Text structure (text-align, font, white-space, overflow, etc.)
redraw
This process is called redrawing when the appearance, style, and other attributes of an element change without affecting the rendering of the layout. Redraw eliminates layout and layering stages (draw – block – Rasterize – composit-display), so performance is better than reflux. Redrawing does not necessarily trigger redrawing.
Property that triggers a redraw
Color, border-style, background, outline, box-shadow, visibility, text-decoration
Avoid redrawing and reflow
Frequent redrawing and backflow triggers frequent UI rendering, which ultimately leads to poor performance. So try to avoid redrawing and reflow:
- Avoid using CSS properties that trigger redraw and backflow
- Create a separate layer for frequently redrawn reflow elements
skills
- Transform: Bypassing backflow and repainting and going straight to composition (Block – Rasterization – Composition – display)
- Use opacity instead of visibility: visibility triggers redrawing
- Use class instead of DOM frequent manipulation styles
- The DOM is modified offline. If the DOM is frequently modified, hide the DOM and display it after the modification is complete
- Do not read DOM property values in a loop: offsetHeight invalidates the backflow buffer
- Try not to use the table layout, small changes will cause the entire table layout
- Animation speed: 200~500ms is the best
- Create a new layer for the animation
- Enable GPU hardware Acceleration: Enable translate3D
HTML parsing features
Sequential execution and concurrent loading
- Sequential execution: LEXICAL analysis of HTML is performed from top to bottom, sequentially
- Concurrent loading: When the HTML parser is blocked by a script, the parser stops building the DOM but still recognizes the resources behind the script and preloads them.
- Concurrency limit: Browsers have a limit on the number of concurrent requests for the same domain (HTTP/2 does not have this limit)
blocking
The CSS block
- CSS blocks page rendering in head: avoid page flashing
- CSS blocks JS execution: When CSSOM is built, JavaScript execution is suspended until CSSOM is ready.
- The CSS does not block the loading of external scripts
By default, CSS blocks rendering, which means that the browser will not render any processed content until CSSOM is built. However, using media queries keeps CSS resources from blocking rendering on the first load.
Js blocked
- Directly introduced JS blocks rendering of the page: when the browser encounters a script tag, DOM construction is halted until the script is finished executing
- Js does not block loading of resources
- Sequential js execution blocks subsequent JS execution
- Js can query and modify DOM and CSS
Change js blocking
The defer and async properties can change js blocking, but they only apply to scripts introduced in SRC mode, not inline-scripts.
Defer means that the script will be loaded asynchronously by the browser without affecting subsequent DOM rendering. It will be executed after the document has been parsed and before the DOMContentLoaded event is triggered. Use async=false for dynamically embedded scripts to achieve a similar effect.
Async means asynchronous execution. The browser asynchronously loads the script and executes it if allowed. The difference from defer is that execution begins once the script has loaded, either at the HTML parsing stage or after DOMContentLoaded is triggered. Note that JavaScript loaded this way still blocks the load event.
DOMContentLoaded
The DOMContentLoaded event is fired after the initial HTML document has been fully loaded and parsed, without waiting for the stylesheet, image, and subframe to complete loading.Copy the code
load
Load should only be used to detect a fully loaded page. When a resource and its dependencies have finished loading, the LOAD event will be triggered.Copy the code