A brief discussion on Yahoo's 35 rules for front-end optimization

Abstract: Whether at work or in an interview, optimizing web front-end performance is very important. So where should we start with optimization? You can follow Yahoo's 34 rules for front-end optimization, but now there are 35, so it can be said that these are Yahoo's 35 rules for front-end optimization. It has been classified, which is good. This will give us a clearer direction for optimization.

Content

1. Minimize the number of HTTP requests

80% of the end-user response time is spent on the front-end, most of which is spent downloading various components on the page: images, style sheets, scripts, Flash, and so on. Reducing the number of components will inevitably reduce the number of HTTP requests submitted by the page. This is the key to making your page faster.

One way to reduce the number of page components is to simplify the page design. But is there a way to build complex pages while still improving response times? Well, there is indeed a way to have the best of both worlds.

Merging files reduces the number of requests by putting all scripts in one file. Of course, you can also merge all CSS. If the scripts and styles for each page are different, merging the files can be a cumbersome task, but doing this as part of the site publishing process can really improve response times.

CSS Sprites are the preferred way to reduce the number of image requests. Combine all background images into one image, and then use the CSS background-image and background-position properties to position the part to be displayed.

Image maps combine multiple images into a single image that has the same total size but reduces the number of requests and speeds up page loads. Image maps are only useful when the images are continuous on the page, such as in a navigation bar. The process of setting coordinates for an image map is tedious and error-prone. It is also not easy to use image maps for navigation, so this method is not recommended.

Inline images (Base64 encoded) use the data: URL scheme to embed images into the page. This will increase the size of the HTML file. Putting inline images in the (cached) style sheet is a good idea and successfully avoids making the page "heavy". However, the current mainstream browsers do not support inline images very well.

Reducing the number of HTTP requests for a page is a starting point, and it is an important guiding principle for improving the speed of first visits to your site.

2. Reduce DNS Lookups

The Domain Name System establishes a mapping between host names and IP addresses, just like the mapping between names and numbers in a phone book. When you enter www.yahoo.com into your browser, the browser contacts the DNS resolver and returns the server's IP address. DNS has a cost; it takes 20 to 120 milliseconds to look up the IP address for a given hostname. Until the DNS lookup is complete, the browser cannot download anything from the hostname.

DNS lookups are more efficiently cached on a special cache server hosted by the user's ISP (Internet Service Provider) or local network, but can also be cached on individual user computers. DNS information is stored in the operating system's DNS cache (the "DNS Client Service" on Microsoft Windows). Most browsers have their own cache that is independent of the operating system. As long as the browser has this record in its cache, it will not query the operating system for DNS.

IE caches DNS lookups for 30 minutes by default, as written in the DnsCacheTimeout registry setting. Firefox caches for 1 minute, which can be set using the network.dnsCacheExpiration configuration item. (Fasterfox changed the cache time to 1 hour. PS Fasterfox is a speed-up plug-in for FF)

If the client's DNS cache is empty (including the browser and operating system), the number of DNS lookups is equal to the number of different host names on the page, including the host names in components such as page URLs, images, script files, style sheets, Flash objects, etc. Reducing the number of different host names can reduce DNS lookups.

Reducing the number of different hostnames also reduces the number of components of the page that can be downloaded in parallel. Avoiding DNS lookups reduces response time, while reducing the number of parallel downloads increases response time. My principle is to spread components across 2 to 4 host names, which is a compromise between reducing DNS lookups and allowing high concurrent downloads.

3. Avoid redirects

Redirects use 301 and 302 status codes. Here is an HTTP header with a 301 status code:

HTTP/1.1 301 Moved Permanently
Location: http://example.com/newuri
Content-Type: text/html

The browser will automatically jump to the URL specified in the Location field. All the information needed for a redirect is in the HTTP header, and the response body is usually empty. In fact, additional HTTP headers such as Expires and Cache-Control also indicate redirection. There are other ways to redirect: refresh meta tags and JavaScript, but if you must redirect, it is best to use the standard 3xxHTTP status code, mainly to allow the back button to work properly.

Keep in mind that redirects slow down the user experience. Inserting a redirect between the user and the HTML document will delay everything on the page. The page cannot be rendered and components cannot start downloading until the HTML document is served to the browser.

