Google PageSpeed Insights and Sitecore

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.

Image Optimization

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

Minification

Once the HTML is delivered to the visitor, the browser begins to process that HTML and make subsequent requests to the server for the JavaScript and CSS files that are needed to render the page.  There is significant overhead in downloading these files, so it is more efficient to deliver a single slightly larger file than it is to deliver a larger number of small files.  To address this, Google recommends a “minifcation” process where files are combined strategically and the overall size of them reduced by removing white space and comments.

If Google PageSpeed Insights is suggesting that you “Minify JavaScript” or “Minify CSS”, make sure you are using a front-end build process, such as Webpack, Gulp or Grunt, to combine and minify these files before including them on the site.  This is typically something that you have to set up in the way you develop your site, but if your site does not change frequently, you can look at external tools to minify what you have, though you would need to go through that process each time.

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.

Render Blocking JavaScript

When JavaScript is included in the <head> block of the HTML, the browser makes the assumption that this file is needed in order to begin the rendering process, causing the browser to wait until the download is complete.   Whenever possible, JavaScript should be loaded at the bottom of the page, allowing the browser to process the bulk of the HTML before waiting on JavaScript file delivery.  This leads to more of the requests happening simultaneously.

In some cases, JavaScript must be injected earlier in the page than is ideal.   Some sites include JavaScript logic on the controls themselves and that code requires JQuery to be included on the page in order to run.  Ideally the implementation moves this included JavaScript to a separate file, but if that is not possible, JQuery must be included early.   Web Forms for Marketers also injects JQuery javascript into the page to make the components function and we do not have the ability to control that.

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.

Keep Testing

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.

 

%d bloggers like this: