14 Principles of high-performance website construction

 

Abstract: This article is a summary of the high-performance website construction after the author reads the "high-performance website construction Guide", a total of 14 points.

Today, I roughly browsed "High Performance Web Sites". The Chinese version of this book is the high-performance website construction guide. This book also provides the Even Faster Web Sites, an advanced guide for high-performance website construction.

This book provides 14 principles for improving website performance. Each principle is a separate chapter with examples. Most of these principles are very practical and suitable for site architects and front-end engineers. It makes more sense for front-end engineers.

This is the original version. I have little practical experience in Web development and have been in a hurry. As a result, there may be omissions and improper expressions. I hope that the majority of users will not correct me.

Principle 1: Reduce the number of HTTP requests

It takes time to construct a request and wait for a response. Therefore, the fewer requests, the better. The overall idea of reducing requests is to merge resources and reduce the number of files required to display a page.

1. Image Map

By setting the usemap attribute of the label and using the <map> label, you can split multiple areas on an image and point to different links. The number of requests is reduced compared to the number of requests that are constructed by using multiple images.

2. CSS Sprite (CSS texture integration/texture combination/texture location)

Set the background-position style of the element. It is generally used for interface icons. For typical examples, refer to the small buttons above the TinyMCE editor. In essence, multiple small images are cropped from a unified big image by different offsets. In this way, the buttons on the interface are loaded only once (one request for a larger image), thus reducing the number of HTTP requests.

3. Inline Image (Inline Image)

In src, the image information is placed directly without specifying the URL of the external image file. For example, src = "data: image/gif; base64, R0lGODlhDAAMAL..." is useful in some special situations (for example, a small image is only used on the current page ).

Principle 2 use multi-line CDN

You can access your site through multiple lines (such as China Telecom, China Unicom, and China Mobile) and multiple geographic locations (North, South, and West), so that all users can access your site quickly.

Principle 3 Use HTTP Cache

Add a long Expires header to resources that are not updated frequently (such as static graphs). Once these resources are cached, they will not be transmitted again for a long time.

Principle 4 Gzip Compression

Use Gzip to compress HTTP packets, reduce the volume and reduce the transmission time.

Principle 5: place the style sheet at the front of the page

Load the style sheet first, so that the page rendering starts earlier, giving the user the feeling that the page loading is faster.

Principle 6 place the script at the end of the page

Cause 5: process the page display first, and the page rendering is completed earlier, while the script logic is executed later. This gives the user the feeling that the page loading is faster.

Principle 7 avoid using CSS expressions

Complex JavaScript script logic, DOM search, and selection operations can reduce page processing efficiency.

Principle 8 use JavaScript and CSS as external resources

This seems to be contrary to the merging idea in principle 1, but it is not: consider that each page introduces a public JavaScript Resource (such as a JavaScript Library such as jQuery or ExtJS ), for the performance of a single page, the inline (JavaScript embedded in HTML) page will be more than external (using the <script> label to introduce) page loading is faster (because of the small number of HTTP requests ). However, if many pages introduce this public JavaScript resource, the inline scheme will cause repeated transmission (because this resource is embedded in each page, therefore, this part of resources must be transmitted every time you open a page, resulting in a waste of network transmission resources ). This problem can be solved by referencing such resources independently.

Because JavaScript and CSS are relatively stable, we can set a long expiration time for the corresponding resources (refer to principle 3 ).

Principle 9 Reduce DNS Lookup

The author provides the following suggestions:

1.Use Keep-Alive to Keep the connection

If the connection is disconnected, the next connection will require DNS lookup. Even if the corresponding domain name-IP ing has been cached, searching will take some time.

2.Domain Name reduction

Each time a new domain name is requested, different domain names need to be searched through DNS, And the DNS Cache cannot play a role. Therefore, we should try to organize the site under a unified domain name to avoid using multiple subdomains.

Principle 10: compress your JavaScript

Use the JS compression tool to compress your JavaScript, which is very effective. Let's look at two different release versions of jQuery to see the difference:

JQuery code for http://code.jquery.com/jquery-1.6.2.js reading, 230KB
Compressed jQuery code for http://code.jquery.com/jquery-1.6.2.min.js (for actual deployment), 89.4KB

Principle 11 avoid redirection

One redirection means that an additional HTTP request is added before you actually access the page you want to see (the client initiates an HTTP request → the HTTP server returns a redirect response → the client initiates a request to the new URL → HTTP content returned by the server, the underline part is an extra request, so it consumes more time (it gives people a slower response ). Therefore, do not use redirection unless necessary. Several "necessary" situations:

1. Avoid URL invalidation

After the old site is migrated, in order to avoid invalid old URLs, requests for old URLs are usually redirected to the corresponding address of the new system.

2. URL beautification

Conversion between readable URLs and actual resource URLs. For example, for Google Toolbar, users can remember http://toolbar.google.com, a semantic address for humans, but it is hard to remember http://www.google.com/tools/firefox/toolbar/ft3/intl/en/index.htmlthis real resource address. Therefore, it is necessary to retain the former and redirect the request to the latter.

Principle 12 remove duplicate scripts

Do not repeatedly introduce the same script in a page. For example, if both scripts B and C depend on A, repeated references to A may exist on pages that use B and C. Solution: manually check dependencies for simple sites and eliminate repeated introduction. For complex sites, you need to build your own dependency management/version control mechanism.

Principle 13 handle ETag with caution

ETag is another HTTP Cache method except Last-Modified. Use the hash method to identify whether the resource is modified. However, ETag has some problems, such:

1. inconsistency: The ETag formats defined by different Web servers (such as Apache and IIS) are different.

2. The ETag calculation is unstable.(Due to too many factors), for example:

1) The ETag calculated by the same resource on different servers is different, while more than one server provides services for large Web applications. As A result, the cached resources of the client on server A are still effective, the next request to B is considered invalid due to the difference in ETag, resulting in repeated transmission of the same resource.

2) The resources remain unchanged, and the ETag changes due to some other factors, such as configuration file changes. The direct consequence is the large-scale Cache failure on the client after the system is updated, resulting in a significant increase in transmission volume and a reduction in site performance.

The author's suggestion is: you can either improve the existing ETag calculation method based on your application characteristics, or simply use the ETag instead of the simplest Last-Modified.

Principle 14 Use HTTP Cache in Ajax

Ajax is an asynchronous request that does not block your current operations. when the request is complete, you can see the result immediately. However, Asynchronization does not mean instantaneous completion, nor can it tolerate the infinite amount of time it takes to complete. Therefore, we also need to pay attention to the performance of Ajax requests. There are a lot of Ajax requests accessing some relatively stable resources, so don't forget to make good use of the HTTP Cache mechanism for Ajax requests. For details, see principles 3 and 13.

From: Bin blog