A common and extremely wasteful redirect that web developers are often unaware of is when a URL is missing a trailing slash. For example, a redirect to http://astrology.yahoo.com/astrology would return a 301 response redirecting to http://astrology.yahoo.com/astrology/ (note the added trailing slash). In Apache, you can use Alias, mod_rewrite or DirectorySlash instructions to cancel unnecessary redirects.

The most common use of redirection is to connect the old site to the new site. It can also connect different parts of the same site and do some processing according to different user situations (browser type, user account type, etc.). Using a redirect to connect two websites is the simplest and requires only a small amount of extra code. Although using redirects at these times reduces development complexity for developers, it reduces the user experience. An alternative is to use Alias ​​and mod_rewrite, provided both code paths are on the same server. If you are using redirection because of a domain change, you can create a CNAME (create a DNS record pointing to another domain as an alias) in conjunction with the Alias ​​or mod_rewrite directive.

4. Make Ajax Cacheable

One benefit of Ajax is that it can provide immediate feedback to users because it can asynchronously request information from a backend server. However, with Ajax there is no guarantee that the user will not be bored while waiting for the asynchronous JavaScript and XML response to return. In many applications, the ability for the user to wait depends on how Ajax is used. For example, in a web-based email client, users will keep an eye on the results returned by Ajax requests in order to find email messages that match their search criteria. It's important to remember that "asynchronous" does not mean "immediate."

Optimizing these Ajax responses is critical to improving performance. The most important way to improve Ajax performance is to make the response cacheable, as discussed in Adding Expires or Cache-Control HTTP headers. The following additional rules apply to Ajax:

1. Gzip Component
2. Reduce DNS lookups
3. Compressing JavaScript
4. Avoid redirects
5. Configuring ETags

Let's look at an example where a Web 2.0 email client uses Ajax to download the user's address book in order to implement the auto-complete feature. If the user has not modified her address book since the last time she used it, and the Ajax response is cacheable, with an Expires or Cache-Control HTTP header that has not expired, then the previous address book can be read from the cache. The browser must be informed whether it should continue to use the previously cached address book response or request a new one. This can be achieved by adding a timestamp to the address book's Ajax URL indicating when the user's address book was last modified, for example &t=1190241612. If the address book has not been modified since the last download, the timestamp remains unchanged and the address book will be read directly from the browser cache, thus avoiding an extra HTTP round trip. If the user has modified their address book, the timestamp also ensures that the new URL will not match a cached response and the browser will request a new address book entry.

Even though Ajax responses are created dynamically and may only be useful to a single user, they can be cached, which can make your Web 2.0 application faster.

5. Lazy Load Components

Take a closer look at the page and ask yourself: What is necessary to render the page in the first place? The rest of the content can wait.

JavaScript is an ideal choice for separating the before and after of the onload event. For example, if there is JavaScript code and libraries that support drag and drop and animations, these can wait because dragging and dropping elements comes after the initial rendering of the page. Other areas that can be lazy loaded include hidden content (content that appears after an interaction) and above-the-fold images.

Tools are available to help ease your workload: YUI Image Loader can lazy-load images behind the fold, and the YUI Get utility is an easy way to include JS and CSS. The Yahoo! homepage is an example, which you can take a closer look at by opening Firebug's Network panel.

It's best to align performance goals with other web development best practices, such as "progressive enhancement". If the client supports JavaScript, it can improve the user experience, but you must ensure that the page works properly when JavaScript is not supported. So, once you’ve made sure your page is working properly, you can enhance it with some lazy loading scripts to support some fancy effects like drag and drop and animations.

6. Preload components

Preloading might seem like the opposite of lazy loading, but it actually has different goals. By preloading components, you can make full use of the browser's idle time to request components (images, styles, and scripts) that will be used in the future. When the user visits the next page, most of the components are already in the cache, so the page will load faster for the user.

There are several types of preloading in actual applications:

