Turn: how to improve the efficiency of web pages (Part 1)-14 guidelines for improving the efficiency of web pages

What is the most basic thing about a website?

What is the most basic thing about a website?
-- Content? SEO (Search Engine Optimization )? UE (User Experience )? None! Yes speed!
Websites with rich content are meaningless if they are too slow to be accessible. Seo is a good website, and it is useless if the search spider cannot catch it. ue is designed to be a user-friendly website, it is also empty talk if the user cannot even see it.
Therefore, the efficiency of web pages is definitely the most noteworthy aspect. How can we improve the efficiency of a webpage? Steve Souders (Steve Souders's profile http://www.oreillynet.com/pub/au/2951) proposed 14 guidelines for improving web page efficiency, which will also be the theoretical basis of the yslow tool we will introduce in the next article:

• Make fewer HTTP requests
• Use a content delivery network
• Add an Expires header
• Gzip Components
• Put CSS at the top
• Move scripts to the bottom
• Avoid CSS expressions
• Make JavaScript and CSS external
• Reduce DNS lookups
• Minify Javascript
• Avoid redirects
• Remove duplicate scripts
• Configure etags
• Make Ajax cacheable

Here we will explain these principles one by one, and I will explain in detail the principles that are closely related to developers. My younger brother has limited technical skills, and mistakes and ignorance are inevitable. Please give your advice.

Article 1: make fewer HTTP requests to minimize the number of HTTP request requests.

80% of user response time is wasted on the frontend. These times are mainly caused by downloading images, style sheets, JavaScript scripts, flash and other files. Reducing the number of request requests for these resource files will be the key to improving the webpage display efficiency.
There seems to be a conflict here, that is, if I have reduced a lot of images, styles, scripts, or flash, then the web page will not be bald, so ugly? This is a misunderstanding. We just want to reduce the number as much as possible, but we do not mean it is completely unusable. There are also some tips and suggestions for reducing the number of request requests for these files:
 

1: Use a large image to replace multiple small images.

This is indeed somewhat Revolutionizing Traditional thinking. In the past, we thought that the download speed of multiple small images would be lower than that of a large image. However, the analysis results of multiple pages using the httpwatch tool show that this is not the case.
The first graph is the analysis result of a large image with a size of 337 * 191px of 40528bytes.
The second figure shows the analysis result of a small image with a size of 280 * 90px of 13883bytes.

The first large image takes the following time:
Blocked: 13.034 s
Send: 0.001 s
Wait: 0.163 s
Receive: 4.596 s
Ttfb: 0.164 s
Network: 4.760 s
Power Consumption: 17.795 s
The real time spent for transferring large files is reveive time, that is, 4.596 S. Most of the time is the blocked time used to retrieve the cache and determine whether the link is valid, for 13.034 S, 73.2% of the total time.

The second small image takes the following time:
Blocked: 16.274 s
Send: less than 0.001 s
Wait: 0.117 s
Receive: 0.397 s
Ttfb: 0.118 s
Network: 0.516 s
Power Consumption: 16.790 s
The real time spent for transferring files is reveive time, that is, 0.397 s, which is indeed much smaller than the 4.596s s of the large files just now. However, his blocked time is 16.274 S, accounting for 97% of the total time.

If the data is not enough to convince you, let's take a look at the figure below. The time spent in all images on a webpage is listed here. Of course, the images in the image are large and small, with different specifications.

The navy blue indicates the reveive time of the file to be transferred, and the previous White indicates the blocked time for retrieving cache and verifying whether the link is valid. The fact that iron is the same tells us:

• The time required for downloading large and small files is indeed different, and the absolute value of the difference is not big. In addition, the time required for download accounts for a small proportion of the total time consumed.
• About 80% of the time is the blocked time used to retrieve the cache and determine whether the link is valid. Regardless of the file size, the time is roughly the same. In addition, the proportion of the total time consumption is extremely large.
• The total time consumption of a K large image is definitely greater than the total time consumption of four 25 k small images. The main difference is that the blocked time of four small images is definitely greater than the blocked time of one large image.

Therefore, if you want to use large images instead of too many trivial pictures. This is why the efficiency of turning the door is higher than that of the sliding door implemented by image replacement.
However, please note that too many images cannot be used, because this will affect the user experience. For example, it is definitely not a good idea to use a few megabytes of background images.

2: Merge your CSS files. I made a mistake before. You will know it in my series of articles on "organization and planning of Style Sheets. At that time, in order to facilitate the organization and planning of style sheets, I separated the style sheet files for different purposes to form different CSS files. Reference multiple CSS files as needed on the page. According to the "Minimize the number of HTTP request requests as much as possible" principle, this is indeed unreasonable, because it will generate more HTTP request requests. This reduces the efficiency of web pages. Therefore, from the perspective of improving the webpage efficiency, we should write all CSS in the same CSS file. But the problem comes again. So how can we organize and plan style sheets well? This is indeed a contradiction. My current practice is to use two sets of versions. Edit and release editions. The Edit version still uses multiple CSS files for planning and organization. At the time of release, multiple CSS files will be merged into one file to reduce the number of httprequest requests.

Figure: Merge and merge
3: Merge your JavaScript files.

The reason and solution are the same as above.

 

Article 2: Use a content delivery network to use CDN

This looks very esoteric, but it is not hard to understand as long as it integrates the network characteristics of China. "North server", "Southern server", "Telecom server", "Netcom server "...... These words sound so familiar and depressing. If a telecom user in Beijing tries to open a webpage similar to wallpaper collection from Guangdong's Netcom server, you will be able to have a deep understanding.
Since this is not the principle that our developers can do, we will not say much here.

Figure: This figure is somewhat Chinese

 

Article 3: add an Expires header to add a periodic Header

This is not controlled by developers, but the responsibility of the website server administrator. Therefore, it does not matter if you do not understand it as a developer. Tell the website server administrator about this rule.

Article 4: gzip components enabling gzip Compression

You should be familiar with this. The idea of Gzip is to first compress the file on the server and then transmit it. This has special effects on large text files. As this is not a developer, but the work scope of the website server administrator, I will not explain it in detail here. If you are interested in this, you can information your company's website server administrator.

Article 5: Put CSS at the top place the CSS style above the page.

Both HTML, XHTML, and CSS are interpreted languages, rather than compiled languages. So when CSS is above, the browser can parse the structure and render the page. In this way, the page structure will not appear, the page structure will be bald first, then CSS rendering, the page will suddenly become gorgeous, so it is too "dramatic" Page browsing experience.

Article 6: Move scripts to the bottom to put the script at the bottom

The reason is the same as that in article 5. Scripts are generally used for user interaction. Therefore, if the page is not displayed and the user does not even know what the page looks like, talking about interaction is nothing more than a conversation. Therefore, the script and CSS are the opposite. The script should be placed at the bottom of the page.

Article 7: Avoid CSS expressions avoid using expressions in CSS

 

Figure: Expressions in CSS is actually an if judgment.
 

First, it is necessary to explain what CSS expressions is. In fact, it is like if... in other languages ...... Else ...... Statement. In this way, simple logic judgment can be performed in CSS. A simple example --

<Style>
Input {background-color: expression (this. readonly & this. readonly = true )? "# 0000ff": "# ff0000 ")}
</Style>
<Input type = "text" name = "">
<Input type = "text" name = "" readonly = "true">

