Browser rendering process and performance optimization

Browser rendering process and performance optimization

As we all know, the application layer of the World Wide Web uses the HTTP protocol, and uses the browser as the entry point to access resources on the network. When a user uses a browser to access a website, he needs to first send a request to the server through the HTTP protocol, and then the server returns the HTML file and response information. At this time, the browser will parse and render according to the HTML file (this stage also includes requesting non-inline CSS files and JavaScript files or other resources from the server), and finally present the page to the user.

Now we know that web page rendering is done by the browser. If a website's page loading speed is too slow, it will lead to a less friendly user experience. This article introduces some basic browser performance optimization solutions by explaining the browser rendering process in detail. Let the browser render your web page faster and respond quickly to improve the user experience.

Critical Rendering Path

The rendering process in which the browser receives the HTML, CSS and JavaScript byte data returned by the server and parses and converts it into pixels is called the critical rendering path. By optimizing the critical rendering path, the time it takes for the browser to render the page can be shortened.

Before rendering a page, the browser needs to build a DOM tree and a CSSOM tree (without the DOM tree and the CSSOM tree, the structure and style of the page cannot be determined, so these two items must be built first).

DOM tree is called Document Object Model. It is a programming interface for HTML and XML documents. It provides a structured representation of documents and defines a way for programs to access the structure (for example, JavaScript uses DOM to manipulate structure, style, and content). DOM parses a document into a collection of nodes and objects. It can be said that a web page is actually a DOM.

The full name of CSSOM tree is Cascading Style Sheets Object Model. Its meaning is almost the same as that of DOM tree, except that it is a collection of CSS objects.

Constructing DOM tree and CSSOM tree

After the browser gets the HTML byte data from the network or hard disk, it will go through a process to parse the bytes into a DOM tree:

  • Encoding: First convert the raw byte data of HTML into characters of the encoding specified by the file.
  • Tokenization: The browser will then convert the string into various tokens according to the HTML specification (such as, such tags and the strings and attributes in the tags will be converted into tokens, each token has a special meaning and a set of rules). The token records the beginning and end of the tag. This feature can easily determine whether a tag is a child tag (assuming there are two tags, when the tag token meets the tag token before it meets its end token, then it is a child tag).
  • Generate objects: Next, each token is converted into an object that defines its properties and rules (this object is the node object).
  • Construction completed: The DOM tree is constructed, and the entire object collection is like a tree structure. Some people may wonder why DOM is a tree structure. This is because there is a complex parent-child relationship between tags, and the tree structure can just explain this relationship (the same is true for CSSOS, and cascading styles also have parent-child relationships. For example: div p {font-size: 18px} will first find all p tags and determine whether its parent tag is div before deciding whether to use this style for rendering).

The entire DOM tree construction process is actually: byte -> character -> token -> node object -> object model. The following will explain this process more vividly through a sample HTML code and illustrations.

  1.  <html>
  2.  <head>
  3.     <metaname= "viewport" content= "width=device-width,initial-scale=1" >
  4.     <linkhref= "style.css" rel= "stylesheet" >
  5.     <title>Critical Path</title>
  6.  </head>
  7.  <body>
  8.     <p>Hello <span>web performance</span> students!</p>
  9.     <div><imgsrc= "awesome-photo.jpg" ></div>
  10.  </body>
  11.  </html>

When the above HTML code encounters a tag, the browser will send a request to obtain the CSS file marked in the tag (using inline CSS can omit the request step to increase speed, but there is no need to lose modularity and maintainability for this little speed). The content of style.css is as follows:

  1.  body { font- size : 16px }
  2.  p { font-weight: bold }
  3.  span { color: red }
  4.  p span { display: none }
  5.  img { float : right }

After the browser obtains the data of the external CSS file, it will start to build the CSSOM tree just like building the DOM tree. There is no special difference in this process.

If you want to experience the construction of the critical rendering path in more detail, you can use the Timeline function in the Chrome developer tools, which records the various operations of the browser from requesting page resources to rendering, and can even record the process of a certain period of time (it is recommended not to visit too large websites, as the information will be more messy).

Building the render tree