1. Unconditional preloading - Start loading as soon as possible, fetching some additional components. google.com is a good example of a sprite image preloading. This sprite image is not needed for the google.com homepage, but for the content on the search results page.
2. Conditional preloading - guess where the user is going to jump based on the user's actions and preload accordingly. After typing in the search.yahoo.com input box, you can see how those additional components are requested to load.
3. Preload in advance – Preload new designs before they are launched. It’s not uncommon to hear after a redesign: “The new site is great, but it’s slower than before.” Part of the reason is that users were accessing the previous pages with an old cache, but the new one is an experience with an empty cache. This negative impact can be mitigated by preloading some components before the new design is launched. The old site can use the browser's idle time to request the images and scripts needed by the new site.

7. Reduce the number of DOM elements

A complex page means more bytes to download, and accessing the DOM with JavaScript will be slower. For example, when you want to add an event handler, there is a difference between looping over 500 DOM elements on a page and looping over 5,000 DOM elements.

A large number of DOM elements is a sign that there is some extraneous markup on the page that needs to be cleaned up. Are you using nested tables for layout? Or are you adding a bunch of <div>s to fix a layout problem? Perhaps better semantic markup should be used.

YUI CSS utilities are very helpful for layout: grids.css is for overall layout, fonts.css and reset.css can be used to remove the browser's default formatting. This is a good opportunity to start cleaning up and thinking about your markup, for example only using a <div> when it makes sense semantically, and not because it renders a new line.

The number of DOM elements is easy to test. Just type in the Firebug console:

document.getElementsByTagName('*').length

So how many DOM elements are too many? For example, the Yahoo! homepage is a fairly busy page with less than 700 elements (HTML tags).

8. Separate components across domains

Separating components maximizes parallel downloads, but ensures that no more than 2-4 domains are used due to the cost of DNS lookups. For example, you can deploy HTML and dynamic content on www.example.org, and separate static components into static1.example.org and static2.example.org.

9. Use iframes as little as possible

Using iframe, you can insert an HTML document into the parent document. It is important to understand how iframe works and use it efficiently.

Advantages of <iframe>:

1. Slow introduction of third-party content, such as logos and ads
2. Security Sandbox
3. Parallel download scripts

Disadvantages of <iframe>:

1. Costly, even for a blank iframe
2. Blocking page loading
3. Non-semantic

10. Avoid 404

HTTP requests are expensive. There is no point in making an HTTP request to get a useless response (such as 404 Not Found). It will only slow down the user experience without any benefit.

Some sites use helpful 404 - "Did you mean xxx?" This is good for user experience, but it also wastes server resources (such as databases, etc.). The worst thing is that the external JavaScript you link to has errors and the result is a 404. First, such a download will block parallel downloads. Second, the browser will try to parse the 404 response body, and since it is JavaScript code, it needs to figure out what parts of it are usable.

CSS part

11. Avoid using CSS expressions

Using CSS expressions to dynamically set CSS properties is a powerful but dangerous way. It has been supported since IE5, but is no longer recommended since IE8. For example, you can use CSS expressions to set the background color to alternate on an hourly basis:

background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );

12. Choose <link> and abandon @import

As mentioned earlier, a best practice is to put CSS at the top in order to achieve progressive rendering.

Using @import in IE has the same effect as using <link> at the bottom, so it is best not to use it.

13. Avoid using filters

IE's proprietary AlphaImageLoader filter can be used to fix the problem of semi-transparent PNG images in versions prior to IE7. During the image loading process, this filter will block rendering, jam the browser, increase memory consumption, and be applied to each element instead of each image, so there will be a lot of problems.

The best approach is to not use AlphaImageLoader at all, and gracefully degrade to using PNG8 images instead, which are well supported in IE. If you must use AlphaImageLoader, you should use the underscore hack: _filter to avoid affecting users of IE7 and above.

14. Put your stylesheet at the top

While researching performance at Yahoo!, we discovered that putting stylesheets in the HEAD section of the document made the page appear to load faster. This is because placing the stylesheet in the head allows the page to render progressively.

Front-end engineers who are concerned about performance want to render pages incrementally. That is, we want the browser to display the existing content as quickly as possible, which is especially important when there is a lot of content on the page or when the user's connection speed is slow. The importance of displaying feedback (such as progress indicators) to users has been extensively studied and documented. In our case, the HTML page is the progress indicator! As the browser gradually loads the page header, navigation bar, top logo, and so on, these are used as feedback by users who are waiting for the page to load, improving the overall user experience.

js part

15. Remove duplicate scripts

