How to optimize web page performance

The front-end is huge, including HTML, CSS, Javascript, Image, Flash and other various resources. Front-end optimization is complex, and there are different methods for all aspects of resources. So, what is the purpose of front-end optimization?

　1. From a user perspective, optimization can make pages load faster, respond more promptly to user operations, and provide users with a more friendly experience.
　2. From the perspective of service providers, optimization can reduce the number of page requests or reduce the bandwidth occupied by requests, which can save considerable resources.
In short, proper optimization can not only improve the user experience of the site but also save considerable resource utilization.
There are many ways to optimize the front-end, which can be roughly divided into two categories according to the granularity. The first category is page-level optimization, such as the number of HTTP requests, non-blocking loading of scripts, position optimization of inline scripts, etc.; the second category It is code-level optimization, such as DOM operation optimization in Javascript, CSS selector optimization, image optimization, HTML structure optimization, etc. In addition, with the purpose of improving the input-output ratio, the various optimization strategies mentioned later are roughly arranged in order from large to small input-output ratio.
1. Page-level optimization
1. Reduce the number of HTTP requests
This strategy is basically known to all front-end people, and it is also the most important and effective. It is said that HTTP requests should be reduced, but what will happen if there are too many requests? First of all, each request has a cost, including both time cost and resource cost. A complete request requires a "long" and complicated process of DNS addressing, establishing a connection with the server, sending data, waiting for the server to respond, and receiving data. The time cost is that the user needs to wait for the process to end to see or "feel" the resource. Since each request on the resource needs to carry data, each request requires bandwidth. In addition, since there is an upper limit on the number of concurrent requests that the browser can make (see here for details), when the number of requests increases, the browser needs to make requests in batches, which will increase the user's waiting time and cause problems to the user's site. The impression of slow speed is that even if all the resources on the first screen that the user can see have been requested, the browser's progress bar will always exist.
The main ways to reduce the number of HTTP requests include:
(1). Simplify the page from the design and implementation level
If your page is as simple as Baidu’s homepage, then the following rules are basically unnecessary. It’s most straightforward to keep the page simple and reduce resource usage. If not, and your page needs a gorgeous skin, then continue reading below.
　(2). Properly set up HTTP cache
The power of cache is powerful, and proper cache settings can greatly reduce HTTP requests. Taking Youa's homepage as an example, when the browser does not cache it, a total of 78 requests will be issued, with a total of more than 600K data (as shown in Figure 1.1). However, when the second visit is after the browser has cached it, only 10 requests will be made. requests, with a total of more than 20K data (Figure 1.2). (It should be noted here that if you directly refresh the page with F5, the effect will be different. In this case, the number of requests is still the same, but the request server for the cached resource is a 304 response. Only the Header has no Body, which can save bandwidth)
What is a reasonable setting? The principle is very simple. The more you can cache, the better, and the longer you can cache, the better. For example, image resources that rarely change can directly set a long expiration header through Expires in the HTTP Header; resources that change infrequently but may change can use Last-Modifed for request verification. Keep resources in the cache as long as possible. The specific settings and principles of HTTP caching will not be described in detail here. Those who are interested can refer to the following articles:
Description of caching strategies in HTTP1.1 protocol
Fiddler HTTP Performance Introduction to caching in
　(3). Resource merging and compression
If possible, try to merge external scripts and styles into one. In addition, CSS, Javascript, and Image can all be compressed using corresponding tools. After compression, a lot of space can often be saved.
　(4). CSS Sprites
Another good way to merge CSS images and reduce the number of requests.
　(5). Inline Images
　Use data: URL scheme is a good way to embed images into pages or CSS if resource management issues are not considered. If it is embedded in the page, the size of the page will be increased, and the browser cache cannot be used. Images used in CSS are more ideal.
　(6). Lazy Load Images (I still don’t understand the content of this section)
This strategy may not actually reduce the number of HTTP requests, but it can reduce the number of HTTP requests under certain conditions or when the page is just loaded. For pictures, you can load only the first screen when the page is just loaded, and only load subsequent pictures when the user continues to scroll back. In this way, if the user is only interested in the content of the first screen, the remaining image requests will be saved. Yes Home Page The previous approach was to cache the image addresses after the first screen in the Textarea tag when loading, and then load them "lazily" when the user scrolls down.

　2. Put the external script at the bottom (load the script content after the page information content is loaded)
As mentioned earlier, the browser can request concurrently, which makes it faster Loading resources, however, external link scripts will block other resources when loading. For example, before the script is loaded, the images, styles and other scripts behind it are blocked and will not start loading until the script is loaded. If the script is placed in a relatively high position, it will affect the loading speed of the entire page and thus affect the user experience. There are many ways to solve this problem, in Here is a more detailed introduction (Here is the translation and More detailed examples ), and the simplest and most reliable method is to move the script as far back as possible to reduce the impact on concurrent downloads.
　3. Asynchronous execution of inline scripts (In fact, the principle is the same as above, ensuring that the script is loaded after the page content.)
　The impact of inline scripts on performance is even worse than that of external scripts. Home page, like external scripts, inline scripts will also block concurrent requests when executed. In addition, since the browser is single-threaded in page processing, when the inline script is executed before the page is rendered, the page rendering work will be postponed. In short, when the inline script is executed, the page is blank. In view of the above two reasons, it is recommended to execute inline scripts that take a long time to execute asynchronously. There are many asynchronous methods, such as using the defer attribute of the script element (there are compatibility issues and other problems, such as document.write cannot be used), Use setTimeout , in addition, introduced in HTML5 The mechanism of Web Workers can exactly solve such problems.

4. Lazy Load Javascript (Only loaded when loading is required, information content is not loaded under normal circumstances.)
With the popularity of Javascript frameworks, more and more sites are using it. frame. However, a framework often includes many functional implementations. These functions are not required by every page. If you download unnecessary scripts, it is a waste of resources - it wastes both bandwidth and execution time. . There are currently two approaches. One is to customize a dedicated mini version of the framework for pages with particularly high traffic, and the other is Lazy Load. YUI uses the second method. In the implementation of YUI, only the core module is loaded initially, and other modules can wait until they are needed.

　5. Put CSS in HEAD
If you put CSS in other places such as BODY, the browser may start rendering the page before downloading and parsing the CSS, which results in The page jumps from the CSS-less state to the CSS state, which results in a poor user experience. In addition, some browsers will only start rendering the page after the CSS is downloaded. If the CSS is placed at a lower position, it will cause the browser to delay the rendering time.
　6. Asynchronous request Callback (that is, extracting some behavioral styles and slowly loading the information content)
　There may be such a requirement in some pages that requires the use of script tags to request data asynchronously. Similar:
Javascript:
/*Callback function*/
function myCallback(info){
//do something here
}
HTML:

Content returned by cb:
myCallback('Hello world!');
Writing