yahoo legal 14

The golden rule of web application performance optimization: optimize the performance of the front-end program first, because this is where 80% or more of the end-user response time is spent.
Rule 1. Reduce HTTP Requests
80% of end-user response time is spent on front-end programs, and most of their time is spent downloading various page elements such as images, style sheets, scripts, and Flash. Fewer page elements will reduce the number of HTTP requests. This is the key to displaying pages 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:
Image maps combine multiple images into a single image. The total file size did not change much, but the number of HTTP requests was reduced and the page 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 are the better way. It can combine images from a page into a single file and use the CSS background-image and background-position properties to render the desired part of the image.
Inline images use the data: URL scheme to inline images in the page. This will increase the size of the HTML file. Combining inline images into your (cached) stylesheets is a way to both 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. This method, although simple, 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 widely from page to page, but if done, it will 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 application:
foreign trade: Combine dozens of small icons on the home page into one, control their display through CSS, and reduce the number of HTTP requests.

Rule 2. When using CDN (Content Delivery Network),
the distance between the user and the web server also has a great influence on the response time. From the user's point of view, deploying content to multiple geographically dispersed servers will effectively speed up page loading. But where to start?
As a first step towards geographic distribution of content, don't try to refactor your web application to fit a distributed architecture. Changing the architecture 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 a redesign of the application's architecture.
We also remember that 80-90% of the end user response time is spent on various elements in the download page such as image files, style sheets, scripts and Flash etc. Rather than spend the difficult task of refactoring the system, distribute static content first. Not only does this drastically reduce response times, but thanks to the CDN, distributing static content is very easy to achieve.
A CDN is a collection of geographically distributed web servers used to distribute content more efficiently. The web server serving a specific user is usually selected based on the network distance.
Some large websites have their own CDNs, but it will be cost-effective to use a CDN service provider such as Akamai Technologies, Mirror Image Internet, or Limelight Networks. Distributing static content to a CDN at Yahoo! reduces user impact time by 20% or more. Switching to a CDN for code modification work is easy, but can result in increased website speed.
Our application: I
haven't used it yet, but according to customers' 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 that the current problem of website access speed can be greatly alleviated.

Rule 3. Increase Expires Header
Web content is getting 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, style sheets, and Flash.
Browsers (and proxies) use caching to reduce the number and size of HTTP requests, allowing web pages to load faster. The Web server tells the client how long an element can be cached via 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" Set 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 use renaming as a step in release: the version number is embedded in the filename, such as yahoo_2.0.6.js.
Our application: foreign trade: Apache is configured with JS, CSS, and image caches. 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;
The rules (JS) are generated according to the client's settings, but there will be basically no changes for a long time. Therefore, an expires response header is attached while generating the rules to minimize the generation of client requests and probe rules. frequency.

Rule 4. Compress page elements
Reduce page response time by compressing HTTP response content. Since HTTP/1.1, the web client uses the Accept-Encoding header in the HTTP request to indicate the supported compression type, such as:
Accept-Encoding: gzip, deflate.
If the web server checks the Accept-Encoding header, it will use the client The supported method to compress HTTP responses will set the Content-Encoding header, such as: Content-Encoding: gzip.
Gzip is currently the most popular and effective compression method. There are other ways like deflate, but it is less effective and not popular enough. With Gzip, the content is typically reduced by 70%. In the case of Apache, the mod_gzip module is required under version 1.3, and mod_deflate is required under version 2.x.
The Web server decides whether to compress according to the file type. Most websites compress HTML files. But it's also worth compressing script files and style sheets. In fact, it is worthwhile to compress task text information including XML and JSON. Image files and PDF files should not be compressed, as 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.
Our applications:
foreign trade, E-net exhaustion, K plan: ext2 package of more than 600K, everyone would think of compressing it, the compression effect is not bad, only more than 150K. In addition, JS, CSS, and HTML are also compressed as much as possible. We must know that many of our customers are still using 1M ADSL.

Rule 5. Put stylesheets in
the HEAD We have found that moving the stylesheets to the HEAD section improves the loading speed of the interface, so this allows the page elements to be displayed sequentially.
The problem with putting style sheets at the bottom of the document in many browsers, such as IE, is that it prohibits the sequential display of the page content. The browser blocks the display to avoid redrawing the page elements, so the user can only see a blank page. Firefox doesn't block the display, but it means that some page elements may need to be repainted when the stylesheet is downloaded, which causes flickering issues.
The HTML specification explicitly requires that style sheets be defined in HEAD, so to avoid blank screen or flickering issues, the best way to follow the HTML specification is to put style sheets in HEAD.
Our application:
Haven't we run into putting stylesheets behind the document yet?

Rule 6. Put script files 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 on the one hand they can be displayed sequentially, and on the other hand to achieve maximum parallel download.
The browser blocks 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 the content behind the script will be blocked, so putting the script at the bottom as much as possible means 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 no more than two parallel downloads per host for browsers. 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 doesn't 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, scripts use the document.write method to insert page content. There may also be domain issues. In many cases, however, there are ways to do it.
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. Unfortunately, Firefox doesn't support the DEFER property. In IE, the script may be delayed but not necessarily get the long delay needed. But on the other hand, if the script can be delayed, it can be placed at the bottom.
Our application:
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 often than most people expect. Not only are expressions evaluated when the page is displayed and resized, but expressions are reevaluated 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 numerical value the first time it is executed. If it must be set dynamically, use event handlers instead. If you must use CSS expressions, keep in mind that they may be executed thousands of times, affecting page performance.
Our application:
Currently the maintenance of CSS is mainly the responsibility of the UI people, and they have tried to avoid this situation as much as possible.