Having duplicate script files on your pages can affect performance in ways you might not expect. In a review of the top 10 web sites in the United States, only 2 were found to contain duplicate scripts. Two main reasons increase the chances of having duplicate scripts on a single page: team size and number of scripts. In this case, duplicate scripts create unnecessary HTTP requests and execute useless JavaScript code, which affects page performance.

IE will generate unnecessary HTTP requests, while Firefox will not. In IE, if a non-cacheable external script is included twice by a page, it will generate two HTTP requests when the page loads. Even if the script is cacheable, it will generate an additional HTTP request when the user reloads the page.

Besides generating meaningless HTTP requests, evaluating the script multiple times wastes time. Because redundant JavaScript code is executed in Firefox and IE regardless of whether the script is cacheable.

One way to avoid accidentally importing the same script twice is to implement a script management module in your template system. The typical script introduction method is to use the SCRIPT tag in the HTML page:

 <script type="text/javascript" src="menu_1.0.17.js"></script>

16. Minimize DOM access

Accessing DOM elements with JavaScript is slow, so to make your page more responsive, you should:

1. Cache the index of the elements that have been visited
2. Update nodes "offline" first, then add them to the DOM tree
3. Avoid using JavaScript to fix layout issues

17. Use smart event handlers

Sometimes the page feels unresponsive because too many frequently executed event handlers are added to different elements of the DOM tree, which is why it is recommended to use event delegation. If you have 10 buttons in a div, you should only add one event handler to the div container, not one for each button. Events can bubble up, so you can capture the event and know which button was the source of the event.

18. Put the script at the bottom

The script will block parallel downloads. The official HTTP/1.1 documentation recommends that the browser should not download more than two components in parallel for each host name. If the images come from multiple host names, the number of parallel downloads can exceed two. If a script is downloading, the browser will not start any other downloads, even to a different hostname.

Sometimes it's not easy to move the script to the bottom. For example, if the script is inserted into the page content using document.write, it cannot be moved down any further. There may also be scoping issues, which can be resolved in most cases.

A common suggestion is to use deferred scripts. Scripts with the DEFER attribute are meant to not contain document.write, and prompt the browser to tell them that they can continue rendering. Unfortunately, Firefox does not support the DEFER attribute. In IE, scripts may be deferred, but not as expected. If the script can be deferred, we can put it at the bottom of the page and the page will load faster.

javascript, css

19. Keep JavaScript and CSS out

Many performance principles are about how to manage external components. However, before these concerns arise, you should ask a more basic question: should JavaScript and CSS be placed in external files or written directly on the page?

In fact, using external files can make your pages faster because the JavaScript and CSS files will be cached in the browser. Inline JavaScript and CSS in an HTML document are re-downloaded every time the HTML document is requested. Doing so reduces the number of HTTP requests required, but increases the size of the HTML document. On the other hand, if the JavaScript and CSS are in external files and are already cached by the browser, then we have successfully made the HTML document smaller without increasing the number of HTTP requests.

20. Compress JavaScript and CSS

Compression is specifically about removing unnecessary characters from the code to reduce its size, thereby increasing loading speed. Code minification removes all comments and unnecessary whitespace characters (spaces, newlines, and tabs). Doing this in JavaScript can improve responsiveness because the file to download is smaller. The two most commonly used JavaScript code compression tools are JSMin and YUI Compressor. YUI compressor can also compress CSS.

Obfuscation is an optional source code optimization measure that is more complex than compression, so the obfuscation process is more prone to bugs. In a survey of the top ten US websites, compression reduced the size by 21%, while obfuscation reduced it by 25%. Although obfuscation reduces the size to a greater extent, it is riskier than compression.

In addition to compressing external scripts and styles, inline <script> and <style> blocks can also be compressed. Even with gzip enabled, compressing first can reduce the size by 5% or more. JavaScript and CSS are becoming more and more common, so compressing the code can be a good idea.

picture

21. Optimize images

Try converting your GIF to PNG to see if that saves space. Run pngcrush (or another PNG optimization tool) on all PNG images

22. Optimize CSS Sprites