After constructing the DOM tree and CSSOM tree, the browser only has two independent sets of objects. The DOM tree describes the structure and content of the document, and the CSSOM tree describes the style rules applied to the document. If you want to render a page, you need to combine the DOM tree and the CSSOM tree together, which is the render tree.

  • The browser will first traverse each visible node starting from the root node of the DOM tree (invisible nodes naturally do not need to be rendered to the page. Invisible nodes also include nodes that have the display: none attribute set by CSS. It is worth noting that the visibility: hidden attribute is not considered an invisible attribute. Its semantics is to hide the element, but the element still occupies the layout space, so it will be rendered as an empty box).
  • For each visible node, find the appropriate CSS style rule and apply it.
  • The rendering tree is constructed, each node is a visible node and contains its content and the style of the corresponding rule.

After the rendering tree is built, the browser obtains the content and style of each visible node. The next step is to calculate the exact position and size of each node in the window, which is the layout stage.

CSS uses a mental model called the box model to represent the distance between each node and other elements. The box model includes margins, padding, borders, and content. Each tag on the page is actually a box.

The layout phase starts from the root node of the render tree and determines the exact size and position of each node object on the page. The output of the layout phase is a box model that accurately captures the exact position and size of each element on the screen. All relative measurements are converted to absolute pixel values ​​on the screen.

  1.  <html>
  2.  <head>
  3.     <metaname= "viewport" content= "width=device-width,initial-scale=1" >
  4.     <title>Critial Path: Hello world!</title>
  5.  </head>
  6.  <body>
  7.  <divstyle= "width: 50%" >
  8.       <divstyle= "width: 50%" >Hello world!</div>
  9.  </div>
  10.  </body>
  11.  </html>

When the Layout event is completed, the browser will immediately issue Paint Setup and Paint events to start drawing the render tree into pixels. The time required for drawing is proportional to the complexity of the CSS style. After the drawing is completed, the user can see the final rendering effect of the page.

It may take only 1-2 seconds for us to send a request to a web page and get the rendered page, but the browser has actually done a lot of work mentioned above. Let's summarize the entire process of the browser's critical rendering path:

  • Processes HTML markup data and generates a DOM tree.
  • Processes CSS markup data and generates a CSSOM tree.
  • Merge the DOM tree and the CSSOM tree together to generate the render tree.
  • Traverse the rendering tree to start layout and calculate the position information of each node.
  • Draw each node to the screen.

Optimization solutions for rendering blocking

If a browser wants to render a page, it must first construct a DOM tree and a CSSOM tree. If the HTML and CSS file structures are very large and complex, this will obviously have a serious impact on the page loading speed.

The so-called rendering blocking resources mean that after sending a request to the resource, the corresponding DOM tree or CSSOM tree needs to be built first. This behavior will obviously delay the start time of the rendering operation. HTML, CSS, and JavaScript are all resources that will cause rendering blocking. HTML is necessary (how can you render without DOM), but you can also start with optimizing CSS and JavaScript to reduce the occurrence of blocking as much as possible.

Optimizing CSS

If CSS resources can be used only under specific conditions, then these resources can be loaded at the last moment without building the CSSOM tree. Only when specific conditions are met will the browser block rendering and then build the CSSOM tree.

CSS media queries are used to achieve this function. They consist of a media type and zero or more expressions that check the status of specific media features.

  1.  <! -- Without using media queries, this CSS resource will block rendering -->  
  2.  <linkhref= "style.css" rel= "stylesheet" >
  3.  <! -- all is the default type, which has the same effect as not setting a media query -->  
  4.  <linkhref= "style.css" rel= "stylesheet" media= "all" >
  5.  <! -- Dynamic media queries, which will be calculated when the page loads.  
  6.  Depending on the orientation of the device when the page is loaded, portrait.css may or may not be render-blocking. -->  
  7.  <linkhref= "portrait.css" rel= "stylesheet" media= "orientation:portrait" >
  8.  <! -- Only applied when printing the page, so it doesn't block rendering when the page is first loaded in the browser. -->  
  9.  <linkhref= "print.css" rel= "stylesheet" media= "print" >

Using media queries can prevent CSS resources from blocking rendering during *** loading, but no matter what kind of CSS resource, their download requests will not be ignored, and the browser will still download the CSS file first.

Optimizing JavaScript

