14 Principles of High Performance website construction

Today I have a general view of the high performance 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 "even faster Web Sites", the translation of "High-performance Web site Building Advanced Guide."

The author introduced the above watercress link, it will not be copied over.

This book gives 14 Web site performance improvement principles, each principle independent, with examples. Most of these principles are very practical, suitable for site architects, front-end engineers. The meaning of the front-end engineers is much 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 requestsConstructing 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 MapBy setting the Usemap property of 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 the links separately.
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 those 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 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 some special cases (for example, a small picture is used only on the current page).
principle 2 Using multi-line CDNFor 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 CacheAdd 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 compressionUse gzip to compress HTTP messages, reduce volume, and reduce transmission time.
Principle 5 Place the style sheet in the front of the pageThe 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 pageThe 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 expressionsOverly complex JavaScript scripting logic, Dom lookup, and selection operations can 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's not: Considering that each page introduces a common JavaScript resource (such as jquery or a JavaScript library like ExtJS), in terms of the performance of a single page, Inline (the JavaScript embedded HTML) page will load faster 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). It is possible to solve this problem by using this resource independently of the external reference.

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, the site should be organized in a uniform domain name, avoid using too many sub-domain name 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 and know 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. A few "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 Remove 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 is complete, 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. Reprint: http://www.cnblogs.com/mdyang/archive/2011/07/12/high-performance-web-sites.html