JavaScript some suggestions on improving the performance of the website (i) _javascript skills

In the study of "High performance Web site construction Guide" This book, this article is a learning note, will be learned to clean up the things, easy to see later.

The performance Golden Rule (performance Golden) explains that only 10%~20% end user response time is spent on accepting the requested user's HTML document, and that the remaining 80%~90% time is spent on all the components referenced by the HTML document (pictures, scripts, Style sheets, etc.) on HTTP requests, end-user response time is spent on page components

--steve Sounders

1 file merging (reducing the number of HTTP requests)

CSS Sprites

The use of CSS sprites the site to use the picture merged into a picture, through the background-position, width, height control background map to use an icon, this way you can reduce multiple picture requests to a time, to generate CSS Sprites tools are also many, grunt and gulp have related plug-ins, Cssgaga is also good.

Merge JS and CSS

Like the wizard diagram, merging CSS and JS files is also a very important way to reduce HTTP requests, the integration of CSS files is currently not controversial, but for the current JS modular popular, all JS files merged into a file, as if it is a retrogression. The correct way is to adhere to the model of the compiled language, to maintain the modularity of JS, in the process of generating only the initial request to use the JS file to generate the target file.

2 Use Content Publishing Network (reduce HTTP request time)

HTTP request time Another factor is the distance between you and the Web server of the website, obviously the farther away, the longer the request time, through CDN can greatly improve this.

A CDN is a Web server distributed across a number of geographically diverse locations for more efficient publishing of content to users. The main function of CDN is to store static files to end users, and also provide downloading, security services and other functions.

3 Setting the browser cache (avoid repeating HTTP requests)

Using Expire/cache-control

Browsers can avoid repeated requests each time by using caching, and HTTP 1.0 and HTTP1.1 each have different caching implementations, Expires (1.0) and Cache-control (1.1). The Web server tells the client through expires that the cached copy of the file is used for the specified time and no longer repeats the request to the service side, for example:

Expires:thu, Dec 2016 16:00:00 GMT (GMT format)

This setting means that the cached copy can be used as of December 1, 2016, no more requests are made.

Expires this way of passing deadlines, there is a limit: Require client and server clock synchronization strictly, and HTTP 1.1 introduced Cache-control by specifying a time in seconds to specify the cache date, then do not save the limit, for example:

cache-control:max-age=31536000

This setting means that the cache time is one year, the recommended use of Cache-control, but in the case of HTTP 1.1 support, another point to note: Cache-control and expire exist at the same time, the Cache-control has a higher priority.

To configure or remove ETag

With Expire/cache-control, you can avoid using a local cache to avoid duplicate HTTP requests and increase the speed of your Web site when you use a second visit. However, when the user clicks on the browser refresh or if the expire has expired, an HTTP GET request is still made to the server, and if the file is not changed, the server does not return the entire file but returns the 304 not modified status code.

Service side to determine whether the file has changed according to two: last-modified (latest modified date) and ETag (Entity label);

ETag (Entity Tags) is introduced in HTTP 1.1, and last-modified exist at the same time to have a higher priority. The server returns the entire file and OK by comparing the ETag (If-none-match) and current ETag sent by the client, if the same returns 304 not modifed.

ETag There is a problem: when the browser sends a GET request raw component to a server, and then requests the component from another server, ETag does not match, of course, if your site hosted on a server does not exist in this problem, and now many Web sites using multiple servers, The existence of ETag greatly reduces the success rate of verification effectiveness.

The solution to this problem is to configure the ETag, remove the server Innode value only to preserve the modified timestamp and size as etag values, or remove the etag directly, using last-modified to verify the validity of the file.

4 compressed components (reduce HTTP request size)

By compressing the files transmitted by HTTP to reduce the size of the HTTP request and increase the request speed, Gzip is the most commonly used and most efficient compression method.

However, not all resource files need to be compressed, the cost of compression includes the server to spend CPU cycles to compress, and the client also needs to extract compressed files, must be combined with their own site to weigh. The vast majority of websites now compress their HTML documents, some sites choose to JS, CSS compression, almost no web site on the pictures, PDFs and other files for gzip compression, because these files have been compressed, the use of HTTP compression has been compressed things can not make it smaller. In fact, adding headers, compressing the dictionary, and verifying the response body actually makes it bigger, and it wastes the CPU.

How to turn on gzip on a Web site needs to be set up in the Web server (IIS, Nginx, Apache, and so on) that you use.

5 CSS files in header

Putting a CSS file in the header and at the tail doesn't affect the HTTP request, so it's consistent from the request time, but putting the CSS file in the header from the perspective of the user experience makes for a better user experience.

The reason is that the browser is from top to bottom parsing HTML documents, the CSS file placed in the head, the page will first make a request to the CSS file, then load the DOM tree and render it, the page will gradually appear in front of the user.

By contrast, if you place the CSS file at the end, the page loads the full Dom and then requests the CSS file, then renders and renders the entire DOM tree to the user, from the user's point of view, before the CSS file is requested to complete, the entire page is out of screen state, screen is a browser behavior, David Hyatt's explanation for it is this.

Rendering a DOM tree is a waste of time before the style tree is fully loaded, because it is rendered again after the style tree is loaded, and there is a Fouc (no style content flicker) problem.

Also note that using link instead of @import to introduce CSS style sheets, the styles introduced using @import will be loaded at the end of the document even if written in the header.

6 JS files on the tail

HTTP requests are parallel, and the number of concurrent downloads for different browsers is not the same (2, 4, or 8), and concurrent downloads increase the speed of HTTP requests. And the JS file in the header, not only will block the download of the following files and will block the page rendering.

  Why is that? There are two reasons:

JS file may exist document.write modify the content of the page, so the page will be completed after the execution of the script to render.

Different JS files, regardless of size, may have dependencies, so they must be executed in order, so concurrent downloads are prohibited when loading scripts.

So, the best way is to talk about JS files placed in the tail, and so on page all the visual components after the completion of the request, improve the user experience.

The above is a small set of JavaScript for you to introduce a few suggestions to improve the performance of the site (i), I hope to help you, if you want to know more content, please pay attention to cloud habitat community. In the next article small series to introduce JavaScript improve Web site performance optimization suggestions (ii)