When the browser's HTML parser encounters a script tag, it will pause the construction of the DOM and then transfer control to the JavaScript engine, which will then start executing the JavaScript script. After the execution is completed, the browser will resume from where it was previously interrupted and continue to build the DOM. Every time a JavaScript script is executed, the construction of the DOM tree will be severely blocked. If the JavaScript script also operates the CSSOM, and the CSSOM has not been downloaded and built, the browser will even delay the script execution and the construction of the DOM until the download and construction of the CSSOM is completed. Obviously, if the execution location of JavaScript is used improperly, this will seriously affect the rendering speed.

The JavaScript script in the following code will not take effect, because the JavaScript script has already started to execute before the DOM tree is built to the <p> tag. This is why people often write inline JavaScript code at the bottom of HTML files, or use window.onload() and $(function(){}) in JQuery (these two functions are slightly different, window.onload() is an event that is triggered after the page is fully loaded, while $(function(){}) will be executed after the DOM tree is built).

  1.  <html>
  2.  <head>
  3.     <metaname= "viewport" content= "width=device-width,initial-scale=1" >
  4.     <linkhref= "style.css" rel= "stylesheet" >
  5.     <title>Hello,World</title>
  6.     <scripttype= "text/javascript" >
  7.         var p = document.getElementsByTagName( 'p' )[0];
  8.         p.textContent = 'SylvanasSun' ;
  9.  </script>
  10.  </head>
  11.  <body>
  12.  <p>Hello, World!</p>
  13.  </body>
  14.  </html>

Using async can inform the browser that the script does not need to be executed at the referenced location, so that the browser can continue to build the DOM, and the JavaScript script will start executing when it is ready, which will significantly improve the performance of page loading (async can only be used in the src tag, that is, externally referenced JavaScript files).

  1.  <! -- The following two usages are equivalent -->  
  2.  <scripttype= "text/javascript" src= "demo_async.js" async= "async" ></script>
  3.  <scripttype= "text/javascript" src= "demo_async.js" async></script>

Summary of Optimizing the Critical Rendering Path

The above article has fully described how the browser renders the page and the preparations before rendering. Next, we will summarize the methods for optimizing the critical rendering path with the following case.

Suppose there is an HTML page that only imports one CSS external file:

  1.  <html>
  2.  <head>
  3.     <metaname= "viewport" content= "width=device-width,initial-scale=1" >
  4.     <linkhref= "style.css" rel= "stylesheet" >
  5.  </head>
  6.  <body>
  7.     <p>Hello <span>web performance</span> students!</p>
  8.     <div><imgsrc= "awesome-photo.jpg" ></div>
  9.  </body>
  10.  </html>

Its critical rendering path is as follows:

First, the browser sends a request to the server to obtain the HTML file. After obtaining the HTML file, it starts to build the DOM tree. When encountering the <link> tag, the browser needs to send another request to the server to obtain the CSS file. Then it continues to build the DOM tree and CSSOM tree. The browser merges the rendering tree, performs layout calculations based on the rendering tree, performs drawing operations, and the page rendering is completed.

There are several terms used to describe critical rendering path performance:

  • Critical resources: resources that may block the *** rendering of the web page (two in the figure above, the HTML file and the external CSS file style.css).
  • Critical path length: the number of round trips or total time required to obtain key resources (the above figure shows 2 or more times, one time to obtain the HTML file and one time to obtain the CSS file. This number is based on the maximum congestion window of the TCP protocol. A file may not be able to be transmitted in one connection).
  • Key Bytes: The sum of the sizes of all key resource files (9KB in the above figure).

Next, the sample code requirements changed to include a new JavaScript file.

  1.  <html>
  2.  <head>
  3.     <metaname= "viewport" content= "width=device-width,initial-scale=1" >
  4.     <linkhref= "style.css" rel= "stylesheet" >
  5.  </head>
  6.  <body>
  7.     <p>Hello <span>web performance</span> students!</p>
  8.     <div><imgsrc= "awesome-photo.jpg" ></div>
  9.     <scriptsrc= "app.js" ></script>
  10.  </body>
  11.  </html>

