Google Lighthouse: Performance

We explore Google Lighthouse with the aim of maximising the performance of your Sitecore website.

Aug 14, 2020

Technology

2

min read

Joseph Moore

,

Front-end Developer

person holding a lighbulb
person holding a lighbulb
person holding a lighbulb
person holding a lighbulb

In this first article of our Google Lighthouse series, we'll be looking at the Performance category. We'll be reviewing some of the most important, commonly failed tests and discussing our approach for passing them.

Before we begin it's important to note that there's no magic bullet for getting fast page loads. Often, great performance is the sum of many small things done right. That said, if you do only one thing, automate your image optimisation!

Image optimisation

One bad content image can undo all the other painstaking work done to craft a fast loading page. For a typical Sitecore website we can configure image optimisation. This will save content editors the headache of manually creating multiple copies of an image, as well as taking advantage of modern file formats such as WEBP.

Lighthouse performance metrics

Defer off-screen images

Once you've optimised your images, the next step is to lazy load them. This involves loading images only when they're needed. This can be especially beneficial to users on slow connections where images represent the bulk of the data transfer on a typical landing or article page.

Remove unused CSS/JavaScript

Google Lighthouse has always measured how much of the CSS is transferred when a page loads is actually used. After all, there's no point in delivering, parsing and executing code that isn't needed. Improvements in technology mean that Google Lighthouse will soon be testing JavaScript.

It sounds simple enough: "Only deliver code which is needed on a given page", but it's actually far from an easy task. At Codehouse we've developed a method of doing this in Sitecore that allows us to register the assets a component requires and add them to the page as necessary.

Eliminate render-blocking resources

When the browser is parsing the page and comes across CSS or JavaScript it must essentially pause to retrieve it, figure out what to do with it and apply the changes. While it's doing that, it's not getting on with the important business of rendering the page which users will see. For this reason, we call resources like these "render-blocking".

Of course, nobody wants to see that flash of unstyled Times New Roman text load before the basic page styles are applied, so there's always a balance to be struck. We'll always try to place resources in the most appropriate place within the document. Typically, JavaScript and non-critical CSS goes at the end of the document and any CSS relating to above-the-fold content is loaded as soon as possible.

Serve static assets with an efficient cache policy

Styles, JavaScripts and images change infrequently, so we always recommend setting a long cache policy on them. When you know a file isn't going to be updated, you might as well tell your users to hang on to their copy and use that rather than asking for a new one every time they visit your site - or worse, load a page.

You need to ensure that users can get the new copy of a file after you've released new code, but this is easily controlled with techniques such as cache-busting query strings.

Minimise third-party usage

Beware the temptation to add in countless tracking scripts via Sitecore content or services such as Google Tag Manager. Every one of these scripts comes with a performance penalty for your users, so it's important to periodically audit them and remove any which you're not getting real value from.

A similar issue we have encountered are A/B testing services such as Optimizely. These can be incredibly versatile and useful for quickly gathering some data about what works and what doesn't, but they can have a terrible impact on your page load times. A server side A/B test will always be better performing in that respect and we can help you get the most from Sitecore's testing features.

Working with Codehouse

If you're looking for some help with Google, or some SEO consultancy for your Sitecore website, our Digital Experience team can help. Get in touch.

In this first article of our Google Lighthouse series, we'll be looking at the Performance category. We'll be reviewing some of the most important, commonly failed tests and discussing our approach for passing them.

Before we begin it's important to note that there's no magic bullet for getting fast page loads. Often, great performance is the sum of many small things done right. That said, if you do only one thing, automate your image optimisation!

Image optimisation

One bad content image can undo all the other painstaking work done to craft a fast loading page. For a typical Sitecore website we can configure image optimisation. This will save content editors the headache of manually creating multiple copies of an image, as well as taking advantage of modern file formats such as WEBP.

Lighthouse performance metrics

Defer off-screen images

Once you've optimised your images, the next step is to lazy load them. This involves loading images only when they're needed. This can be especially beneficial to users on slow connections where images represent the bulk of the data transfer on a typical landing or article page.

Remove unused CSS/JavaScript

Google Lighthouse has always measured how much of the CSS is transferred when a page loads is actually used. After all, there's no point in delivering, parsing and executing code that isn't needed. Improvements in technology mean that Google Lighthouse will soon be testing JavaScript.