Rule 8. Put JavaScript and CSS in External Files
Many of the above performance optimization rules are based on external files. Now, we have to ask a question: should JavaScript and CSS be included in external files, or in page files?
In the real world, using an external file will speed up the page display because the external file is cached by the browser. If the built-in JavaScript and CSS in the page will reduce the number of HTTP requests, but 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, in general, external files are the more feasible way. The only exception is that the inline method is more effective for the home page, such as Yahoo! and My Yahoo! both use the inline method. Generally speaking, in a session, the home page is visited less at this time, so the inline method can achieve faster user response time.
Our application:
foreign trade, E-net, K plan: ext2 code has made a good guide. At present, front-end developers pay great attention to the encapsulation and reuse of client-side modules, and try to use external JS to improve code reuse. , and of course be careful not to introduce too many external resources, as this violates Law 1.
At present, the 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 problems.

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 cache server maintained by the ISP or the local area network, 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 cache time of Firefox is 1 minute.
Reducing the hostname reduces the number of DNS queries, but may result in a reduction in the number of parallel downloads. Avoiding DNS queries can reduce response time, while reducing the number of parallel downloads can increase response time. A possible compromise is to distribute content across at least 2 and at most 4 different hostnames.
Our application:
foreign trade: In order to bypass the browser's limit on the number of download threads, we have enabled multiple domain names for static resources, but doing so violates 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 to minimizing source code. Like minification, it reduces source code size by removing comments and whitespace, and it also obfuscates the code. As part of the obfuscation, function and variable names are replaced with short strings, which makes the code more compact, but also harder to read, making it difficult to reverse engineer. Dojo Compressor (ShrinkSafe) is the most common obfuscation tool.
Minimization is a safe, straightforward process, whereas obfuscation is more complicated and prone to problems. From a survey of the top 10 U.S. websites, by minimizing, files can be reduced by 21%, while 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 according to rule 4 for transmission, minimizing the script will reduce the file size by 5% or more.
Our application:
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
Redirects are done with 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 of redirection is to reduce the user experience.
One of the most resource-intensive, often-occurring, and easily overlooked redirects is the missing / at the end of the URL, e.g. visiting http://astrology.yahoo.com/astrology will be redirected to http://astrology.yahoo.com /astrology/. Under Apache, this problem can be solved by means of Alias, mod_rewrite or DirectorySlash.
Our application:
The experienced SA has considered this issue for us. Interested students can look at the Apache configuration file in the online environment: httpd.conf.

Rule 12. Remove Duplicate Script Files
Including duplicate JS script files in a page affects performance i.e. it creates unnecessary HTTP requests and extra JS execution.
Unnecessary HTTP requests happen under IE, while Firefox doesn't make redundant HTTP requests. Additional JS execution, whether under IE, or under Firefox, will happen.
One way to avoid duplicating script files is to use a template system to build script management modules. In addition to preventing duplicate script files, this module can also implement dependency checking and add version numbers to script filenames to achieve super long expiration times.
Our application:
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 mistakes.

Rule 13. Configure ETags
ETags is a mechanism for determining whether an element in the browser cache matches an element in the Web server, and is a more flexible element validation mechanism than last-modified date. ETag is a string used to uniquely represent the version of the element, and it needs to be enclosed in quotes. The web server first specifies the ETag in the response:
      HTTP/1.1 200 OK
      Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
      ETag: "10c24bc-4ab-457e1c1f"
      Content-Length: 12195
Later, if the browser requires authentication For 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, which saves download time:
      GET /i/yahoo.gif HTTP/1.1
      Host: us.yimg. com
      If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
      If-None-Match: "10c24bc-4ab-457e1c1f"
      HTTP/1.1 304 Not Modified

The problem with ETags is that they are constructed based on some properties of server uniqueness, like Apache1.3 and 2.x, the format is inode-size-timestamp, while under IIS5.0 and 6.0, the format is Filetimestamp:ChangeNumber . In this way, the ETag of the same element on different web servers is different. In this way, in the environment of multiple Web servers, the browser first requests an element from server1, and then verifies the element to server2. Because the ETag is different, the cache is invalid and must be downloaded again.
Therefore, if you are not using the flexible authentication mechanism provided by the ETags system, it is best to delete ETags. Removing the ETag will reduce the size of the HTTP headers of the http response and subsequent requests. The Microsoft support article describes how to remove ETags, and under Apache, just set FileETag none in the configuration file.
Our application:
E-net exhaustion: Customize the generation strategy of ETag to minimize the generation times of probe rules. Since the default ETag of the server is not adopted, this problem does not exist.
Other product lines: Pay attention, no one has paid attention to this point, hurry up and check the configuration in Apache.

Rule 14. Caching Ajax
performance optimization rules also apply to web 2.0 applications. The most important way to improve Ajax performance is to make its response cacheable, as discussed in "Rule 3 Increase the Expires Header". The following other rules also apply to Ajax, but 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.We Applications:
In more cases, we don't want Ajax requests to be cached. In this case, it is enough to append a timestamp to the url of each Ajax request.