Page Speed Best Practices

Configure your server to send data in a compressed format to reduce transfer times. For compressible files, compression can reduce the amount of data that needs to be sent by around 70% for only a small amount of configuration effort. Text-based data formats such as HTML, CSS, JavaScript, plain text, XML, JSON and SVG should almost always be sent with compression enabled. However, we recommend only compressing responses above 1,000 bytes in size as compressing small files can actually increase the response size and compression has a server CPU overhead. To confirm your server is sending a URL response in a compressed format, you should 1) verify the Content-Encoding response header is being returned and 2) check the value of that header is set to the name of a compression scheme such as gzip, deflate or br. If you’re checking from your own machine that runs antivirus software, be aware there’s been cases where HTTP scanning features have been found to disable compression before responses reach your browser. Also, it isn’t unusual to see misconfigured servers which compress some compressible file types like HTML but forget to do it for others like CSS so be on the look out for this.

Compression should only be applied to data that can be compressed to avoid wasting server resources. Common non-text-based data formats like JPG, PNG, MP4 and PDF files are already stored in a compressed format so you don’t need to compress files like these again when your website serves them. Trying to compress already compressed data will consume server resources and can even result in increased file sizes. Your server should be configured to only compress resources that can be effectively compressed such as HTML, CSS, JavaScript and SVG files. To check for this, you need to confirm the Content-Encoding response header is used to specify a compression scheme only for compressible files. The header should be omitted for already compressed files.

Take care that your minification process does not inline source maps into your JavaScript or CSS files. Source maps are used to help developers debug minified files by providing a mapping from minified code statements back to the original unminified code. Minification tools will either store the source map in an external file or inline the source map into the minified file itself. As source map data can take up even more space than the minified code, inline source maps defeat the file shrinking purpose of minification. Inline source maps should only be used during development and you should use external source maps for production builds. You can check if a JavaScript or CSS file contains an inlined source map by looking for a statement starting with /* sourceMappingURL=data: in your files.

Enable caching of your page resources so browsers can reuse resources that have already been downloaded. The Cache-Control response header is used to specify the caching policy of each URL: the no-store setting prevents all browser caching and the no-cache setting forces the browser to check with the server if a cached version is out-of-date before using the cached copy. For page resources, we recommend that no-cache and no-store are not set. This configuration means a browser will always cache resources and will immediately reuse them if needed without having to contact the server again. Warning: You must have a strategy for how updated versions of your page resources are going to replace the cached versions. Generally, each updated resource should use a new URL to force browsers to fetch the new version. This is referred to as “cache busting” and is built into many web frameworks.

Configure page resources to have long caching times so browser caches will retain them for longer. The cache duration of each resource URL can be specified by either 1) setting an Expires response header which specifies the point in time the response becomes stale such as Expires: Fri, 10 Aug 2019 20:00:00 GMT or 2) adding a max-age directive to the Cache-Control response header that specifies the number of seconds the response is valid for such as Cache-Control: max-age=3600 for 1 hour. If max-age and Expires are both used, max-age takes priority. We recommend setting the cache time of page resources to at least 24 hours.

The same page resource should always be served from the same URL to improve caching efficiency. Browsers will only reuse a cached resource if the resource is requested from the exact same URL as before. If the same resource is available over multiple URLs, this can lead to extra browser requests. For example, say a browser cached a resource from http://example.com/jq.js and later had to request identical content from these URLs while browsing (where the URL differences are highlighted): https ://example.com/jq.js, http:// www. example.com/jq.js, http://example.com/ jquery .js, http://example.com/ libs/ jq.js, http://example.com/jq.js ?v=3.2&a=1, http://example.com/jq.js ?a=1&v=3.2. As none of the URLs are exact matches, the same content would need to be downloaded when each URL was first seen as a cached response from a different URL cannot be used instead. For caching to happen, URLs must have matching protocols, filenames, folders, query parameters and even query parameter ordering. Avoid caching issues like this by making sure each unique page resource is referenced using a single consistent URL.

Avoid using @import in CSS files as this prevents parallel loading of CSS. Inside a CSS file, @import can be used to include the contents of another CSS file by specifying a URL. This can be convenient but impacts download times because browsers can only start fetching the imported URL after the CSS file containing the @import has been fetched. To get a page to load CSS files in parallel, you should instead add a <link rel="stylesheet" href="…"> tag for each of the CSS files you need to load to the HTML code of the page.

External JavaScript should be included on pages in a way that doesn’t block page rendering. A <script src="…"> tag will block HTML rendering until the JavaScript file specified is fetched and the contents of the file has finished executing. Inline JavaScript also blocks rendering until execution is complete. You can stop <script> tags from blocking rendering by placing them directly before the closing </body> tag. Alternatively, for external JavaScript files you can load the script in the background using either 1) <script defer src="…">, which delays script execution until the DOM is ready or 2) <script async src="…">, which will execute the script as soon as it has loaded. Note that defer scripts execute in the order they appear on the page like inline scripts. However, async scripts execute whenever they have downloaded so their execution order can change. This difference is important when scripts have dependencies.

To speed up browsing between pages on your site, avoid hyperlinks to URLs that perform redirects. For example, say you had a hyperlink pointing to /news which now redirects to /updates because the page was moved. A user visiting the hyperlink would experience a significant page loading delay as the redirect was being followed. You can avoid delays like this by hyperlinking directly to the redirect destination.

Avoid loading page resources via URLs that perform redirects as redirects will slow down page loading. For example, if a CSS file was loaded using the URL example.com/styles.css that then redirects to www.example.com/styles.css, the redirect would introduce a delay when the file was fetched. This can be fixed by linking directly to the redirect destination.

When a redirect must be used, use a single redirect instead of a chain of several redirects for a faster response. For instance, a redirect chain such as http://example.com → https://example.com → https://www.example.com can be common when redirect rules haven’t been optimised. Chains of redirects add significant delays to fetching URLs while browsing and search bots may give up following long chains which can impact search rankings. You should optimise your server redirection rules to eliminate chains of redirects when it isn’t possible to eliminate redirects entirely.