It sounds simple enough: "Only deliver code which is needed on a given page", but it's actually far from an easy task. At Codehouse we've developed a method of doing this in Sitecore that allows us to register the assets a component requires and add them to the page as necessary.

Eliminate render-blocking resources

When the browser is parsing the page and comes across CSS or JavaScript it must essentially pause to retrieve it, figure out what to do with it and apply the changes. While it's doing that, it's not getting on with the important business of rendering the page which users will see. For this reason, we call resources like these "render-blocking".

Of course, nobody wants to see that flash of unstyled Times New Roman text load before the basic page styles are applied, so there's always a balance to be struck. We'll always try to place resources in the most appropriate place within the document. Typically, JavaScript and non-critical CSS goes at the end of the document and any CSS relating to above-the-fold content is loaded as soon as possible.

Serve static assets with an efficient cache policy

Styles, JavaScripts and images change infrequently, so we always recommend setting a long cache policy on them. When you know a file isn't going to be updated, you might as well tell your users to hang on to their copy and use that rather than asking for a new one every time they visit your site - or worse, load a page.

You need to ensure that users can get the new copy of a file after you've released new code, but this is easily controlled with techniques such as cache-busting query strings.

Minimise third-party usage

Beware the temptation to add in countless tracking scripts via Sitecore content or services such as Google Tag Manager. Every one of these scripts comes with a performance penalty for your users, so it's important to periodically audit them and remove any which you're not getting real value from.

A similar issue we have encountered are A/B testing services such as Optimizely. These can be incredibly versatile and useful for quickly gathering some data about what works and what doesn't, but they can have a terrible impact on your page load times. A server side A/B test will always be better performing in that respect and we can help you get the most from Sitecore's testing features.

Working with Codehouse

If you're looking for some help with Google, or some SEO consultancy for your Sitecore website, our Digital Experience team can help. Get in touch.

In this first article of our Google Lighthouse series, we'll be looking at the Performance category. We'll be reviewing some of the most important, commonly failed tests and discussing our approach for passing them.

Before we begin it's important to note that there's no magic bullet for getting fast page loads. Often, great performance is the sum of many small things done right. That said, if you do only one thing, automate your image optimisation!

Image optimisation

One bad content image can undo all the other painstaking work done to craft a fast loading page. For a typical Sitecore website we can configure image optimisation. This will save content editors the headache of manually creating multiple copies of an image, as well as taking advantage of modern file formats such as WEBP.

Lighthouse performance metrics

Defer off-screen images

Once you've optimised your images, the next step is to lazy load them. This involves loading images only when they're needed. This can be especially beneficial to users on slow connections where images represent the bulk of the data transfer on a typical landing or article page.

Remove unused CSS/JavaScript

Google Lighthouse has always measured how much of the CSS is transferred when a page loads is actually used. After all, there's no point in delivering, parsing and executing code that isn't needed. Improvements in technology mean that Google Lighthouse will soon be testing JavaScript.

It sounds simple enough: "Only deliver code which is needed on a given page", but it's actually far from an easy task. At Codehouse we've developed a method of doing this in Sitecore that allows us to register the assets a component requires and add them to the page as necessary.

Eliminate render-blocking resources

When the browser is parsing the page and comes across CSS or JavaScript it must essentially pause to retrieve it, figure out what to do with it and apply the changes. While it's doing that, it's not getting on with the important business of rendering the page which users will see. For this reason, we call resources like these "render-blocking".

Of course, nobody wants to see that flash of unstyled Times New Roman text load before the basic page styles are applied, so there's always a balance to be struck. We'll always try to place resources in the most appropriate place within the document. Typically, JavaScript and non-critical CSS goes at the end of the document and any CSS relating to above-the-fold content is loaded as soon as possible.

Serve static assets with an efficient cache policy

Styles, JavaScripts and images change infrequently, so we always recommend setting a long cache policy on them. When you know a file isn't going to be updated, you might as well tell your users to hang on to their copy and use that rather than asking for a new one every time they visit your site - or worse, load a page.

You need to ensure that users can get the new copy of a file after you've released new code, but this is easily controlled with techniques such as cache-busting query strings.

Minimise third-party usage

