How to improve the load performance of the website. Website construction The company summarized the following aspects according to its own experience, hoping to give some help to the novice webmaster.
1. Reduce the number of HTTP requests
It takes time to construct a request and wait for a response, so fewer requests are better. The general idea of request reduction is to combine resources and reduce the number of files required to display a page.
1) . Image mapping
By setting the usemap attribute of the tag and using the tag, you can cut multiple areas in the image and point to different links. Compared with using multiple images to build links separately, the number of requests is reduced.
2）. CSS Sprite (CSS Map Integration/Map Flattening/Map Positioning)
This is achieved by setting the background position style of the element. For general interface icons. Typical examples can refer to the small buttons at the top of TinyMCE editor. In essence, multiple small images are cut from a unified large image through different offsets. In this way, many buttons on the loading interface actually need to be requested only once (requesting the large image once), thus reducing the number of HTTP requests.
3) . Embedded image (embedded image)
Instead of specifying the URL of the external image file in src, the image information is directly put in. For example, src="data: image/gif; Base64, R0lGODlhDAAMAL..." is very useful in some special cases (for example, a small image is only used on the current page).
2. Use multi wire CDN
Provide access to multiple lines (such as China Telecom, China Unicom, and China Mobile) and multiple geographical locations (north, south, and west) for your site, so that all users can quickly access it.
3. Use HTTP cache
Add longer expired header information to resources that are not updated frequently, such as static graphs. Once these resources are cached, they will not be transmitted repeatedly for a long time in the future.
4. Use Gzip compression
Using Gzip to compress HTTP messages can reduce the volume and transmission time.
5. Place the style sheet in front of the page
Load the style sheet first, so that the page rendering can start earlier, giving the user a sense of faster page loading.
6. Place the script at the end of the page
Similarly, 5, the page display is processed first, the page rendering is completed early, and the script logic is executed late, giving the user a sense of faster page loading.
7. Avoid CSS expressions
The overly complex JavaScript script logic, DOM search and selection operations will reduce the efficiency of page processing.
8. Use JavaScript and CSS as expansion resources
This seems to violate the consolidation idea in Principle 1, but it is not true: consider that every page introduces a common JavaScript resource (such as jQuery or ExtJS JavaScript library). From the performance of the page alone, the loading speed of the inline (that is, JavaScript is embedded in HTML) page is faster than that of the external (introduced with tags) page (because it has fewer 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, this part of the resource will be transmitted every time a page is opened, causing a waste of network transmission resources). This problem can be solved through independent external use of such resources.
Since JavaScript and CSS are relatively stable, we can set a longer validity period for their corresponding resources (refer to Principle 3).
9. Reduce DNS lookup
The author's suggestions are:
1) . Use Keep Alive to stay in touch.
If the connection is disconnected, DNS lookup will be performed next time. Even if the corresponding domain name IP mapping has been cached, the lookup will take some time.
2) . Reduce domain name
Each time you request a new domain name, you need to search for a different domain name through DNS, and DNS cache cannot work. So try to organize the site under a unified domain name and avoid using too many subdomains.
10. Compress your JavaScript
Use the JS compression tool to compress your JavaScript. Very effective. Look at the two different distributions of jQuery and see their differences:
H of jQuery code ttp://code.jquery.com/jquery-1.6.2.js Version, 230KB
H ttp://code.jquery.com/jquery-1.6.2.min.js Compressed jQuery code (for actual deployment), 89.4KB
11. Try to avoid redirection
Redirection refers to adding an additional round of HTTP requests before you actually visit the page you want to see (the client initiates an HTTP request → the HTTP server returns a redirect response → the client initiates a request for a new URL → the HTTP server returns the content, and the underlined part is an additional request), so it takes more time (giving the impression that the response is slow). So don't use redirection unless necessary. Several "necessary" situations:
1) . Avoid invalid URLs
After the old site is migrated, in order to avoid the invalidation of the old URL, the request for the old URL is usually redirected to the corresponding address of the new system.
2）. URL beautification
Convert between the readable URL and the actual resource URL. For example, Google Toolbar, what users remember is //toolbar.google.com , an address that has semantic meaning for human beings, but is difficult to remember //www . Google . com/tools/Firefox/Toolbar/FT3/intl/en/index . Html, the real resource address. Therefore, the former should be retained and requests for the former should be redirected to the latter.
12. Deleting duplicate scripts
Do not repeat the same script on one page. For example, if script B and C both depend on A, then repeated references to A may appear in the pages where B and C are used. Solution: For simple sites, manually check the dependency to eliminate repeated introductions; For complex sites, you need to establish your own dependency management/version control mechanism.
13. Handle electronic labels carefully
ETag is another HTTP caching method besides Last Modified. Determines whether the resource has been hash modified. But ETag also has some problems, such as:
1) . Inconsistent: different Web servers (Apache, IIS, etc.) define different ETag formats.
2）. The calculation of ETAG is unstable (due to too many factors), for example:
1) The etags calculated for the same resource on different servers are different. Large Web applications are usually served by multiple servers, which leads to the fact that the resources cached by the client on server A are obviously still valid, but in the next request B, they will be considered invalid due to different etags, resulting in repeated transmission of the same resource.
2) The resources remain unchanged, but ETag changes due to some other factors, such as configuration file changes. The direct result is that after the system is updated, the client cache fails on a large scale, resulting in a large increase in transmission and a decline in site performance.
The author's suggestion is: either improve the existing ETag calculation method according to your application characteristics, or simply replace ETag with the simplest Last Modified.
14. Using HTTP caching in Ajax
Ajax is an asynchronous request. It will not block your current operation. When the request is completed, you can see the results immediately. However, asynchrony does not mean that it can be completed immediately, nor does it mean that it needs infinite time to complete. Therefore, you should pay attention to the performance of Ajax requests. Many Ajax requests access relatively stable resources, so don't forget to use the HTTP caching mechanism for Ajax requests. See principles 3 and 13 for details.
