The golden rule of web application performance optimization: optimize the performance of the front-end program (front-end) first, because this is where 80% or more of end-user response time is spent.
Rule 1: Reduce the number of HTTP requests
80% of end-user response time is spent in front-end programs, and most of this time is spent on various page elements such as images, stylesheets, scripts and Download Flash etc. Reducing page elements will reduce the number of HTTP requests. This is key to displaying the page quickly. One way to reduce the number of page elements is to simplify the page design. But are there other ways to achieve both rich content and fast response times? Here are some such techniques: Combining image maps, multiple images into one image. The total file size does not change much, but the number of HTTP requests is reduced and the page display speed is accelerated. This method is only suitable for continuous pictures; at the same time, the definition of coordinates is annoying and error-prone work. CSS Sprites are a better way. It can combine the images on the page into a single file and use the CSS background-image and background-position properties to realize the required part of the image. inline images Use data: URL scheme to embed images in the page. This will increase the size of the HTML file. Combining inline images into your (cached) stylesheets is a way to make fewer HTTP requests without increasing the size of your HTML file. Combined files reduce the number of HTTP requests by combining multiple script files into a single file. Style sheets can also be processed in a similar way. Although this method is simple, it has not been used on a large scale. American websites have an average of 7 script files and 2 style sheets per page. This approach can be challenging when scripts and stylesheets vary significantly from page to page, but if done it can speed up response times. Reducing the number of HTTP requests is the starting point for performance optimization. This plays an important role in improving the efficiency of the first visit. Tenni Theurer's article Browser Cache Usage? Exposed! describes that 40-60% of daily visits to data are first-time visits, so speeding up page access for first-time visitors is key to user experience.
Rule 2: Use CDN (Content Delivery Network, Content Delivery Network)
The distance of the user from the web server also has a great impact on the response time. From a user perspective, deploying content to multiple geographically dispersed servers will effectively increase page loading speeds. But where to start?
As a first step towards geographically distributing your content, do not try to refactor your web application to accommodate the distribution architecture. Changing the architecture will result in multiple periodic tasks, such as synchronizing session state and replicating database transactions between multiple servers. Such attempts to shorten the distance between users and content may be delayed or blocked by changes in application architecture. We also remember that 80-90% of end-user response time is spent downloading various elements in the page, such as image files, stylesheets, scripts, Flash, etc. Instead of spending the difficult task of refactoring the system, distribute static content first. Not only does this greatly reduce response time, but thanks to CDN, distributing static content is very easy to implement. A CDN is a collection of geographically distributed web servers used to publish content more efficiently. The web server that serves specific users is usually selected based on the distance of the network. Some large websites have their own CDN, but it would be cost-effective to use the services of a CDN service provider such as Akamai Technologies, Mirror Image Internet, or Limelight Networks. At Yahoo!, distributing static content to a CDN reduces user impact time by 20% or more. Changing the code to switch to a CDN is easy, but can increase the speed of your website.
Rule 3: Increase Expires Header
Web content is becoming more and more abundant, which means more script files, style sheets, image files and Flash. First-time visitors will have to face multiple HTTP requests, but by using the Expires header, you can cache these elements on the client side. This avoids unnecessary HTTP requests on subsequent visits. The Expires header is most commonly used with image files, but it should also be used with script files, stylesheets, and Flash. Browsers (and proxies) use caching to reduce the number and size of HTTP requests so that web pages load faster. The Web server tells the client how long an element can be cached through the Expires header. If the server is Apache, you can use ExpiresDefault to set the expiration date based on the current date, such as: ExpiresDefault "access plus 10 years" sets the expiration time to 10 years from the request time. Keep in mind that if you use a very long expiration time, you will have to modify the file name when the content changes. At Yahoo! we often change the name as a step in release: the version number is embedded in the file name, such as yahoo_2.0.6.js.
Rule 4: Compress page elements
By compressing HTTP response content, page response time can be reduced. Starting from HTTP/1.1, the web client indicates the supported compression type through the Accept-Encoding header in the HTTP request, such as:
Accept-Encoding: gzip, deflate. If the Web server checks the Accept-Encoding header , it will use the method supported by the client to compress the HTTP response, and will set the Content-Encoding header, such as: Content-Encoding: gzip. Gzip is currently the most popular and effective compression method. Other methods such as deflate are less effective and not popular enough. With Gzip, content is typically reduced by 70%. If it is Apache, you need to use the mod_gzip module under version 1.3, and under version 2.x, you need to use mod_deflate. The web server determines whether to compress based on the file type. Most websites compress HTML files. But it's also worth compressing script files and stylesheets. In fact, it is worthwhile to compress task text information including XML and JSON. Image files and PDF files should not be compressed because they are inherently compressed. Compressing them not only wastes CPU, but may also increase the file size. Therefore, compressing as many file types as possible is an easy way to reduce page size and improve user experience.
Rule 5: Put the style sheet in the head
We found that moving the style sheet to the HEAD section can improve the loading speed of the interface, so this allows the page elements to be displayed sequentially. In many browsers, such as IE, the problem with placing the style sheet at the bottom of the document is that it prohibits the sequential display of web content. The browser blocks display to avoid redrawing page elements, so the user only sees a blank page. Firefox does not block display, but this means that some page elements may need to be redrawn after the stylesheet is downloaded, causing flickering issues. The HTML specification clearly requires that style sheets be defined in HEAD. Therefore, to avoid blank screen or flickering problems, the best way is to follow the HTML specification and place the style sheet in HEAD.
Rule 6: Place script files at the bottom
Same as style files, we need to pay attention to the location of script files. We need to try to put them at the bottom of the page so that they can be displayed sequentially and achieve maximum parallel downloading. The browser will block display until the style sheet is downloaded, so we need to put the style sheet in the HEAD section. For scripts, the sequential display of content behind the script will be blocked, so placing the script at the bottom as much as possible means that more content can be displayed quickly. The second problem caused by the script is that it blocks the number of parallel downloads. The HTTP/1.1 specification recommends that browsers limit the number of parallel downloads per host to no more than 2. So if you distribute the image files to multiple machines, you can achieve more than 2 parallel downloads. But when the script file is downloaded, the browser will not start other parallel downloads, not even downloads from other hosts. In some cases, it is not easy to move the script to the bottom. For example, the script uses the document.write method to insert page content. There may also be domain issues. But in many cases, there are still some methods. An alternative is to use a deferred script. The DEFER attribute indicates that the script does not contain document.write, instructing the browser to continue displaying it immediately. Unfortunately, Firefox does not support the DEFER attribute. In IE, scripts may be delayed, but not necessarily as long as needed. On the other hand, if the script can be delayed, it can be placed at the bottom.
Rule 7: Avoid CSS Expressions
CSS expressions are a powerful (and dangerous) way to dynamically set CSS properties. IE supports CSS expressions starting from version 5, such as backgourd-color: expression((new Date()).getHours()%2?”#B8D4FF”:”#F08A00”), that is, the background color switches every hour. The problem with CSS expressions is that they are executed more times than most people would like. Expressions are not only evaluated when the page is displayed and resized, but also when the page is scrolled and even when the mouse is moved over the page. One way to reduce the number of times a CSS expression is executed is to use one-shot expressions, which replace the expression with an explicit value the first time it is executed. If it must be set dynamically, an event handler can be used instead. If you must use CSS expressions, remember that they may be executed thousands of times, affecting page performance.
Rule 8: Put JavaScript and CSS in external files
Many of the above performance optimization rules are based on external files for optimization. Now, we have to ask the question: should JavaScript and CSS be included in external files, or in the page file? In the real world, using external files will speed up page display because external files are cached by the browser. If JavaScript and CSS are built into the page, although it will reduce the number of HTTP requests, it will increase the size of the page. On the other hand, using external files will be cached by the browser, and the page size will be reduced without increasing the number of HTTP requests. Therefore, in general, external files are the more feasible way to go. The only exception is that the inline method is more effective for homepages, such as Yahoo! and My Yahoo! both use the inline method. Generally speaking, in a session, there are fewer homepage visits at this time, so the inline method can achieve faster user response time.
Rule 9: Reduce the number of DNS queries
DNS is used to map host names and IP addresses. Generally, a resolution takes 20 to 120 milliseconds. In order to achieve higher performance, DNS resolution is usually cached at multiple levels, such as the caching server maintained by the ISP or LAN, and the cache of the local machine operating system (such as the DNS Client Service on Windows). The default DNS cache time of the browser is 30 minutes, Firefox's default buffer time is 1 minute. IE reducing the host name can reduce the number of DNS queries, but may result in a reduction in the number of parallel downloads. Avoiding DNS queries may reduce response time, while reducing the number of parallel downloads may increase response time. A workable compromise is to distribute content across at least 2 and at most 4 different hostnames.
Rule 10: Minimize JavaScript code
Minimizing JavaScript code means removing unnecessary characters in JS code, thereby reducing download time. Two popular tools are JSMin and YUI Compressor. Obfuscation is an alternative to minimizing source code. Like minify, it reduces source code size by removing comments and whitespace, and it can also obfuscate the code. As part of the obfuscation, function names and variable names are replaced with short strings, which makes the code more compact and harder to read, making it difficult to reverse engineer. Dojo Compressor (ShrinkSafe) is the most common obfuscation tool. Minimization is a safe, straightforward process, while obfuscation is more complex and prone to problems. From a survey of the top 10 websites in the United States, through minimization, files can be reduced by 21% and obfuscation can be reduced by 25%. In addition to minimizing external script files, embedded script code should also be minimized. Even if the script is compressed for transmission according to Rule 4, minimizing the script will reduce the file size by 5% or more.
Rule 11: Avoid redirection
The redirection function is completed through the two HTTP status codes 301 and 302, such as: HTTP/1.1 301 Moved Permanently Location: http://example.com/ newuri Content-Type: text/html The browser automatically redirects the request to the URL specified by Location. The main problem with redirection is that it reduces the user experience. One of the most resource-consuming, frequent and easily overlooked redirects is the last missing part of the URL. For example, visiting http://astrology.yahoo.com/astrology will be redirected to
http:/ /astrology.yahoo.com/astrology/. Under Apache, this problem can be solved through Alias, mod_rewrite or DirectorySlash.
Rule 12: Remove Duplicate Script Files
Including duplicate JS script files in a page affects performance, i.e. it creates unnecessary HTTP requests and additional JS executions. Unnecessary HTTP requests occur under IE, while Firefox does not generate unnecessary HTTP requests. Additional JS execution will occur regardless of whether it is under IE or Firefox. One way to avoid duplicate script files is to use a template system to create script management modules. In addition to preventing duplicate script files, this module can also implement dependency checking and add version numbers to script file names, thereby achieving ultra-long expiration times.
Rule 13: Configure ETags
ETags is a mechanism used to determine whether elements in the browser cache match elements in the Web server. It is a more flexible element verification mechanism than last-modified date. ETag is a string that uniquely represents an element's version and must be enclosed in quotes. The Web server first specifies the ETag in the response: HTTP/1.1 200 OK < 03:03:59 2006 Dec 12> 10c24bc-4ab-457e1c1f” Content-Length: 12195 Later, if the browser needs to validate an element, it uses If- The None-Match header returns the ETag to the Web server. If the ETag matches, the server returns a 304 code, thus saving download time: GET /i/yahoo.gif HTTP/1.1 Host: us.yimg.com < 03:03: 59 2006 Dec 12> 10c24bc-4ab-457e1c1f” HTTP/1.1 304 Not Modified The problem with ETags is that they are constructed based on certain attributes unique to the server, such as Apache1.3 and 2.x, and their format is inode-size- timestamp, and under IIS5.0 and 6.0, its format is Filetimestamp:ChangeNumber. In this way, the ETag of the same element on different web servers is different. In this way, in a multi-Web server environment, the browser first requests a certain element from server1, and then verifies the element with server2. Since the ETag is different, the cache becomes invalid and must be downloaded again.
Therefore, if you do not use the flexible verification mechanism provided by the ETags system, it is best to delete the ETag. Removing the ETag will reduce the size of the http response and the HTTP headers of subsequent requests. A Microsoft support article describes how to remove ETags, and under Apache, just set FileETag none in the configuration file.
Rule 14: Caching Ajax
Performance optimization rules also apply to web 2.0 applications. The most important way to improve the performance of Ajax is to make its response cacheable, as discussed in "Rule 3" Add Expires Header". The following other rules also apply to Ajax, of course "Rule 3" is the most effective way:
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