The JavaScript file blocks the construction of the DOM tree, and when executing the JavaScript script, it is necessary to wait for the CSSOM tree to be built first. The key rendering path characteristics of the above figure are as follows:

  • Key resources: 3 ( HTML , style.css , app.js )
  • Critical path length: 2 or more (the browser will download style.css and app.js together in one connection)
  • Keyword bytes: 11KB

Now, we want to optimize the critical rendering path. First, add the asynchronous attribute async to the <script> tag so that the browser's HTML parser will not block this JavaScript file.

  1.  <html>
  2.  <head>
  3.     <metaname= "viewport" content= "width=device-width,initial-scale=1" >
  4.     <linkhref= "style.css" rel= "stylesheet" >
  5.  </head>
  6.  <body>
  7.     <p>Hello <span>web performance</span> students!</p>
  8.     <div><imgsrc= "awesome-photo.jpg" ></div>
  9.     <scriptsrc= "app.js" async></script>
  10.  </body>
  11.  </html>

  • Key resources: 2 ( app.js is loaded asynchronously and will not become a rendering-blocking resource)
  • Critical path length: 2 or more
  • Critical Bytes: 9KB ( app.js is no longer a critical resource, so its size is not included)

Next, optimize the CSS, such as adding media queries.

  1.  <html>
  2.  <head>
  3.     <metaname= "viewport" content= "width=device-width,initial-scale=1" >
  4.     <linkhref= "style.css" rel= "stylesheet" media= "print" >
  5.  </head>
  6.  <body>
  7.     <p>Hello <span>web performance</span> students!</p>
  8.     <div><imgsrc= "awesome-photo.jpg" ></div>
  9.     <scriptsrc= "app.js" async></script>
  10.  </body>
  11.  </html>

  • Key resources: 1 ( app.js is loaded asynchronously, style.css is only used when printing, so only HTML is left as a key resource, which means that when the DOM tree is built, the browser will start rendering)
  • Critical path length: 1 or more
  • Keyword Bytes: 5KB

Optimizing the critical rendering path is to optimize the critical resources, critical path length and key bytes. The fewer critical resources there are, the less preparation the browser has to do before rendering; similarly, the critical path length and key bytes are related to the efficiency of the browser downloading resources. The fewer they are, the faster the browser downloads resources.

Other optimization solutions

In addition to asynchronously loading JavaScript and using media queries, there are many other optimization solutions that can make the page load faster. These solutions can be used in combination, but the core idea is to optimize the critical rendering path.

Loading partial HTML

When the server receives the request, it will only respond with the initial part of the HTML, and the subsequent HTML content will be obtained through AJAX when needed. Since the server only sends part of the HTML file, the workload of building the DOM tree is greatly reduced, making the user feel that the page loads very quickly.

Note that this method cannot be used on CSS. The browser does not allow CSSOM to construct only the initial part, otherwise it will not be able to determine the specific style.

compression

By compressing external resources, the amount of resources that the browser needs to download can be greatly reduced. It will reduce the critical path length and key bytes, making the page load faster.

Compressing data is actually re-encoding the data using fewer bits. There are many compression algorithms nowadays, and each one has different areas of application and complexity. However, I will not go into the details of compression algorithms here. Friends who are interested can Google them themselves.

Before compressing files such as HTML, CSS and JavaScript, you need to perform redundancy compression first. Redundancy compression is to remove redundant characters, such as comments, spaces and line breaks. These characters are useful for programmers, after all, the readability of unformatted code is very terrible, but they are meaningless to browsers. Removing these redundancies can reduce the amount of data in the file. After the redundancy compression is completed, the data itself is further compressed using a compression algorithm, such as GZIP (GZIP is a general compression algorithm that can be used on any byte stream. It will remember what it has seen before, and then try to find and replace duplicate content.).

HTTP Cache

Retrieving resources over the network is usually slow. If the resource file is too large, the browser needs to communicate with the server multiple times to obtain the complete resource file. The cache can reuse previously obtained resources. Since the backend can use the cache to reduce the overhead of accessing the database, the frontend can also use the cache to reuse resource files.

The browser has built-in HTTP caching capabilities. You just need to make sure that the header of each server response contains the following attributes:

