Website performance optimization What you need to know

The website performance mentioned in this article refers to the response speed of the website, which is also in line with most people's understanding of the performance of the site: Access to fast website performance is good, conversely, the slower the access speed, the site performance is worse. The optimization method summarized in this paper is a macro-engineering-level approach, and does not include microscopic language grammar-level methods, such as JS, CSS syntax optimization, which also affect the performance of the site, but the language grammar level of optimization depends more on the developer's programming level.

What kind of website responds faster? In fact, it is easy to think that the faster the site loads resources, the faster the site responds, the less resources the site needs to load, and the faster the site responds. This corresponds to the two main directions of website Performance Optimization: Resource cache, resource merging and compression. When the browser completes the load of the resource, it needs to parse the resources further to render the final page, so the parsing mechanism of the browser is also one of the directions of the website performance optimization. Various optimization methods can be categorized into these three general directions.

1. Resource Cache 1.1 using CDN

The static resources of the site, such as static HTML, image image, CSS style, script JS, and so on, the static resources deployed to the CDN, can significantly accelerate the loading speed of this part of the resources.

1.2 Using the HTTP caching mechanism

The HTTP cache caches the browser-loaded resources locally, and the next time it loads, it can use local resources directly, reducing the number of HTTP requests and speeding up the load of resources, as long as the cached resources are not expired. This is done by setting the Cache-control parameter in the HTTP Header. HTTP 1.0 uses pragma and expires two parameters for caching, but it is deprecated.

2. Merge compression of resources 2.1 reduce HTTP requests

Using an HTTP request to load a 10M file, and split the file into 1M of 10 files, 10 HTTP requests in parallel to load, which way to complete the load faster? Since the mention of reducing HTTP requests can improve the responsiveness of your Web site, the conclusion seems to be that it should be quicker to use an HTTP request. In fact, the correct answer is: not necessarily!

I did a little experiment: There are two HTML files, index1.html and index2.html,index1.html with 1 <script> tags to load a 2M js file bundle.js,index2.html with 6 <script> tags loaded bundle1.js, bundle2.js ... bundle6.js, these 6 JS files are divided by Bundle.js average. Request index1.html and index2.html 10 times respectively, get load bundle.js time and load Bundle1.js to Bundle6.js time (with the last JS file loading completed as the end time), the average load time calculated is 1.07s and 1.87s respectively.

Experimental results show that a htttp request to load a merged resource file is more efficient than multiple HTTTP requests to load multiple resource files concurrently. But the conclusion is only for the average load time, for a single comparison, it is possible to have the opposite conclusion, for example, in my experiment, the single htttp request load time of the maximum value of 2.36s, more than the second load method of the average time of 1.87s. Perhaps some people will be more puzzled, why the parallel efficiency is lower than the serial? In fact, the HTTP request loads the bottleneck of the resource in the bandwidth, not the number of requests, and when a request has been utilized with sufficient bandwidth, adding new requests does not reduce the overall resource load time.

In fact, the reduction of HTTP requests to improve site performance is mainly based on the following 2 reasons:

1) The establishment of HTTP connection is more time-consuming, generally need hundreds of MS, each HTTP request also has a certain network delay, the more HTTP requests required, the two parts of the more time-consuming. Of course, the default support for HTTP 1.1 for keep-alive, which enables the reuse of connections, greatly optimizes the problem.

2) Each HTTP request requires additional data, such as header information in the request and response, and cookie information. When the requested resource is very small, the accompanying additional data may be larger than the actual resource.

2.2 js File

Combined compression JS file, on the one hand, the number of JS files decreased, the number of HTTP requests will be reduced, on the other hand, compression JS file can greatly reduce the file volume. JS files can be compressed and merged using Web build tools such as Webpack.

Note that compressing and merging JS files is not about packing all the JS files into a single JS file. The general practice is to follow the "Basic code" + "page code" separately packaged. "Base Code" refers to the common code that is used for each page or route (for a single page), which is code that is used only on a specific page or route. This enables the JS code to be loaded on demand, to avoid the first screen loading, because a single JS file is too large, and affect the first screen display time. For a single page application, there can also be a vendor.js file, the content of which is used in a relatively high frequency of third-party libraries (such as echarts, etc.), but these libraries are not used by every route, so it will not be packaged into the "Base code". Such a third-party library from each routing page corresponding to the JS file split, one can reduce the overall size of all JS files, because it could have been a, B and many other files will contain the code, now only need a copy The second is that vendor.js only need to be loaded once, and subsequent opening of other routes, you can not need to load this part of the code again, played the role of resource preloading.