1. In sprite images, horizontal arrangement generally results in a smaller final file size than vertical arrangement.
2. Combining similar colors in a sprite image can keep the color count low, ideally in PNG8 format with less than 256 colors.
3. "Mobile-friendly", don't leave too much space in the sprite image. While this will not significantly affect the image file size, it will save the memory consumed by the user agent when decompressing the image into a pixmap. A 100×100 image has 10,000 pixels, while a 1000×1000 image has 1 million pixels.

23. Don’t scale images with HTML

Don't use unnecessarily large images just because you can set the width and height in HTML. If needed

<img width="100" height="100" src="mycat.jpg" alt="My Cat" />

Then the image itself (mycat.jpg) should be 100x100px, instead of shrinking the 500x500px image.

24. Use a small, cacheable favicon.ico (PS Favorites Icon)

favicon.ico is an image placed in the root directory of the server. It will cause a lot of trouble because even if you ignore it, the browser will automatically request it, so it is best not to give a 404 Not Found response. And as long as it is on the same server, the cookie will be sent every time you request it. In addition, this image will interfere with the download order. For example, in IE, when you request additional components in onload, the favicon will be downloaded first.

So to mitigate the disadvantages of favicon.ico, you should ensure that:

1. Small enough, preferably below 1K
2. Set a suitable expiration date HTTP header (you can't rename it if you want to change it later). It is usually safe to set the expiration date to a few months in the future. You can make sure that the browser is aware of the change by checking the last modified date of the current favicon.ico.

Cookies

25. Reduce the weight of cookies

Cookies are used for a number of reasons, such as authorization and personalization. Cookie information is exchanged between web servers and browsers in HTTP headers. It is important to keep the cookie as small as possible to minimize the impact on user response time.

1. Clear unnecessary cookies
2. Keep cookies as small as possible to minimize the impact on user response time.
3. Be careful to set the appropriate domain level for cookies to avoid affecting other subdomains
4. Set an appropriate expiration date. An earlier expiration date or none can delete cookies faster and improve user response time.

26. Place components on a domain that does not contain cookies

When the browser sends a request for a static image, the cookies are also sent along with it, and the server doesn't need these cookies at all. So they only cause meaningless network traffic, and you should make sure that requests for static components do not contain cookies. You can create a subdomain and deploy all static components there.

If the domain name is www.example.org, you can deploy static components to static.example.org. However, if cookies have been set on the top-level domains example.org or www.example.org, then all requests to static.example.org will include those cookies. At this time, you can buy a new domain name, deploy all static components on it, and keep this new domain name free of cookies. Yahoo! uses yimg.com, YouTube is ytimg.com, Amazon is images-amazon.com, and so on.

Another benefit of deploying static components in a domain without cookies is that some proxies may refuse to cache components with cookies. One thing to note: If you don't know whether to use example.org or www.example.org as your homepage, consider the impact of cookies. If you omit www, you can only write cookies to *.example.org, so for performance reasons it is best to use the www subdomain and write cookies to this subdomain.

Mobile

27. Ensure all components are less than 25K

This limitation is because the iPhone cannot cache components larger than 25K, note that this refers to the uncompressed size. That's why it's also important to minify the content itself, as gzip alone may not be enough.

28. Package components into a compound document

By packaging the components into a compound document like an email with attachments, you can fetch multiple components with a single HTTP request (remember: HTTP requests are expensive). When using this method, you must first check whether the user agent supports it (iPhone does not support it).

server

29.Gzip Component

Front-end engineers can find ways to significantly reduce the time it takes to transmit HTTP requests and responses over the network. There is no doubt that the end user's bandwidth speed, network service provider, distance to peer exchange points, etc. are all beyond the control of the development team. But there are other factors that can affect response time, and compression can improve response time by reducing the size of the HTTP response.

Since HTTP/1.1, web clients have had the Accept-Encoding HTTP request header to support compression.

Accept-Encoding: gzip, deflate

If a web server sees this request header, it will compress the response using one of the methods listed by the client. The web server notifies the client through the Content-Encoding response header.

Content-Encoding: gzip

Using gzip compression as much as possible can reduce the size of the page, which is also the easiest way to improve the user experience.

30. Avoid leaving the image src attribute empty

Image with empty string Images with an empty string src attribute are very common and appear in two main forms:

1. Straight HTML

<img src=””>

2. JavaScript

var img = new Image();
img.src = "";

Both forms cause the same problem: the browser sends another request to the server.

31. Configure ETags

Entity tags (ETags) are a mechanism used by servers and browsers to determine whether a component in the browser cache matches a component on the origin server (an "entity" is a component: an image, script, style sheet, etc.). Adding ETags provides an entity validation mechanism that is more flexible than the last-modified date. An ETag is a string that uniquely identifies a specific version of a component. The only format constraint is that the string must be enclosed in quotes, and the origin server specifies the component's ETag using the ETag in the response header:

HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
ETag: "10c24bc-4ab-457e1c1f"
Content-Length: 12195 

Then, if the browser must validate a component, it passes the ETag back to the origin server using the If-None-Match request header. If the ETags match successfully, a 304 status code will be returned, thus reducing the response body by 12195 bytes.

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

32. Use GET request for Ajax

The Yahoo! Mail team discovered that when using XMLHttpRequest, the browser's POST request is implemented through a two-step process: first sending the HTTP header, then sending the data. So it is best to use a GET request, which only requires sending one TCP message (unless there are a lot of cookies). The maximum length of IE URL is 2K, so if the data to be sent exceeds 2K, GET cannot be used.

An interesting side effect of a POST request is that no data is actually sent, just like with a GET request. As described in the HTTP specification, a GET request is used to retrieve information. So its semantics is just to request data using GET request, not to send data that needs to be stored on the server.

33. Clear the buffer early

When a user requests a page, it takes the server about 200 to 500 milliseconds to assemble the HTML page, during which time the browser is idly waiting for the data to arrive. PHP has a flush() function that allows sending a portion of the prepared HTML response to the browser so that the browser can start fetching components while the rest is being prepared in the background. This is useful in busy backends or very "light" frontend pages (PS, the advantage is best when the response time is mainly in the background).

The ideal place to flush the buffer is after the HEAD, because the HEAD part of the HTML is usually easier to generate and allows the inclusion of any CSS and JavaScript files, which allows the browser to start fetching components in parallel while they are still being processed in the background.

For example:

 ... <!-- css, js -->
    </head>
    <?php flush(); ?>
    <body>
      ... <!-- content -->

34. Use a CDN (Content Delivery Network)

The physical distance between the user and the server also affects response time. Deploying your content across multiple geographically dispersed servers allows your users to load pages faster. But how to do it specifically?

The first step to implementing geographically distributed content is to not try to redesign your web application to accommodate a distributed structure. Depending on the application, changing the architecture may involve daunting tasks such as synchronizing session state and replicating database transactions across servers. Proposals to shorten the distance between users and content may be delayed, or simply not passed, because of this difficulty.

Remember that 80% to 90% of the end user's response time is spent downloading page components: images, styles, scripts, Flash, etc. This is the golden rule of performance. It is better to distribute static content first rather than redesigning the application structure from the beginning. This not only greatly reduces response time, but also makes it easier to demonstrate the merits of CDN.

A content delivery network (CDN) is a group of web servers distributed in different geographical locations, used to deliver content to users more efficiently. Typically, the server selected for delivering content is based on a measure of network distance. For example: select the server with the least hops or the fastest response time.

35. Add Expires or Cache-Control HTTP header

This rule has two aspects:

1. For static components: set a distant future time as Expires to never expire
2. Redundant dynamic components: Use appropriate Cache-Control HTTP headers to allow browsers to make conditional requests

Web page designs are becoming richer and richer, which means there are more scripts, images, and Flash in the pages. A new visitor to your site may still have to submit several HTTP requests, but by using expiration dates you can make the component cacheable, which avoids unnecessary HTTP requests on subsequent visits. Expires HTTP headers are commonly used on images, but they should be used on all components, including scripts, styles, and Flash components.

Browsers (and proxies) use caches to reduce the number and size of HTTP requests, allowing pages to load faster. The web server uses the Validity HTTP response header to tell the client how long the various components of the page should be cached. Using an expiration date in the distant future tells the browser that this response will not change before April 15, 2010.

Expires: Thu, 15 Apr 2010 20:00:00 GMT

If you are using Apache, use the ExpiresDefault directive to set the expiration date relative to the current date. The following example sets the validity period to 10 years from the request time:

ExpiresDefault "access plus 10 years"

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.