1. ETag: ETag is a pass-through verification token that checks for updates to resources. If the resource has not changed, no data will be transmitted. When the browser sends a request, it will send the ETag to the server. The server will check the token against the current resource (ETag is usually a fingerprint obtained by hashing the content). If the resource has not changed, the server will return a 304 Not Modified response. At this time, the browser does not need to download the resource again, but continues to reuse the cache.

2. Cache-Control: Cache-Control defines the cache policy, which stipulates under what conditions the response can be cached and how long it can be cached.

  • no-cache: no-cache means that you must first confirm with the server whether the returned response has changed before you can use that response to satisfy subsequent requests for the same URL (each time a request is sent to the server based on ETag to confirm the change; if there is no change, the browser will not download the resource).
  • no-store: no-store directly prohibits the browser and all intermediate caches from storing any version of the returned response. Simply put, this policy prohibits any cache and downloads the server's response in full every time a request is sent.
  • public&private: If the response is marked as public, the browser can cache the response even if it has associated HTTP authentication and even if the response status code is usually not cacheable. If the response is marked as private, then this response is usually cached only for a single user, so no intermediate cache (CDN) is allowed to cache it. Private is generally used to cache user private information pages.
  • max-age: max-age defines the maximum cache time starting from the request time, in seconds.

Resource preloading

Pre-fetching is a method of prompting the browser to preload resources that the user may need later.

Use dns-prefetch to perform DNS resolution in advance so that you can quickly access another host name later (the browser will resolve and cache the domain name in the web page when loading the web page, so that you don’t need to perform additional DNS resolution on subsequent visits, reducing user waiting time and increasing page loading speed).

  1.  <linkrel= "dns-prefetch" href= "other.hostname.com" >

Use the prefetch attribute to pre-download resources, but its priority is ***.

  1.  <linkrel= "prefetch" href= "/some_other_resource.jpeg" >

Chrome allows you to use the subresource attribute to specify the highest priority download resource (the resource with the attribute prefetch will not be downloaded until all resources with the attribute subresource are downloaded).

  1.  <linkrel= "subresource" href= "/some_other_resource.js" >

prerender can pre-render a page and hide it. When the page is opened later, it will skip the rendering stage and be presented directly to the user (it is recommended to pre-render the page that the user must visit next, otherwise the gain will outweigh the loss).

  1.  <linkrel= "prerender" href= "//domain.com/next_page.html" >

<<:  2017 Big Data Festival is coming in October, iResearch A10 Summit will open on the 27th

>>:  【IT Observation】Methodology for programmers to train new people

Recommend

Can consumption be doubled by optimizing information flow using these 3 copywriting tricks?

Today we are going to talk about the black techno...

What preparations should be made before launching an App or Web product?

This is a question that has been delayed for quit...

Why do most startup marketing fail?

The author of this article will explain the mista...

When doing promotion, how can we achieve systematic thinking and rhythmic control?

This article will explain from the thinking level...

WeChat for Business: A Practical Guide to Marketing Management

Introduction to the practical strategy resource o...

Toutiao account optimization plan!

"Whatever does not destroy me will make me s...

How much does it cost to attract investors for the Baoding fast food mini program? What is the investment quotation for Baoding fast food mini program?

How much does it cost to attract investors for th...

Douyin super useful information: a complete guide from getting started to operation!

"Two Weibo and One Douyin" have become ...

Caocao talks about movies: a one-stop guide to movie commentary, revealing the method of gaining tens of millions of followers in a year

Caocao talks about movies: a one-stop guide to mo...

Analysis report on competitive products of Dewu and Shihuo

This is my first attempt at writing a competitive...

Novel Reading Network: How does Tingyun Server ensure the performance of a high-concurrency website with tens of millions of users?

As of December 31, 2014, Xiaoshuo.com has been on...

9 cases and 12 methods to obtain seed users

Regarding seed users , there are several concepts...

From Himalaya’s “123 Carnival”: How can content payment continue to explode?

As of 6 a.m. on December 1: Himalaya's "...

From the spicy snack brand Weilong’s marketing methods, it can imitate Apple’s flagship store, so what is there to be afraid of!

Weilong "pays tribute" to Apple again, ...

Alang South Gate Video Hall "2021PR Zero-Based Systematic Editing Thinking Training Camp"

Nanmen Video Studio's "PR Zero-Based Sys...