Beware the temptation to add in countless tracking scripts via Sitecore content or services such as Google Tag Manager. Every one of these scripts comes with a performance penalty for your users, so it's important to periodically audit them and remove any which you're not getting real value from.

A similar issue we have encountered are A/B testing services such as Optimizely. These can be incredibly versatile and useful for quickly gathering some data about what works and what doesn't, but they can have a terrible impact on your page load times. A server side A/B test will always be better performing in that respect and we can help you get the most from Sitecore's testing features.

Working with Codehouse

If you're looking for some help with Google, or some SEO consultancy for your Sitecore website, our Digital Experience team can help. Get in touch.

In this first article of our Google Lighthouse series, we'll be looking at the Performance category. We'll be reviewing some of the most important, commonly failed tests and discussing our approach for passing them.

Before we begin it's important to note that there's no magic bullet for getting fast page loads. Often, great performance is the sum of many small things done right. That said, if you do only one thing, automate your image optimisation!

Image optimisation

One bad content image can undo all the other painstaking work done to craft a fast loading page. For a typical Sitecore website we can configure image optimisation. This will save content editors the headache of manually creating multiple copies of an image, as well as taking advantage of modern file formats such as WEBP.

Lighthouse performance metrics

Defer off-screen images

Once you've optimised your images, the next step is to lazy load them. This involves loading images only when they're needed. This can be especially beneficial to users on slow connections where images represent the bulk of the data transfer on a typical landing or article page.

Remove unused CSS/JavaScript

Google Lighthouse has always measured how much of the CSS is transferred when a page loads is actually used. After all, there's no point in delivering, parsing and executing code that isn't needed. Improvements in technology mean that Google Lighthouse will soon be testing JavaScript.

It sounds simple enough: "Only deliver code which is needed on a given page", but it's actually far from an easy task. At Codehouse we've developed a method of doing this in Sitecore that allows us to register the assets a component requires and add them to the page as necessary.

Eliminate render-blocking resources

When the browser is parsing the page and comes across CSS or JavaScript it must essentially pause to retrieve it, figure out what to do with it and apply the changes. While it's doing that, it's not getting on with the important business of rendering the page which users will see. For this reason, we call resources like these "render-blocking".

Of course, nobody wants to see that flash of unstyled Times New Roman text load before the basic page styles are applied, so there's always a balance to be struck. We'll always try to place resources in the most appropriate place within the document. Typically, JavaScript and non-critical CSS goes at the end of the document and any CSS relating to above-the-fold content is loaded as soon as possible.

Serve static assets with an efficient cache policy

Styles, JavaScripts and images change infrequently, so we always recommend setting a long cache policy on them. When you know a file isn't going to be updated, you might as well tell your users to hang on to their copy and use that rather than asking for a new one every time they visit your site - or worse, load a page.

You need to ensure that users can get the new copy of a file after you've released new code, but this is easily controlled with techniques such as cache-busting query strings.

Minimise third-party usage

Beware the temptation to add in countless tracking scripts via Sitecore content or services such as Google Tag Manager. Every one of these scripts comes with a performance penalty for your users, so it's important to periodically audit them and remove any which you're not getting real value from.

A similar issue we have encountered are A/B testing services such as Optimizely. These can be incredibly versatile and useful for quickly gathering some data about what works and what doesn't, but they can have a terrible impact on your page load times. A server side A/B test will always be better performing in that respect and we can help you get the most from Sitecore's testing features.

Working with Codehouse

If you're looking for some help with Google, or some SEO consultancy for your Sitecore website, our Digital Experience team can help. Get in touch.

THE EXPERIENCE ENGINE

Personalise your site in 20 days! No Roadblocks. No Upgrades. MVP Driven.

THE EXPERIENCE ENGINE

Personalise your site in 20 days! No Roadblocks. No Upgrades. MVP Driven.

THE EXPERIENCE ENGINE

Personalise your site in 20 days! No Roadblocks. No Upgrades. MVP Driven.

Talk to us about your challenges, dreams, and ambitions

X social media icon

Talk to us about your challenges, dreams, and ambitions

X social media icon

Talk to us about your challenges, dreams, and ambitions

X social media icon

Talk to us about your challenges, dreams, and ambitions

X social media icon