The importance of front-end performance the importance of front-end performance

Welcome to my homepage. The latest article will be published on my homepage first:

Http://blog.guaidm.com/shocky/

Original book: Http://pan.baidu.com/s/1pJocRwB

In most of my web development career, I am a background engineer. In this way, I have invested a lot of energy to study and practice how to improve the performance of the project products through background optimization, such as compiler options, database indexes, and memory management. Many books spend a lot of time explaining how to improve performance in these aspects, and many people have spent a lot of time optimizing this aspect. To be honest, the time spent on many web pages from Web servers to end users is usually less than one or two of the total response time. If you really want to significantly reduce the response time of web pages, you should focus on the other pieces of content that really affect the user experience. So where is the time spent between 80% and 90%? How can we reduce it? Based on the basic principles of today's Web applications, the following sections of this book will provide 14 accelerated optimization rules in the future.

Tracking web page performance
Tracking web page performance

In order to find a performance improvement point, we must know where the user's time is spent. The chart A-1 shows the HTTP transfer when users access the Yahoo homepage (http://www.yahoo.com) using IE. Each horizontal bar is an HTML request. The first horizontal bar named HTML indicates initializing HTML documents. The browser parses HTML text and starts to download the document elements. In this example, the browser cache is empty, so all elements need to be downloaded. The download of HTML documents only takes 5% of the total response time, so the remaining 95% of the user wait time is used to download the specific elements of the document node. Of course, a very small part of the time is spent waiting for parsing HTML, scripts, and CSS, that is, the blank intervals in the two download entries in the figure.

The icon A-2 shows the second access to the same URL address using IE. HTML document initialization still takes up only 12% of the total response time, and most elements do not need to be downloaded because they are already in the browser cache.

However, during the second visit, five elements were still requested for download:

One redirection:
The redirected content has been downloaded before, but the browser still requested it again. This HTTP response result is 302 ("found" or "move temporarily "), the returned header does not contain any cached information, so the browser cannot cache the response. I will discuss HTTP in chapter B.

Three images that are not cached
The reason why the three images were requested to be downloaded is that they were not cached during the first visit. These three images are news images and AD images, so they will be frequently replaced.

A cached Image
The last HTTP request is a conditional GET request. This image has been cached before, but because of the parameter settings in the HTTP response header, the browser must ensure that the image is the latest version before it can be sent to the user. Conditional GET requests are also discussed in section B.

Where does the time go?
Where has the time been?

In this way, we found that at least 80% of the response time is spent on downloading the page element content. When we dig deep into the details of these charts, we will gradually see the complex interaction process between HTTP and browsers. Previously, I have mentioned how HTTP status codes and headers affect browser cache operations. In addition, we can also note the following points:

1. When cache is used (Chart A-2), there are not many download requests. On the contrary, you will see a blank area without any download records after the HTML document initialization and resolution is complete. This period of time is used to parse HTML documents, JS and CSS, as well as to retrieve the existing element content from the cache.

2. The number of parallel HTTP requests that change at any time. A chart A-2 has at most three parallel HTTP requests, but as many as six or seven HTTP requests appear simultaneously in the chart A-1. This phenomenon is caused by the number of different domain names, regardless of the protocol HTTP/1.0 or HTTP/1.1 used. We will discuss this issue in Chapter 6 "parallel download" in depth.

3. Parallel requests do not occur when the script is requested, because in most cases, the browser blocks requests other than the download script. Chapter 6 explains the cause and describes how to use this feature to accelerate page loading.

It is difficult to find out exactly where time is spent. However, it is easy to find out where it takes no time to download HTML documents, and any background processing related to it is not time-consuming. Since these are not time-consuming, we can realize how important it is to optimize those time-consuming items in the front end.

The performance golden rule
Performance Optimization gold Regulations

Previously we mentioned that only 10-20% of the response time is spent on downloading HTML documents. This phenomenon not only happens on the homepage of Yahoo. The previous data features can be very well applied to almost all Yahoo's functions (except Yahoo's search function, because there are too few elements on that search page ). In addition, these statistics apply to the vast majority of websites. Table A-1 showsHttp://www.alexa.comTop 10 websites in the United States. Of course, there are some minor changes: Except for AOL, the top ten websites in the United States, among which craigslist.org ranks among them, but the website has almost no images, scripts, and CSS, so it is really impossible to become a good example. So I chose AOL.

Similarly, almost all websites only use less than 20% of the response time to download HTML documents. The only external column is Google in a cache environment. This is because the http://www.google.com has only 6 document elements in total, and all other elements except one are set to browser cache for processing. In subsequent access, since these elements have been cached, only HTML document requests and an image beacon are left.

Among all the performance optimizations, the most important thing is to define the current performance and point out where it is the key to a substantial performance improvement. Obviously, the front-end is the performance optimization point we really want to focus on.

First, there is huge potential for improving the overall performance of the optimized front-end. We cut the processing time of the background system by half, so the end user's response time is nothing more than 5-10%; on the contrary, if we cut the time by half on the front end, it will shorten the total response time by 40-50%!

Second, front-end performance optimization usually takes less time and requires less resources. To shorten the wait time in the background, we often have to do a variety of things, such as re-designing the architecture and code, finding and optimizing problematic code branches, and adding or modifying hardware devices, distributed Database Construction. These events often take weeks or even months. The frontend performance optimization measures mentioned in the subsequent sections will be best practices that are more conducive to actual operations, such as modifying web server configurations (Chapters 3 and 4 ); change the position of the script and CSS on the web page (chapters 5 and 6); merge images, scripts, and CSS (Chapter 1 ). These work takes only a few hours or days-far less time than the background optimization needs.

Furthermore, the actual value of browser optimization has been confirmed. At Yahoo, over 50 teams successfully reduced the response wait time of end users by using these best practice solutions, with a much smaller proportion of 25% or more. Of course, in many cases, we must not stick to these rules, but conduct more specific analysis and optimization based on the specific circumstances of the website. But in general, through these best practices, it is entirely possible to increase the performance by 25% or even higher.

Every time I start performing performance optimization, I draw a chart like a A-1, and then note the golden rule of Performance Optimization:

10-20% of the time is actually used to download HTML documents, and other 80-90% of the time is on the download page element.

The rest of this book will give you a detailed description of how to reduce the time consumption of this 80-90%. To clarify this, I will cover many technologies, such as HTTP request headers, JavaScript, CSS, and Apache.

Considering that the basic concept of HTTP is the key to understanding this book, I upgraded this part to Chapter B separately.

After chapter B, there are 14 Rules for improving performance. Each rule is a chapter. These rules are sorted according to the priorities we generally understand. Of course, whether a rule can be good for your specific website depends on the specific situation. For example, rule 2 is more suitable for commercial websites than for personal websites. If you use all the optimization methods suitable for your website, you can increase the access speed of your page by 25-50%, and greatly improve the user experience. The last chapter of this book shows how to analyze the top ten websites in the United States from the perspective of performance.

The importance of front-end performance the importance of front-end performance