Yahoo page Optimization 14: The theoretical basis of yslow tools

website | optimization | Yahoo |yslow

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

80% of user response time is wasted on the front end. These times are mainly caused by downloading pictures, style sheets, JavaScript scripts, flash files, and so on. Reducing the number of requests requested for these resource files will be a key to improving the efficiency of Web page display.

There seems to be a contradiction, is that if I reduced a lot of pictures, styles, scripts or flash, then the page is not bare, how ugly? In fact, this is a misunderstanding. We're just saying as much as possible, and not saying that it's completely out of use. The number of request requests for these files is reduced, and there are 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 pictures would be less than the download speed of a large picture. But now the results of the analysis of multiple pages using the HttpWatch tool indicate that this is not the case.

The first picture is an analysis of a large picture of the size of a 40528bytes 337*191px.
The second picture is an analysis of a small picture of the size of a 13883bytes 280*90px.

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

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

The first large picture takes time for:
blocked:13.034s
send:0.001s
wait:0.163s
receive:4.596s
ttfb:0.164s
network:4.760s
Power consumption: 17.795s

The actual time spent transferring large files is reveive time, or 4.596s, most of the time is used to retrieve the cache and determine the validity of the link blocked time, for 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 to transfer files is reveive time, that is, 0.397s, which is really much smaller than the 4.596s of the big file. But his blocked time was 16.274s, which accounted for 97% of the total time.

If that's not enough to convince you, let's take a look at this picture below. Here is a list of the time spent on all the pictures in a Web page. Of course, there are a lot of pictures of small, different specifications.

More than 80% of the time is used to retrieve the cache and determine whether the link is valid blocked time. The reveive time spent in the blue for transferring files, and the front white blocked time for retrieving the cache and confirming that the link is valid. Iron the same fact tells us:

The time required for large and small file downloads is indeed different, and the difference is not absolute. And the amount of time spent downloading is very small.

More than 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 proportion of the total time spent is enormous.

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

So if you can still use large pictures to replace too many trivial small pictures. This is why the efficiency of the flip door is higher than the sliding door of the picture replacement.

However, note that you cannot use too large a single picture, because that will affect the user experience. For example, the use of a few megabytes of background images is definitely not a good idea.

2: Merge your CSS files.

Figure: Merging and merging I made a mistake before, and you will see it in my series of articles on the organization and planning of the style sheet. At the time, I separated the stylesheet files for different purposes and formed different CSS files to facilitate the organization and planning of style sheets. Then, on the page, refer to multiple CSS files as needed.

based on the "Minimize HTTP request requests as possible" guideline, we know that that would be unreasonable, because that would result in more HTTP request requests. Thus reducing the efficiency of the Web page. So, from the point of view 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 your stylesheets well? This is indeed a contradiction. My current approach is to use two sets of versions. Edition and release. The edit version still uses multiple CSS files for easy planning and organization. And wait until the release, and then merge multiple CSS files into a file, so as to reduce the number of HttpRequest requests.