Some suggestions on improving website performance using JavaScript (I) and some suggestions on javascript

Some suggestions on improving website performance using JavaScript (I) and some suggestions on javascript

This article is a learning note, which will sort out what you have learned for later viewing.

Performance Golden Rule explains that there are only 10% ~ 20% of the end user response time is spent on the HTML document of the requested user, and the remaining 80% ~ 90% time spent on HTTP requests for all components referenced by HTML documents (images, scripts, style sheets, etc.), and end user response time spent on page Components

Zookeeper -- Steve Sounders

1. Merge files (reduce the number of HTTP requests)

CSS Sprites

  Uses css sprites to merge images used by the website into one image, and controls the background image position through background-position, width, and height to use an icon, in this way, multiple image requests can be reduced to one, and many tools are used to generate css sprites. grunt and gulp both have related plug-ins, and CssGaga is also good.

Merge js and css

Like the spirit map, merging css and js files is also an important way to reduce HTTP requests. there is no dispute over merging css files, but JavaScript modularization is prevalent, merging all js files into one file seems to be a regressing process. The correct method is to follow the compiling language mode and maintain the modularization of js. During the generation process, only the js files used in the initial request are generated to the target file.

2. Use the content publishing network (reducing the HTTP request time)

Another factor affecting the HTTP request time is the distance between you and the web server. Obviously, the longer the request takes, the more time it takes. This can be greatly improved through CDN.

Zookeeper CDN is a web server distributed across multiple geographic locations for more effective content delivery to users. The main function of CDN is to store static files for end users, as well as download and security services.

3. Set browser cache to avoid repeated HTTP requests)

Use Expire/Cache-control

The Zookeeper browser uses Cache to avoid repeated requests every time. HTTP 1.0 and HTTP1.1 have different Cache implementation methods, including Expires (1.0) and Cache-control (1.1 ). The Web server uses expires to tell the client to use cached copies of the file within the specified time and no longer send repeated requests to the server. For example:

Expires: Thu, 01 Dec 2016 16:00:00 GMT (GMT format)

The Zookeeper setting means that the cached copy can be used as of January 1, December 1, 2016 without sending a request.

Due to the expiration date, the client and server clock must be strictly synchronized, the Cache-Control introduced by HTTP 1.1 does not save this restriction by specifying a time in seconds to specify the Cache date. For example:

Cache-Control: max-age = 31536000

Zookeeper indicates that the Cache time is one year. Cache-Control is recommended. However, when HTTP 1.1 is supported, note that Cache-Control and Expire coexist, cache-Control has a higher priority.

Configure or remove ETag

Zookeeper uses Expire/Cache-Control to avoid repeated HTTP requests during the second access and improve the website speed. However, if the user clicks the browser to refresh or the expire has expired, an http get request will still be sent to the server. If the file does not change, the server returns the 304 Not Modified status code instead of the entire file.

The Zookeeper server determines whether the file has changed based on the Last-Modified (latest modification date) and ETag (entity tag );

  ETag (Entity Tags) is introduced in HTTP 1.1. It must have a higher priority when it coexist with Last-Modified. The server compares the ETag (If-None-Match) sent by the client with the current ETag. If the ETag is the same, the server returns 304 Not Modifed; otherwise, the whole file and 200 OK are returned.

Deletecetag has a problem: when the browser sends a GET request to the original component to a server and then requests the component to another server, the ETag does not match. Of course, if your website does not host on one server, but many websites now use multiple servers, the existence of ETag greatly reduces the success rate of verification effectiveness.

Zookeeper has this problem. The solution is to configure ETag. The innode value of the removed server only retains the modified Timestamp and size as the ETag value, or directly removes ETag, use Last-Modified to verify the file validity.

4. compression component (reducing the HTTP request size)

Upload compression compresses HTTP files to reduce the size of HTTP requests and increase the request speed. GZIP is currently the most common and effective compression method.

However, not all resource files need to be compressed. The compression cost includes the CPU cycle required by the server, and the client also needs to decompress the compressed files, you must weigh your website. Currently, most websites compress their HTML documents. Some websites choose to compress JavaScript and css files, and almost no websites perform GZIP compression on images, PDF files, and other files, the reason is that these files have been compressed. Using HTTP to compress the files that have been compressed cannot make them smaller. In fact, adding a header, compressing the dictionary, and verifying the response body actually makes it bigger, and it also wastes the CPU.

To enable GZIP for a website, you must set it in the web server (such as IIS, Nginx, and Apache) you are using.

5. Place the CSS file in the header.

CSS files are placed at the header and tail of the CSS file without affecting HTTP requests. Therefore, the request time is consistent. However, from the perspective of user experience, CSS files are placed at the header, it will provide a better user experience.

The reason is that the browser parses the html document from top to bottom and places the CSS file in the header. The page will first send a request to the CSS file, then load the DOM tree and render it, the page is gradually displayed in front of the user.

In contrast, if the CSS file is placed at the end, the page loads the complete DOM and requests the CSS file, then renders the entire DOM tree and presents it to the user. From the user's perspective, before the css file is completed, the whole page is in the white screen state, and the white screen is a behavior of the browser. David Hyatt's explanation is as follows:

Rendering the dom tree is a waste before the style tree is fully loaded, because after the style tree is loaded, it will be rendered again, and the FOUC (no style content flashing) problem occurs.

In addition, use link instead of @ import to introduce the css style sheet. Even if the style introduced by @ import is written in the header, it will be loaded at the end of the document.

6. Put the JS file at the end

  HTTP requests are in parallel, and the number of parallel downloads in different browsers is different (2, 4, or 8). Parallel downloads increase the speed of HTTP requests. Putting the JS file in the header will not only block the download of the subsequent files, but also block page rendering.

  Why? There are two reasons:

JavaScript files may contain document. write to modify the page content. Therefore, the page can be rendered only after the script is executed.

Different JS files may have dependencies regardless of their size. Therefore, they must be executed in order. Therefore, parallel download is prohibited when a script is loaded.

Therefore, the best way is to place the js file at the end and wait until all visualization components on the page are loaded before sending requests to improve the user experience.

The above is a small part of the JavaScript suggestions for improving the website performance (I), I hope to help you, if you want to learn more, please stay tuned to the help house. In the next article, I will introduce some suggestions for improving the website performance by using javascript (2)