This is just a quick update to list out some further optimisations that might help you achieve a few extra points.
Prolong the Cache Expiry Setting
The default cache expiry settings is 7 days OOTB in Sitecore. This is a little short for the likes of GTMetrix but may be passable for Lighthouse. I found it best to bump it up to 30 days (if you can).
Google Page Speed insights calls this criteria “Text Compression” but this does actually make a download size difference if your HTML payload is large. After doing this I witnessed my initial HTML delivery drop from 130KB to 40KB.
Inside your web.config and the <httpCompression> tags we added just previously add the mimeType for document into both staticTypes and dynamicTypes.
<add mimeType="document" enabled="true" />
Cleanup all missing fonts and 404s
Be sure to check you network tab and make sure any missing font references or external resources are not throwing 404s. This will result in a score reduction particularly on GTMetrics.
I have done a number of posts and talks at user groups on Page Speed and performance over the last few years. I have split the various topics into individual blog posts for the most part as performance is dependent on many factors. What has really been missing is a complete demo of how all the different techniques come together to give your site a really good score. So that’s what I intend to demo here is the combination of the 6 pillars of page speed in one Sitecore instance. To recap here are the 6 pillars of page speed performance in my opinion:
I have shown a subset of these previously but crucially three critical pillars to do with imaging were hard to achieve at the time. This is now possible due to being able to support Next Gen image compression (webp), which I wrote about in my previous blog. With a little more time and investigation Image Lazy Loading, responsiveness and image compression to give a more complete picture of how each pillar impacts page speed.
Here are the tools and blogs I will use to achieve each of these:
Alternatives: Mark Gibbons (MVP) recently upgraded the Dianoga image library to support WEBP. Worth a look if you don’t want to use a third party API. It also supports a CDN. Also Vincent Lui (MVP) also pointed out in his recent SUGCON talk, you can achieve both image compression and image lazy loading via some of the modern CDN’s. That is a great (easy) option if you are retro fitting these techniques to a live website.
I’m not going to dive deep into exactly how to setup each of these things as I think the individual links have sufficient instructions. I will show in the Demo videos how each pillar impacts the HTML rendered. For the most part I am keen to demonstrate the impact of each of these line items and how each one will benefit your page speed score.
Before we begin its important to understand that the algorithm (Lighthouse) behind Google’s Page Speed insight doesn’t work in an exactly linear fashion. If you improve your score by ticking off one of the above, don’t expect ticking off another issue will have the same benefit. The last 20 points out of 100 (on the mobile scoring system) is that hardest to achieve based on what I have seen.
Live Demo Video Series that accompanies this blog:
The Baseline score encompasses the habitat site installed with no modifications.
Result: 48 / 38 / 40 / 34 / 38 = 39.6/100 Average
Observation: Heavily penalised for CSS and Javscript loading times.
Image Lazy Loading
All images on the homepage were converted to be Lazily loaded. A single large blurred image was used as the placeholder for all images.
Result: 57 / 55 / 61 / 52 / 63 = 57.6/100 Average
Observation: Around the mid point of the scale, image lazy loading has around a 15 – 20 point impact.
Rendering Cache Strategy
I have blogged extensively about this in the past but setting up cache settings properly is so critical and has a major impact. Its also one of the easiest things to fix for a poorly performing Sitecore site. Also note the only way to accurately demonstrate the impact that Rendering cache has on a site is to test it under load.
ERR_TIMED_OUT / ERR_TIMED_OUT / ERR_TIMED_OUT / ERR_TIMED_OUT / ERR_TIMED_OUT = You get the point 🙂
Observation: Rendering cache settingsare critical and should be the first step in Page Load Speed refinement for a Sitecore site. 10 Point benefit observed once a site is stable under load.
Result: 60 / 58 / 61 / 62 / 62 = 60.6/100 Average
Observation: Around the mid point of the scale, image lazy loading has around a 20 point impact.
Result: 74 / 78 / 79 / 81 / 81 = 78.6/100 Average
Observation: The combination of critical CSS in the head and Deferred styles provides a meaningful page speed boost. 25 Point observed benefit.
Result: 92 / 94 / 93 / 94 / 94 = 93.4/100 Average
Result: 56 / 54 / 59 / 56 / 60 = 57/100 Average
Observation: Around the mid point of the scale converting images to be responsive (srcset support) has about a 10 point impact.
No Change (SXA Habitat Home OOTB)
41.8 / 100
Image Lazy Loading
57.6 / 100
Sitecore Rendering/HTML Cache Settings
50.8 / 100
Image Compression (webp)
60.6 / 100
78.6 / 100
93.4 / 100
57 / 100
The Pillars Combined
In isolation we can see the rough results of what each of the pillars might do to our Page Speed. The real question is what does combining all these pillars produce.
Observation: Do I expect this on an actual production site realistically ? That is certainly the dream, but in reality you should be over the moon if you make it into the 90s and pat your self on the back if you get into the 80s as well. For any Sitecore site if you make it into the 90’s for mobile, your doing an amazing job.
Admittedly for the combined demo I skipped the responsive image pillar. SXA supports Responsive Images but not in combination with data attributes. It was going to be a bunch of work to write a custom SXA handler to support both lazy loading and responsiveness at the same time. That is not to say its not possible. Either way the impact was minimal.
Page speed is so critical to SEO and visitor conversion. A slow site instantly turns away users on mobile and tablet devices. Admittedly the final result shown above and in the video have required that all the right tools be available to the Sitecore community. Which up until recently you likely needed to bake your own solutions in order to get that over the line.
I think its now becoming possible to aim fairly high (90/100 on mobile) with our Page Speed scores, but it does require getting most if not all of the Architecture Pillars above working together. Its worth learning each of these and understanding the pitfalls and limitations if you want really great page speed. Good luck and feel free to get in touch with any questions.
The combined pillars can produce great results but you still need to load test before going live. Checkout the video below where I search for the breaking point using the loadtest tool. Please note that this node based load test tool should just be used for a guide. Before go live I recommend using a hosted load tool solution that has multiple geographic locations. Tests done based on one network location or device will result in a network bottle neck and give you false positives.
Spoiler: This post is not a post about Dianoga, I take a deep dive into Tiny PNG and Kraken.IO integrations into Sitecore. The results are worth checking out at the bottom.
At the start of the year, I’ve picked up where I left off, on page speed. Last year I took a deep dive into attempting to improve the page speed on Sitecore SXA sites by using some of Google’s recommended techniques to structure the page. If you haven’t already seen it, head on over the Sitecore Speedy and see some of the results we achieved.
I’ll be the first to admit that getting really good page speed scores isn’t easy. It takes a lot of different factors to come together. Just as a reminder, here is the main list that I would consider you need to check off to be winning at this game.
For this post, i’m going to look at an alternative to Dianoga. I’m a big fan of Dianoga and have used it over the years to crunch loads of oversized images introduced by Content Editors. I will, however, say that it can add complexity to deployments and CI/CD pipelines and while some claim to have had success in Azure Apps, others have not.
On the flip side, content editors love Tiny PNG, which is one of the most popular image compression website utilities going around. Tiny PNG also has a developer API, so we have used this to build in a compression tool that can be used directly from your Sitecore toolbar.
The button below is hooked up to chat to Tiny PNG API. It will send across your image data and receive a compressed image back for storage.
Full disclosure, I’m not the first person to hook up Tiny PNG to the image library. I could find two other implementations
Now let’s jump in have a look at the results just from crunching a few images down:
Without image compression:
To compress the images on the page, we head on over to the “Compress” button in the Media tab that we have introduced.
A few examples of compression results taken from homepage images:
Before: 158.4 KB | After: 110.6 KB
Before: 197.8 KB | After: 135.3 KB
Before: 640.0 KB | After: 120.7 KB
After compressing all the images on the page the saving can be seen below.
So our total image size saving is 2.4MB – 1.3MB = 1.1MB
A pretty decent saving from just pressing the compress button on 27 homepage images. Also, consider that the user won’t notice any difference in image quality as this method uses lossless compression.
The compression achieved is great for helping us tick off one of the requirements for fast pages with Google. But as we are about to find out Google will likely still complain about two other criteria. When it comes to Google Page Speed insights a page that does not have properly processed images will bring up the following three recommendations:
Here is a break down of how we address each one:
Serve image in next-gen formats – Image formats like JPEG 2000, JPEG XR, and WebP often provide better compression than PNG or JPEG, which means faster downloads and less data consumption. Learn more.
Properly Size images – Your CSS layouts should be responsive and use modern image retrieval techniques that adapt the image size requested based on screen size. Read More
Efficiently encode images – The Tiny PNG integration above will take care of this. This is all about compressing the image to as small as it can get without a visible loss of quality.
So assuming you have already achieved number three using the Tiny PNG integration or another source, let us look at how we can solve the next-gen image requirement.
As a quick side note the testing I did after converting the images to next-gen also ticked item number two above. I don't think this should be relied on however and its best to incorporate responsive images into your projects from the beginning.
When looking into how to convert images to a next-gen format I opted to target webp. Google has a nice little page explaining the format here.
WebP is natively supported in Google Chrome, Firefox, Edge, the Opera browser, and by many other tools and software libraries.
Once again I opted to look for an API that would provide the conversion for me so that Sitecore could easily connect, send the image and then store the result. All without any extra hosting requirements. I opted to go with Kraken.IO image APIs as they have a free 100MB trial offer and well free is a good price when building proof of concepts. The integration is all available on Aceik’s github repository. Just signup for your own API keys add them to the module settings (in the CMS) and start converting.
To test out just how much this would impact the image payload size for the whole page, I once again converted all the images on the SXA habitat homepage.
Here are the results:
So our total image size saving is now 2.4MB – 0.79MB = 1.61MB
The reduction in size from a non-compressed image to a webp formatted image is truly impressive.
A few examples:
I can only conclude by saying that if page speed is really an important factor for your Sitecore project take a look at Tiny PNG. If you want to go next level with your image formats and achieve great compression try out the Kraken.IO API integration as it could be well worth the small subscription fee.
Total Image Size
The module and code mentioned in this blog post are available on Aceik’s Github account. This also contains installations instructions.