We all say that Internet content wins, but if the website's response speed is too slow, even if the content is good, it will also cause the user experience to go from "crazy-angry-always leave-bad reputation spread" to a devastating path.
- Make fewer HTTP requests-reduces the number of HTTP requests
. For example, if the home page is nested with four IFRAME, then 4 + 1 = 5 HTTP requests, if you remove IFRAME or change it to include on the server ...... There is only one HTTP request left. Therefore, it may be a good choice to directly write CSS and JS on the homepage of a website with a large traffic volume. Although this violates 8th Military rules, the rules are dead, the actual situation is live.
- Use a CDN-use a content delivery network
. Special resources use special network connections for special acceleration, for example: china Netcom, China Telecom, and CERNET respectively accelerate the development of local CDN for users in Beijing or Shanghai to accelerate access to such specific regions, download software for special acceleration, dedicated acceleration for live streaming media, static resource download acceleration (CSS/JS/html) ......
- Add an Expires header-try to make the client browser cache website resources
So you don't need to download it from the server every time, which can greatly reduce the burden on the website server, but if the resources are updated and the client is not notified in time ...... Therefore, be careful to design and change the expiration mark of your Web Resource header, so as to maximize reuse of the client browser cache without making the user unable to see the latest changes.
- Gzip components-enabling gzip compression is already recognized as a standard for website services.
Gzip can greatly compress the volume of website data packets (generally, the compression ratio can reach 85%! That is to say, a 100 k page on the server can be compressed to about 15 K and then sent to the client), uploaded to the client, and unwrapped. Generally, browsers and search engine crawlers support this function. We strongly recommend that all the text on the website be compressed using gzip, for example, JavaScript css html txt. The agent server software that supports Gzip is also excellent, such as nginx-simple and easy to use, with first-class performance, and is recommended for vomiting blood.
- Put stylesheets at the top-place the style sheet at the top of the page
. If you put the style sheet at the bottom, the page style will not be rendered in time if the network is delayed!
- Put scripts at the bottom-place the script (such as JavaScript) at the bottom of the page
. Some scripts are very large. If they cannot be downloaded for half a day on the top, the page will be blank. You certainly don't want users to watch the white screen for a long time-Neither do users! The script is usually used to respond to the page loading behavior, so it is better to download the script to the end and let the user see the page as soon as possible-this experience is better for the user. Another problem caused by the script is that it blocks the number of parallel downloads. In the HTTP 1.1 standard, it is recommended that the number of concurrent downloads for Web browsers should not exceed 2 (ie can only be 2, and other browsers such as Firefox are set to 2 by default, however, IE8 can have 6). Therefore, if you distribute image files to multiple machines, you can download more than 2 parallel files. However, when you download a script file, the browser blocks parallel image downloads. Of course, in some cases, you still have to put the script on the top, such as the computing required during page rendering.
- Avoid CSS expressions-do not use CSS (style sheet) Expressions
. First, CSS expressions are not a cross-browser tool. ie5 will support them later. other browsers are not guaranteed. The problem with CSS expressions is that they are calculated much more frequently than expected, not only when the page is displayed and scaled, that is, you may have to recalculate the page when you scroll the page or move the mouse. If the style attribute must be dynamically changed within the page cycle, it is feasible to use the event handle instead of the CSS expression. The Calculation of thousands of CSS expressions may have a great impact on the performance of your page. This may cause users to feel that the machine becomes slow after opening your page ...... Very slow. This is an example of a CSS expression:Background-color: expression (new date (). gethours () % 2? "# F00": "# 00f ");
- Make JS and CSS external-place JS scripts and CSS style sheets in separate files
. First, we can accelerate the display of the overall page. We know that the sudden transmission rate of the network is higher than the continuous transmission rate. Second, it is good for Seo, the "crawling time" that the search engine assigns to your site every day is limited. If you put the content-independent things that will inevitably be ignored by the search engine on the page, A waste of crawler time may reduce the page indexing volume of the entire site. In addition, it is also convenient for individual files to enjoy static resources "privileged CDN" and special compression processing advantages?
- Reduce DNS lookups-Reduce DNS resolution times
. We know that a domain name needs to be resolved from the DNS server to an IP address to present the page to you. Generally, a DNS resolution process consumes 20 to 20 milliseconds. the browser will not download anything under the domain name until the DNS resolution is complete. If you encounter an unscrupulous DNS service provider or the resources on your webpage are under many different domain names, the DNS resolution time will make your users want to die.
- Minify JS
-JavaScript compression as much as possible. In addition to images, audios, and videos, JS scripts are the most common resources that consume the most network bandwidth. Therefore, we need to separate them into files and place them on the CDN, it is better to compress it. Here there is an online processing JS tool, not only can compression, but also can encrypt JS: http://www.huobi3jia.com/htm/fuckjs.htm
- Avoid redirects-try to avoid URL redirection
. The main meaning here is that the background program can use forward to forward as much as possible, rather than redirect to redirect. Why? As redirection consumes more resources than the former, it is equivalent to sending a new HTTP request. The original request is cleared and a new request is constructed ...... In addition, from the SEO perspective, redirection indicates that the URL has been transferred and the URL in the browser's address bar has changed, at this time, the choice of 301 permanent redirection, or 302 temporary redirection (usually 302 by default) is a very tangled, very painful thing, increased complexity, Seo effect is hard to say.
- Remove duplicate scripts-Remove duplicate scripts
. The script is a client-side thing. It is the most difficult to get rid of the server due to page deformation. Therefore, some websites do not pay much attention to it and there are many functional repeated script functions, as we do not know, this not only consumes valuable bandwidth resources of Web applications, but also increases the computing workload of the client, and sometimes directly affects the user experience. So try to merge and abstract duplicate scripts as much as possible. Using object-oriented JS programming may be a good idea.
- Configure etags-define etags
. Don't be scared by etags, in fact, is to make full use of the client browser cache to reduce the bandwidth and load consumed by web applications, the specific implementation can refer to this article: http://www.infoq.com/cn/articles/etags
. Enabling the etags option on the Web server can effectively control the invalid client cache, but it is not conducive to the server cache. If squid is used as the proxy server cache, you can use etags instead. What are the benefits of squid as the proxy server, refer to this article: http://blog.csdn.net/kthq/archive/2009/08/17/4456385.aspx
- Make Ajax cacheable-pay attention to Ajax Cache
! Does Ajax need to be cached? Yes, you can prevent Ajax caching based on your actual needs. A timestamp is usually added for Ajax requests to avoid caching them. It's important to remember that "Asynchronous" does not imply "instantaneous". (remember that "Asynchronous" is not "instant", which is important ). You must understand that AJAX requests can still be cached even if they are dynamically generated and only work for one user.
(This article originated from csdn, author Hu Qi's blog: http://blog.csdn.net/kthq
)
Finally, a friendly gift: There is a plug-in yslow (by Yahoo.com) in Firefox, which is integrated into the famous firebug, you can use it to conveniently observe the specific performance of your website on these 14 military rules.
