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:
1) Introduce image lazy loading
2) Ensure a cache strategy is in place and verify its working. (must have adequately sized production servers)
3) Deploy image compression techniques
4) Use responsive images (must serve up smaller images sizes for mobile)
5) Introduce Critical CSS and deferred CSS files
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:
2) SXA Cache Settings – SXA official documentation
3) Next Image (WEBP) Image Compression – https://github.com/Aceik/ImageCompression
4) SXA Responsive Images – SXA official documentation
5) Introduce Critical CSS and deferred CSS files – https://github.com/Aceik/Sitecore-Speedy
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:
- A) Baseline Scores
- 1) Image Lazy Loading
- 2) Cache Strategy
- 3) Image Compression
- 4) Responsive Images
- 5) Critical CSS & Deferred CSS
- Combined Pillars
- Bonus Load Testing Step-Through
Google Page Speed Insights — Scores can fluctuate widely based on network latency. At time you will experience score fluctuations at different times of the day on the same site.
In general this is a guide
Here is the general outline of the VM that hosted the IIS instance for testing. I also put the VM under some basic load while running the tests.
- All the test below used Sitecore 9.3 and the SXA habitat example site.
- Test used the live Google Page Speed insights tool via the url: https://developers.google.com/speed/pagespeed/insights/
- Sitecore was setup on an Azure VM with the specifications:
- The test was run 5 times, to get an average score.
- The test page was the homepage of the Habitat site and the page was requested before running the test 5 times so that the instance could be considered warm.
- EXM and XDB were not running on these test instances.
- Test results are Mobile Page Speed scores only – This is the most important metric in today environment and good desktop scores are not really a challenge.
- The default Habitat cache rendering for Navigation was left on for all tests. (without this the site fails under basic load altogether)
- All tests were conducted under load in an attempt to replicate a production environment. For this I used a node package called loadtest.
loadtest -c 10 –rps 10 http://baselinecd.dev.local/10 requests per second with a concurrency of 10
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.
This test was run with higher user per second: loadtest -c 10 –rps 30 http://baselinecd.dev.local/
With Cache Enabled:
49 / 56 / 41 / 54 / 54 = 50.8
Without Cache Enabled:
ERR_TIMED_OUT / ERR_TIMED_OUT / ERR_TIMED_OUT / ERR_TIMED_OUT / ERR_TIMED_OUT = You get the point 🙂
Observation: Rendering cache settings are 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.
|Criteria||Average Score||Observed Benefit|
|No Change (SXA Habitat Home OOTB)||41.8 / 100||–|
|Image Lazy Loading||57.6 / 100||15 Points|
|Sitecore Rendering/HTML Cache Settings||50.8 / 100||10 Points|
|Image Compression (webp)||60.6 / 100||20 Points|
|Critical CSS||78.6 / 100||25 Points|
|Responsive Images||57 / 100||10 Points|
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.
Result: 100 / 100 / 100 / 100 / 100 = 100/100 Average
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.
Bonus Video: https://www.youtube.com/watch?v=96YcxyhYh0U