High-performance Web site Building Guide: 14 Principles for performance improvement

Intermediary transaction http://www.aliyun.com/zixun/aggregation/6858.html ">seo diagnose Taobao guest cloud host technology Hall

Today I have a general view of the high configured Web Sites. The Chinese version of this book is the "High performance Web site Building guide." This book has a further in-depth study of some of the issues of the Advanced chapter "Evan Faster Web Sites", the translation of "High-performance Web site Building Advanced Guide." This book gives 14 Web site performance improvement principles, each principle independent, with examples. Most of these principles are very useful for site architects and front-end engineers. The significance of the front-end engineers is greater. This is the original. I have a lack of practical experience in web development, coupled with a hasty look, there may be omissions, improper presentation, I hope that the vast numbers of netizens do not hesitate to correct.

Principle 1 reduce the number of HTTP requests

Constructing a request and waiting for a response takes time, so fewer requests are better. The overall idea of reducing requests is to combine resources to reduce the number of files needed to display a page.

1. Image Map

By setting the Usemap property of <img> label and using <map> tag, you can cut multiple areas on a picture to point to different links. The number of requests is reduced compared to using multiple pictures to construct a link.

2. CSS Sprite (CSS texture integration/tile mosaic/Map positioning)

Do this by setting the background-position style of the element. Generally used for interface icons. Typically, you can refer to the small buttons above the TINYMCE editor. The fact that multiple small graphs are cropped from a unified larger image through a different offset means that many of the buttons on the load interface actually reduce the number of HTTP requests as long as they are requested once (request a larger image).

3. Inline image (inline picture)

In the src of <img> do not specify the URL of the external picture file, but directly put the picture information into. For example, src= "Data:image/gif;base64,r0lgodlhdaamal ..." is useful in special cases (for example, a small picture is used only on the current page).

Principle 2 using multi-line CDN

For your site to provide a variety of lines (such as domestic telecommunications, unicom, mobile), multiple geographical location (north, south, west) access, so that all users can quickly access.

Principle 3 Using HTTP Cache

Add longer expires header information to resources that are infrequently updated, such as static graphs, which, once cached, can no longer be replicated over a long period of time.

Principle 4 using GZIP compression

Use gzip to compress HTTP messages, reduce volume, and reduce transmission time.

Principle 5 Place the style sheet in the front of the page

The style sheet is loaded first so that the page rendering starts early and gives the user a quicker feel to load the page.

Principle 6 Place the script at the end of the page

The reason for the same 5, the first processing of the page display, page rendering earlier completed, and the script logic later execution, so that the user page load faster feeling.

Principle 7 Avoid the use of CSS expressions

Overly complex JavaScript scripting logic, Dom lookup, and Selection operations reduce page processing efficiency.

Principle 8 use JavaScript and CSS as an outreach resource

This seems to contradict the idea of merging in principle 1, but it doesn't: consider each page introducing a common JavaScript resource (such as jquery or a JavaScript library like JS), in terms of the performance of a single page, inline ( The JavaScript embedded HTML page will be faster to load than the external (introduced with <script> tag) page (because of its fewer HTTP requests). But if a lot of pages are introduced into this public JavaScript resource, then the inline solution will cause a repeat transfer (because the resource is embedded in each page, so each time a page is opened to transfer this part of the resources, resulting in the waste of network transport resources). This problem can be solved by the independent reference of this resource.

Because JavaScript and CSS are relatively stable, we can set a longer expiration period for their corresponding resources (Reference principle 3).

Principle 9 Reduce DNS Lookup

The author's recommendations are:

1. Use keep-alive to keep the connection

If the connection is disconnected, then the next connection will perform a DNS lookup, even if the corresponding domain name IP mapping has been cached, the lookup also consumes some time

2. Reduce domain name

Each request for a new domain name requires a different domain name to be found through DNS, and the DNS cache is not functioning. Therefore, you should try to organize the site under a unified domain name, avoid using too many subdomains

Principle 10 Compress your JavaScript

Use the JS compression tool to compress your JavaScript bar, very effective OH. Look at the two different distributions of jquery to see the difference:

Http://code.jquery.com/jquery-1.6.2.js read jquery code, 230KB

Http://code.jquery.com/jquery-1.6.2.min.js compressed jquery code (for actual deployment), 89.4KB

Principle 11 Avoid redirection as much as possible

A redirect means adding a round of extra HTTP requests before you actually access the page you want to see (the client initiates the HTTP request →http the server returns the redirect response → The client initiates a request to the new URL →http the server returns the content, the underlined part is an additional request), So consuming more time (and giving people a more slow feeling). Therefore, do not use redirection unless necessary. Several "necessary" situations:

1. Avoid URL invalidation

After the old site is migrated, the request to the old URL is usually redirected to the corresponding address of the new system in order to avoid the old URL from being invalidated.

2. URL beautification

Converting between a readable URL and an actual resource URL, for example, for Google Toolbar, the user remembers Http://toolbar.google.com's semantically rich address, but it's hard to remember http://www.google.com/ Tools/firefox/toolbar/ft3/intl/en/index.html this real resource address. It is therefore necessary to retain the former and redirect requests to the former to the latter.

Principle 12 Removing duplicate scripts

Do not repeat the same script in one page. For example, both scripts B and C are dependent on a, so a duplicate reference to a is possible in pages using B and C. Workaround, for simple site Manual Check dependencies, eliminate duplication of introduction; for complex sites, you need to build your own dependency management/versioning mechanism.

Principle 13 Handle ETag carefully

ETag is another kind of HTTP cache means other than last-modified. The hash method is used to identify whether the resource has been modified. But there are some problems with etag, such as:

1. Inconsistency: Different Web servers (Apache, IIS, etc.) are defined in different etag formats

2. ETag calculations are unstable (due to excessive considerations), such as:

1 The same resources are calculated on different servers etag, while large Web applications are often serviced by more than one server, this causes the client to cache good resources in Server A that are still valid, and are identified as invalidated at the next request B due to etag, resulting in duplicate transfers of the same resources.

2 resources are unchanged, and due to changes in other factors, such as configuration file changes, resulting in etag changes. The direct consequence is that the system updates the client on a large scale cache failure, resulting in a large increase in transmission, site performance decline.

The author's advice is to either improve the existing ETag calculation based on your application, or simply skip the etag and switch to the simplest last-modified.

Principle 14 using HTTP Cache in Ajax

Ajax is an asynchronous request, and asynchronous requests do not block your current operations, and when the request completes, you can see the result immediately. But Asynchrony does not mean that it can be done instantaneously, nor does it mean that it can be done with an infinite amount of time. Therefore, the performance of Ajax requests also needs to be valued. There are a lot of Ajax requests to access some relatively stable resources, so don't forget to use the HTTP cache mechanism for AJAX requests, specifically see Principles 3, 13.

Original: http://www.cnblogs.com/mdyang/archive/2011/07/12/high-performance-web-sites.html