2.3 CSS Files

The CSS files are combined to compress, the basic principles and practices with the JS file.

2.4 pic

1) Use images in WEBP format. WEBP is a picture file format that supports lossy compression and lossless compression, derived from the image Encoding format VP8. According to Google's tests, lossless compressed WebP has a 45% less file size than PNG files, and WebP can reduce the file size by 28% even after the PNG files are compressed by other compression tools.

2) Use the font icon Iconfont. You can arbitrarily set the size and color of the icon graphic (only monochrome, because it essentially sets the color for the font).

3) Use CSS sprites to combine multiple images into one, thus reducing the number of HTTP requests.

4) Use Base64 to encode the image directly into a string into a CSS file, as well as reduce the number of HTTP requests. However, it is important to note that BASE64 encoded pictures are best small images (preferably dozens of-byte level), because the image is Base64 encoded, usually larger than the original file. Also, BASE64 encoded strings that are too long can affect the overall readability of the CSS.

5) For sites that require a large number of images, you should deploy the picture resources separately and use different domain names to access them. Because of the large bandwidth of picture resources, if you deploy pictures and other resources to a single server or cluster, the server-side egress bandwidth will be greatly affected. Using different domain names to load image resources, you can better take advantage of the browser parallel download features, because the browser for the maximum number of concurrent requests under a domain name is limited.

2.5 Server-Side open gzip

The server-side enables gzip compression to reduce the volume of resource files during network transfer.

3. Browser loading, parsing, rendering mechanism

The browser works very cumbersome and complex, to understand carefully, you can refer to this classic article how to browers work.

Combined with the article and my own experiment to verify that, simply speaking, when the browser loads an HTML file,

1) The request to load all external resources (JS, CSS files, etc.) referenced in the HTML is placed in a queue and the browser loads the resources concurrently through multiple threads (which are determined by the browser settings).

2) The HTML is then parsed from top to bottom.

3) When parsing to the <script> tag, if the tag is embedded into the HTML JS code, will directly execute this part of the code, if the tag refers to the external JS file, and this file is not downloaded at this time, the parsing process will be blocked until the JS file download is complete, Then parse the execution of the JS code, before continuing the parsing process of HTML, if the tag refers to the external JS file, but at this time the JS file has been downloaded, it will directly execute this part of the JS code, does not block the parsing of HTML (it can be understood that the execution of the JS code at this time is the HTML parsing this <script> tag process).

4) When parsing to the <link> tag, no matter whether the external CSS resource referenced in <link> is finished loading, the HTML will not be blocked from continuing to parse.

Here are 2 places to be aware of:

1) Because JS loading will block the parsing of HTML, so the execution order of the code in multiple JS files is consistent with the order in which they are placed in the HTML. For example, in HTML, A.js is introduced from top to bottom, B.js, A.js's file size is much larger than b.js, so b.js files are likely to complete loading first, but not before the code in A.js, because before a.js load, parse, and execute, Parsing of HTML is blocked, and the <script> tag where the b.js is located will naturally not be parsed and executed. If you do not want to load an external JS file to block parsing of HTML, you can use the defer or async attribute of the script tag, which is no longer expanded.

2) all referenced external scripts or style files are added to the browser's request queue before the HTML begins parsing, so the starting time for multiple external resources to start loading is generally not significant, unless the number of external resources requested is large, exceeding the number of concurrent requests for the browser.

There are 2 ways to optimize performance based on the browser's working principle:

1) referring to the external CSS file link tag, will generally be written in

2) The script tag referring to the external JS file is usually written on the <body> bottom, in order to avoid HTML parsing being blocked, so that the page elements are displayed more quickly. It is important to note that although script is written at <body> Bottom, this does not mean that the other elements in <body> will begin to load these JS files after parsing, and these JS files are still added to the request queue before the HTML begins parsing.

The above is from the resource cache, the combination of resources compression and browser resolution principle of three dimensions, commonly used to optimize the performance of the site practice method

You are welcome to join the Learning Exchange Group if you encounter any problems or want to acquire learning resources in the learning process.

343599877, we learn the front-end together!

Website performance optimization What you need to know