14 tips to improve the efficiency of Web pages experience Exchange

Content again rich site, if slow to inaccessible is meaningless; SEO do a good site, if the search spider can not catch is useless; UE design of the re-humanized site, if the user can not see is also empty talk.

What is the most basic thing about the website?
--Content? SEO (Search engine optimization)? UE (user experience)? It's all right! It's speed!
Content again rich site, if slow to inaccessible is meaningless; SEO do a good site, if the search spider can not catch is useless; UE design of the re-humanized site, if the user can not see is also empty talk.
Therefore, the efficiency of Web pages is definitely the most noteworthy aspect. How can you improve the efficiency of a Web page? Steve Souders (Steve Souders's information http://www.php.cn/) proposes 14 guidelines for improving Web page efficiency, and these guidelines will be the rationale for the YSlow tools we describe in our 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 each of these guidelines, and I will explain in detail the guidelines that are closely related to developers. Little Brother Personal technology is limited, mistakes and ignorance is unavoidable, but also please expert guidance.

First: Make fewer HTTP requests as much as possible to reduce the number of request requests for HTTP.

80% of the user response time is wasted on the front end. And these times are mainly due to download pictures, stylesheets, JavaScript scripts, Flash and other files. Reducing the number of request requests for these resource files will be the focus of improving the efficiency of your Web page display.
There seems to be a contradiction here, that is, if I reduce a lot of pictures, styles, scripts or flash, then the page is not bare, how ugly? In fact, this is a misunderstanding. We are only saying that as much as possible, we do not say that we can not use it completely. The number of request requests to reduce these files, and of course some tips and suggestions:

1: Replace multiple small pictures with a large picture.

This is a bit of a reversal of traditional thinking. We used to think that the download speed of multiple small images is less than the download speed of a large picture. But now the results of the analysis of multiple pages using the HttpWatch tool show that this is not the case.
The first picture is an analysis of a large picture of a size of 40528bytes 337*191px.
The second picture is an analysis of a small picture of a 280*90px size of 13883bytes.

Analysis results of a large picture of a size of 40528bytes 337*191px (click on the image to see the full large picture)

Analysis results of a small picture of a size of 13883bytes 280*90px (click on the image to see the full large picture)

The first large picture takes time:
blocked:13.034s
send:0.001s
wait:0.163s
receive:4.596s
ttfb:0.164s
network:4.760s
Power consumption: 17.795s
The real time spent transferring large files is reveive time, that is, 4.596s, most of the time is used to retrieve the cache and determine whether the link is valid blocked time, which costs 13.034s, accounting for 73.2% of the total time.

The second small picture takes time:
blocked:16.274s
Send: Less than 0.001s
wait:0.117s
receive:0.397s
Ttfb:0.118s
Network:0.516s
Power consumption: 16.790s
The real time spent transferring files is reveive time, which is 0.397s, which is much smaller than the 4.596s of a large file. But his blocked time is 16.274s, accounting for 97% of the total time.

If this data is not enough to persuade you, let's take a look at this picture below. This lists the time spent in all the pictures in a webpage. Of course, the pictures inside are big and small, the specifications vary.

Approximately 80% of the time is used to retrieve the cache and determine whether the link is valid blocked time.

One of the reveive time that the Navy has spent on transferring files, while the front white is the blocked time to retrieve the cache and confirm whether the link is valid. The same facts as iron tell us:

• The time required for large files and small file downloads is really different, and the absolute value of the difference is small. And the amount of time it takes to download is a fraction of the total time spent.

• Approximately 80% of the time is used to retrieve the cache and determine whether the link is valid blocked time. Regardless of file size, the cost of this time is roughly the same. And the percentage of total time spent is enormous.

• A large picture of 100k total time consuming is definitely more than 4 25k of the total time spent on small pictures. And the main difference is that the blocked time of 4 small pictures is definitely greater than the blocked time of 1 large pictures.

So if it is possible to use large pictures instead of too many trivial small pictures it. This is why the turnover gate is more efficient than the sliding door realized by the picture replacement.
However, please note: It is also not possible to use too large a single picture, as that will affect the user experience. For example the use of a few megabytes of background image is definitely not a good idea.

2: Merge your CSS files.

Figure: Merging and blending

I made a mistake before, and you'll know it in a series of articles on the organization and planning of style sheets. At the time, I separated the stylesheet files for different purposes to facilitate the organization and planning of style sheets, forming different CSS files. Then refer to multiple CSS files as needed in the page. According to the guideline "minimize the number of request requests for HTTP" We know that that is really unreasonable, because that would generate more requests for HTTP request. Thus reducing the efficiency of web pages. Therefore, from the perspective of improving the efficiency of Web pages, we should still write all the CSS in the same CSS file. But the problem comes again. So how do you organize and plan style sheets well? This is indeed a contradiction. What I do now is to use two sets of versions. Edition and release. The edition still uses multiple CSS files to facilitate planning and organization. By the time you publish, you can reduce the number of HttpRequest requests by merging multiple CSS files into a single file.

3: Merge your JavaScript files.

The reason and the method of treatment above, no longer elaboration.

Article two: Use a Content Delivery Network using CDN

This looks like a very esoteric look, but as long as the combination of Chinese network characteristics, this is not difficult to understand. "North Server", "Southern Server", "Telecom Server", "Netcom server" ... These words sound so familiar and depressing. If a Beijing telecom user tries to open a Web page like "wallpaper collection" from the Guangdong netcom server, you can understand it deeply.
Given that this is not the norm for our developers, there is not much to say here.

Figure: This figure is also a bit of Chinese characteristics

Article three: Add an Expires header adding a period header

This is not the developer to control, but the role of the site server administrator. So, if you don't understand and understand as a developer, it doesn't matter. Or let the company's Web server administrator know the code.

Fourth article: gzip enabled gzip compression

This people should be more familiar with. The idea of gzip is to compress the files on the server side before transferring them. This has special effects for larger, text-only files. Since this is not a developer, but a site server administrator of the scope of work, here is not explained in detail. If you are interested in this, you can information about your company's website server managers.

Fifth: Put CSS at the top put CSS style on top of the page.

Whether HTML or XHTML or CSS is an interpreted language, not a compiled one. So CSS to the top, then the browser parsing structure, you can already render the page. This will not appear, the page structure is bare first out, and then the CSS rendering, the page suddenly gorgeous up, so it is too "dramatic" page browsing experience.

Sixth: Move Scripts to the Bottom put the script at the bottom

The reason is the same as the fifth article. Only scripts are typically used for user interaction. So if the page has not come out, the user even the page does not know what looks like, then talk about interaction is simply talking. So, the script and CSS are just the opposite, the script should be placed at the bottom of the page.

Seventh: Avoid CSS Expressions avoid using Expressions in CSS

Figure: Expressions in CSS is actually an if judgment

First of all, it is necessary to explain the CSS expressions is what a thing. In fact, it is like the if......else in other languages ... Statement. In this way, you can make simple logic judgments in CSS. To give a simple example--

<style>
Input{Background-color:expression ((this.readonly && this.readonly==true)? " #0000ff ":" #ff0000 ")}
</style>
<INPUTTYPE= "text"NAME="">
<INPUTTYPE= "text"NAME=""ReadOnly= "true">

In this way, the CSS can be rooted in a number of situations using different styles. If you are interested in this you can go to my blog to read the relevant article- "expression series in CSS" article. But the cost of expressions in CSS is extremely high. When your page needs to be judged to render a lot of elements of the effect, your browser will be in suspended animation for a long time, resulting in a very poor user experience.

Eighth: Make JavaScript and CSS External to separate JavaScript and CSS into external files

This one seems a bit contradictory to the first one. Indeed, if you are speaking from the request number of HTTP requests, it does reduce efficiency. But the reason for doing this is because of another important consideration-caching. Because the external reference files are cached by the browser, if JavaScript and CSS are larger, we separate them into external files. This way, when users browse once, these larger JS and CSS files can be cached, which greatly improves the efficiency of the user's re-visit.

Nineth: Reduce DNS lookups decrease DNS query

DNS domain name resolution system. We all know that we can remember so many URLs, because we remember the words, rather than http://www.php.cn/such things, and help us to those words and 202.153.125.45 such IP address is the DNS. So what does this one really mean for us? There are actually two articles:
1: If it is not necessary, please do not put the site on two servers.
2: Pictures, CSS files, JS files, flash files and so on, not too much scattered in different cyberspace. This is why a post that only sends a wallpaper image from a website is much faster than a post from a different site than a wallpaper image.

Tenth: Minify JavaScript and CSS Reduce the volume of JavaScript and CSS files

This is a good understanding. Remove unnecessary blank lines, spaces, and comments in your final release. Obviously the manual processing efficiency is too low, fortunately the Internet is everywhere is used to compress these things the tool. The tools for compressing JavaScript code volumes are everywhere, and I'm not listing anymore, here I'm only offering a web-tool site for compressing the volume of CSS code-http://www.php.cn/
It offers a variety of compression methods that can be adapted to a variety of requirements.

11th: Avoid redirects avoid jumping

I only read this article from the perspective of web developers. So what can we read? 2 O'Clock--
1: "This domain name has expired, 5 seconds later, the page will jump to the http://www.php.cn/page", this sentence looks really familiar. But, I wonder, why not directly link to that page?
2: Some link address please write it more clearly. For example: Write http://www.php.cn/ as http://www.php.cn/ (Note the last "/" symbol). Yes, these two URLs have access to my blog, but, in fact, they are different. The result of the http://www.php.cn/ is a 301 response, which will be re-directed to http://www.php.cn/ . But obviously, there's a lot of wasted time in the middle.

12th Remove Duplicate Scripts Remove Duplicate script

Picture: Say to repeat "No!" ”

The principle is very simple, but really in the work, many people are because of "project time Tight", "Too Tired", "early planning is not good" ... That's a reason to stall the past. You, you can really find a lot of reasons not to deal with these redundant script code, if your site does not require higher efficiency and post-maintenance.
It is this, I remind you, some JavaScript framework, JavaScript package must be used with caution. At least ask: using this JS kit in the end to give us a lot of convenience, improve how much work efficiency. Then, compare it with the negative effects it has caused by redundant, repetitive code.

13th: Configure etags Configure your Entity label

First of all, let's talk about the ETag. Etag (Entity Tags) entities tab. This tag is a bit different from the tag cloud that you often see online. This etag is not for the user, but for the browser cache. The etag is a mechanism by which the server tells the browser to cache whether the content in the cache has changed. With the ETag, the browser will know that the contents of the cache are not up-to-date and need not be re-downloaded from the server. This is somewhat similar to the concept of "last-modified". It's a pity that as a web developer there is nothing to do. He is still the domain of Web server personnel. If you are interested in this, you can consult your company's website server administrator.

14th: Make Ajax cacheable The above guidelines also apply to Ajax

Figure: The use of Ajax should be appropriate

Ajax seems to be a bit of a myth now, as if the Web page as long as Ajax, then there is no efficiency problem. In fact, this is a misunderstanding. Poor use of Ajax will not make your Web pages more efficient, but can reduce the efficiency of your pages. Ajax is really a good thing, but please don't overdo it. You should also consider the above guidelines when using AJAX.

Postscript:

Of course, these are just theoretical guidelines for you to refer to. The specific situation is still to be treated concretely. Theories and norms are only used to guide the real work, but it is absolutely not rote hard sets.

