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 the end-user response time is spent.
Rule 1. Reduce the number of HTTP requests
80% of end-user response time is spent on front-end programs, and most of this time is spent on downloading various page elements, such as images, style sheets, scripts, 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 is there another way to achieve both rich content and fast response times? Here are some such techniques:
Image mapsCombine multiple images into one image. The total file size does not change much, but the number of HTTP requests is reduced and the page is displayed faster. This method is only suitable for continuous pictures; at the same time, the definition of coordinates is annoying and error-prone work.
CSS Sprites is a better way. It combines images from the page into a single file and uses the CSS background-image and background-position properties to implement the required portion of the image.
Inline images use the 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 reduce HTTP requests and avoid increasing the size of your HTML files.
Combined files reduce the number of HTTP requests by combining multiple script files into a single file. Style sheets can also be handled in a similar way. Although this method is simple, it has not been used on a large scale. The top 10 US 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. According to Tenni Theurer's article Browser Cache Usage - Exposed!, 40-60% of daily visits are first-time visits, so speeding up page access for first-time visitors is the key to user experience.
Our Apps:
Foreign Trade: Merge dozens of small icons on the homepage into one, control their display through CSS, and reduce the number of HTTP requests.
Rule 2. Use CDN (Content Delivery Network, Content Delivery Network)
The user’s distance 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 geographical distribution of content, don’t try to refactor your web application to fit the distribution architecture. Changing the schema will result in multiple periodic tasks, such as synchronizing session state and replicating database transactions across 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.
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 network distance.
Some large websites have their own CDN, but it will 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.
Our app:
It has not been used yet, but according to customer reports, the network conditions in Guangdong, Shandong and other places are relatively poor. If the static resources that occupy the main bandwidth can be released through CDN, I believe it can greatly alleviate the current website access speed problem.
Rule 3. Add Expires Header
Web content is becoming richer and richer, 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 for image files, but it should also be used for script files, stylesheets, and Flash.
Browsers (and proxies) use caching to reduce the number and size of HTTP requests, making 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.
Please remember that if you use a long expiration time, you will have to modify the file name when the content changes. At Yahoo! we often rename as a step in the release process: the version number is embedded in the file name, such as yahoo_2.0.6.js.
Our app:
Foreign trade: The cache of JS, CSS, and image is configured in Apache. If the static resources need to be updated, the solution of modifying the file version number is adopted to ensure that the client obtains the latest version;
E-Network: The probe rules (JS) of E-Network are generated according to the customer's settings, but they will basically not change for a long period of time. Therefore, an expires response is attached when generating the rules. header to minimize the number of client requests and probe rule generation.
Rule 4. Compress page elements
Reduce page response time by compressing HTTP response content. 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 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 can typically be 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.
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.
So compressing as many file types as possible is an easy way to reduce page size and improve user experience.
Our app:
Foreign trade, E-net, K plan: People will think of compressing an ext2 package of more than 600 K. The compression effect is not bad, only more than 150 K. In addition, JS, CSS, and HTML are also compressed as much as possible. You must know that many of our customers are still using 1M ADSL.
Rule 5. Put the style sheet above your head
We found that moving the style sheet to the HEAD section can improve the loading speed of the interface, so this allows 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, and the user only sees a blank page. Firefox does not block display, but this means that some page elements may need to be repainted after the stylesheet is downloaded, which causes flickering issues.
HTML specificationclearly requires style sheets to be defined in HEAD. Therefore, to avoid blank screen or flickering issues, the best way is to follow the HTML specification and place the style sheet in HEAD.
Our app:
Have you ever encountered the situation of putting style sheets at the back of the document?
Rule 6. Put the script file at the bottom
Like 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 the 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 downloads, the browser does not initiate 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. However, 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. But from another perspective, if the script can be delayed, it can be placed at the bottom.
Our app:
You may not have realized this before, but we have implemented this rule in our XCube XUI, and I believe it can further improve the page access performance.
Rule 7. Avoid CSS expressions
CSS expressions are a powerful (and dangerous) way to dynamically set CSS properties. IE, starting from version 5, supports CSS expressions, 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 execute 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.
Our app:
Currently, CSS maintenance work is mainly the responsibility of UI personnel, and they have tried their best to avoid this situation.
Rule 8. Put JavaScript and CSS in external files
Many of the above performance optimization rules are optimized based on external files. Now, we have to ask the question: should JavaScript and CSS be included in external files, or within 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.
So, generally speaking, external files are the more viable 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.
Our app:
Foreign trade, E-net, K plan: The ext2 code provides a good guide. Currently, front-end developers pay great attention to the encapsulation and reuse of client modules, and try to improve the reuse of the code through external JS. Of course, Be careful not to bring in too many external resources, as this violates Rule 1.
The current encapsulation of CSS is also good, but it is mainly a solution for the IE series. You can consider introducing CSS frameworks such as YAML and blueprint to easily solve browser compatibility issues.
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. To achieve higher performance, DNS resolution is usually cached at multiple levels, such as the caching server maintained by the ISP or LAN, the cache of the local machine operating system (such as the DNS Client Service on Windows), and the browser. The default DNS cache time of IE is 30 minutes, and the default buffer time of Firefox is 1 minute.
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.
Our app:
Foreign Trade: In order to bypass the browser's limit on the number of download threads, we enabled multiple domain names for static resources, but doing so violated this rule. However, for Windows IE, DNS caching can alleviate this problem.
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 way to minimize the 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 and variable names are replaced with short strings, which makes the code more compact and less readable, 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.
Our app:
We do not use JS compression directly, but many components we use, such as ext2, jquery, etc., are already practicing this rule for us.
Rule 11. Avoid redirects
The redirection function is completed through the two HTTP status codes 301 and 302, such as:
HTTP/1.1 301 Moved Permanently
Copy after login
<span style="color: #000000"> Location: http://example.com/newuri</span>
Copy after login
Content-Type: text/html
Copy after login
The browser automatically redirects the request to the URL specified by Location. The main problem of redirection is that it reduces the user experience.
One of the most resource-consuming, frequent and easily overlooked redirects is the missing / at the end 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.
Our app:
Experienced SA has already considered this issue for us. Interested students can take a look at the Apache configuration file of the online environment: httpd.conf.
Rule 12. Delete duplicate script files
Including duplicate JS script files in a page affects performance, i.e. it creates unnecessary HTTP requests and extra 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, allowing for extremely long expiration times.
Our app:
This problem is more serious in the old version of Xplatform, but I believe that the new version of XCube will not repeat the same mistake.
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. An 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
Copy after login
Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
Copy after login
ETag: "10c24bc-4ab-457e1c1f"
Copy after login
Content-Length: 12195
Copy after login
Later, if the browser needs to verify an element, it uses the If-None-Match header to return 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
Copy after login
Host: us.yimg.com
Copy after login
If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
Copy after login
If-None-Match: "10c24bc-4ab-457e1c1f"
Copy after login
HTTP/1.1 304 Not Modified
Copy after login
The problem with ETags is that they are constructed based on some attributes unique to the server, like Apache1.3 and 2.x, their format is inode-size-timestamp, while under IIS5.0 and 6.0, their 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 an 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.
Our app:
E-Network: Customize the ETag generation strategy to minimize the number of probe rule generation times. Since the default ETag of the server is not used, this problem does not exist.
Other product lines: Please pay attention. No one has paid attention to this. Check the configuration in Apache quickly.
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:
Rule 4. Compress page elements
Rule 9. Reduce the number of DNS queries
Rule 10. Minimize script files
Rule 11. Avoid redirects
Rule 13. Configure ETags.
Our app:
In more cases, we don’t want the Ajax request to be cached. At this time, just append a timestamp to the URL of each Ajax request.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
