Google now prioritizes fast pages in the search algorithm and when pages do poorly on these tests, it may be for a wide range of reasons, some content and configuration. There are some quick wins in Sitecore for both that will help your site perform faster and pass these types of tests.
The first thing to note is that the Google PageSpeed Insights test is checking to see if your obeys some specific rules. Passing these rules does not mean that users will have a fast experience of the site, but it will help. It’s also important to look at true page speed metrics when evaluating the health of your Sitecore instance.
The Google PageSpeed Insights uses a variety of different rules to score the page. Depending on the type of error you are seeing, there may be different solutions needed.
Reduce Server Response Time
The first step in delivering the page to the user is downloading the entire HTML, which Sitecore is generating dynamically on the server. When the page contains custom logic, complex queries or searches, the page can be returned slowly to the visitor. This type of issue typically becomes worse the more users that are on the site at the same time.
The solution for this type of error is looking at ways to cache components on the page and looking for ways to rewrite search queries to reduce the time they take. In some cases, additional hardware may improve response time. The goal is to have the HTML delivered to the visitor within 200ms of the request.
Images uploaded to the Sitecore media library are often not optimized for the smallest possible file size. As pages often contain multiple images, the impact of this is high on the total time it takes the visitor to download the page. Images like jpgs and pngs can be compressed in a way that does not lose any image quality. Standard “export for web” options in Photoshop or similar programs do not pass Google’s strict image optimization standards.
We can either do this by working with authors to only upload web optimized images or we can implement an optimization inside Sitecore to ensure that all images get compressed to the smallest possible size.
Dianoga is a free marketplace module for Sitecore that uses jpegtran and PNGOptimizer to reduce the size of these images when they are delivered to visitors. It does this by modifying the image in the MediaCache to be optimized using these free tools. The compression is done asynchronously, so there is no degradation of the performance while it is compressed and the image is only compressed on the first time it is requested.
Image Optimizer v2 is a tool on the marketplace that uses the same underlying tools, but instead handles the process in the Media Library. A button media items and folders allows you to recursively optimize imagery and save actions in Sitecore ensure that new images uploaded are automatically optimized.
Note: Google PageSpeed tests lately have no longer seen images adjusted by jpgetran and PNGOptimizer as optimized. I’ve taken Image Optimizer v2 and forked it to use an alternative library (Magick.NET). Read more about that here.
You will likely also see a recommendation to “Minify HMTL” and this one is more complicated. It is possible to minify the resultant HTML that the server creates, further improving the transfer speed. There is an example of minifying the HTML with custom logic on Anders Laub Christoffersen’s blog.
This type of change may have negative impacts on the functionality of the page, especially conditional commenting for cross-browser support, so testing should be done to ensure it works properly.
Leverage Browser Caching
When the browser delivers an individual file (image, video, css, js, etc) it indicates to the browser how long it should trust that version of the file before requesting an updated file. By default, IIS does not provide an expiration date for content, which effectively causes browsers to ask for the file every time. Google recommends that we cache the values for at least 1 week. These values can be configured in IIS with instructions found here.
Note: This may mean that deploys that update static files may not be seen by client browsers until their expiration date. In order to force updates of cached critical files, adjustments should be made to the URL to avoid the cached value. An example of this approach would be to append a build number or date as a part of the query string when requesting these files.
Sadly, this is not a single solution but an ongoing battle. The rules that Google is following are constantly evolving and the features and content of your Sitecore site are constantly changing. It’s important to keep coming back and testing.