Page Speed: Leverage browser caching More Recommendations

Rule Summary

Server
High
Moderate
60%

Overview

Reduce the load times of pages by storing commonly used files from your website on your visitors browser.

  • Reduce page load times for repeat visitors
  • Particularly effective on websites where users regularly re-visit the same areas of the website
  • Cost-benefit ratio: high
  • Access needed
How does your site score on this rule?

What is browser caching?

Every time a browser loads a webpage it has to download all the web files to properly display the page. This includes all the HTML, CSS, javascript and images.

Some pages might only consist of a few files and be small in size - maybe a couple of kilobytes. For others however there may be a lot of files, and these may add up to be several megabytes large. Twitter.com for example is 2mb+.

The issue is two fold.

  1. These large files take longer to load and can be especially painful if you're on a slow internet connection (or a mobile device).
  2. Each file makes a separate request to the server. The more requests your server gets simultaneously the more work it needs to do, only further reducing your page speed.

Browser caching can help by storing some of these files locally in the user's browser. Their first visit to your site will take the same time to load, however when that user revisits your website, refreshes the page, or even moves to a different page of your site, they already have some of the files they need locally.

This means the amount of data the user's browser has to download is less, and fewer requests need to be made to your server. The result? Decreased page load times.

How does it work?

Browser caching works by marking certain pages, or parts of pages, as being needed to be updated at different intervals. Your logo on your website, for instance, is unlikely to change from day to day. By caching this logo image, we can tell the user's browser to only download this image once a week. Every visit that user makes within a week would not require another download of the logo image.

By the webserver telling the browser to store these files and not download them when you come back saves your users time and your web server bandwidth.

Why is it important?

The main reason why browser caching is important is because it reduces the load on your web server, which ultimately reducing the load time for your users.

How to leverage browser caching

To enable browser caching you need to edit your HTTP headers to set expiry dates on certain types of files.

Find your .htaccess file in the root of your domain, this file is a hidden file but should show up in FTP clients like FileZilla or CORE. You can edit the htaccess file with notepad or any form of basic text editor.

In this file we will set our caching parameters to tell the browser what types of files to cache.

## EXPIRES CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 2 days"
</IfModule>
## EXPIRES CACHING ##

Depending on your websites files you can set different expiry dates. If certain types of files are updated more frequently, you would set an earlier expiry date on the (ie. css files)

When you are done save the file as is and not as a .txt file.

If you are using any form of CMS, cache extensions or plugins might be available.

Recommendations

  • Be aggressive with your caching for all static resources
  • Expiry at a minimum of one month (recommended: access plus 1 year)
  • Don't set your caching more than a year in advance!

Be careful

You want to be careful when enabling browser caching as if you set the parameters too long on certain files, users might not be getting the fresh version of your website after updates.

This is particularly relevant if you are working with a designer to make changes to your website - they might have made the changes but you can't see them yet because the elements that have been changed are cached on your browser.

recommends:

Set caching headers aggressively for all static resources

For all cacheable resources, we recommend the following settings:

  • Set Expires to a minimum of one month, and preferably up to one year, in the future. (We prefer Expires over Cache-Control: max-age because it is is more widely supported.) Do not set it to more than one year in the future, as that violates the RFC guidelines.
  • Set the Last-Modified date to the last time the resource was changed. If the Last-Modified date is sufficiently far enough in the past, chances are the browser won't refetch it.
Use fingerprinting to dynamically enable caching

For resources that change occasionally, you can have the browser cache the resource until it changes on the server, at which point the server tells the browser that a new version is available. You accomplish this by embedding a fingerprint of the resource in its URL (i.e. the file path).

Set the Vary header correctly for Internet Explorer

Internet Explorer does not cache any resources that are served with the Vary header and any fields but Accept-Encoding and User-Agent. To ensure these resources are cached by IE, make sure to strip out any other fields from the Vary header, or remove the Vary header altogether if possible.

Avoid URLs that cause cache collisions in Firefox

The Firefox disk cache hash functions can generate collisions for URLs that differ only slightly, namely only on 8-character boundaries.

Use the Cache control: public directive to enable HTTPS caching for Firefox

Some versions of Firefox require that the Cache control: public header to be set in order for resources sent over SSL to be cached on disk, even if the other caching headers are explicitly set. Although this header is normally used to enable caching by proxy servers (as described below), proxies cannot cache any content sent over HTTPS, so it is always safe to set this header for HTTPS resources.

Read More

Contribute to this recommendation

Have an opinion, link, or other contribution to share regarding this recommendation? Share it with us and help make the web a faster place!