In this way, CSS can use different styles in different situations. If you are interested in this, you can go to my blog and read the related article "expression series in CSS". However, the cost of expressions in CSS is extremely high. When your page needs to be rendered with many elements based on judgment, your browser will remain in the suspended state for a long time, thus bringing users a very poor user experience.

Article 8: Make JavaScript and CSS external separate JavaScript and CSS into external files

This article seems to be in conflict with the first article. Indeed, in terms of the number of HTTP request requests, this is indeed a reduction in efficiency. But the reason for doing so is another important factor-caching. Because external reference files will be cached by the browser, when JavaScript and CSS are large, we will separate them into external files. In this way, as long as the user browses the file once, these large JS and CSS files can be cached, thus greatly improving the efficiency of the user's re-access.

Article 9: Reduce DNS lookups reduces DNS queries

DNS domain name resolution system. We all know that we can remember so many URLs because we remember words instead of http: // 202.153.125.45, DNS is used to connect the words with IP addresses such as 202.153.125.45. So what is the true guiding significance of this Article for us? There are actually two:
1: If not required, do not put the website on two servers.
2: images, CSS files, JS files, Flash files, and so on the webpage should not be too scattered in different network spaces. This is why the post that sends only one wallpaper image on a website is much faster than the post display of wallpaper images from different websites.

Article 10: Minify JavaScript and CSS reduces the size of JavaScript and CSS files

This is easy to understand. Remove unnecessary blank lines, spaces, and comments in your final release. Obviously, manual processing is too inefficient. Fortunately, tools are everywhere on the Internet to compress these things. Compressed JavaScript code volume tools are everywhere, I will not list, here I only provide an online tool site for compressing CSS code volume-http://www.cssdrive.com/index.php/main/csscompressor
It provides multiple compression methods and can meet various requirements.

Article 3: Avoid redirects avoids redirection

I will only interpret this article from the perspective of Web developers. So what can we interpret? 2 --
1: "This domain name has expired. After five seconds, the page will jump to the http://www.xxxxxx.com/index.html page. This is a very familiar sentence. However, I am wondering, why not directly link to that page?
2: write some link addresses more clearly. For example: Write http://justinyoung.cnblogs.com/as a http://justinyoung.cnblogs.com (note the last '/' symbol ). Indeed, both websites can access my blog, but in fact they are different. The result of the http://justinyoung.cnblogs.com is a 301 response, which is directed back to the http://justinyoung.cnblogs.com /. However, it is obvious that it is a waste of time.

12th remove duplicate scripts The principle of this rule is simple, but in my work, many people are "too busy", "Too tired", and "not well planned at the beginning "...... Such a reason has passed. You can find a lot of reasons not to deal with the redundant script code, if your website does not require higher efficiency and later maintenance.
I would like to remind you that some JavaScript frameworks and JavaScript packages must be used with caution. At least let's have a question: how much convenience does this JS kit help us and how much efficiency is improved. Then, compare it with the negative effects of redundant and repetitive code. Article 3: Configure etags configure your object tag

First, let's talk about etag. Etag (entity tags) entity tag. This tag is a little different from the tag cloud that you often see on the Internet. This etag is not used for users, but for browser cache. Etag is a mechanism used by the server to tell the browser whether the cached content has changed. Through etag, the browser can know whether the content in the current cache is up-to-date and does not need to be re-downloaded from the server. This is similar to the concept of "last-modified. Unfortunately, Web developers cannot do anything about this. He is still a website server employee. If you are interested in this, you can consult your company's website server administrator.

Article 3: Make Ajax cacheable rules apply to Ajax The current Ajax seems a bit mythical, as if the webpage only needs Ajax, then there will be no efficiency problems. In fact, this is a misunderstanding. Poor use of Ajax will not make your webpage more efficient, but will reduce your webpage efficiency. Ajax is indeed a good thing, but never overdo it. When using Ajax, consider the above principles. Postscript:

Of course, the above are just the theoretical principles for your reference. The specific situation should be treated as needed. Theories and principles are just used to guide practical work, but they are hard to remember.