fbpx
Technical Development

Magento Page Speed: How to measure the performance of your Magento store.

With ecommerce now accounting for over a third of total retail sales in the UK, the experience that we offer our customers is crucial for our retail success. And site performance is a key part of this.    

This blog is part of a series on Magento Page Speed. To find out how to make your Magento store faster, check the second post in the series.

Why performance matters

Having a slow and poorly performing Magento store could impact your conversion rates massively, almost up to 20% on mobile alone. You can work out how much revenue this can cost you, by comparing your page load speed to one that has improved by one second. How much revenue would it be to increase your conversion rate by 20%? 

Exactly.

And guess what – this method will actually underestimate your loss. Failing to convert a new user into a customer is not just missing on one sale, but potentially all the lifetime value of a customer that has now gone into a competitor. 

Performance matters. A lot. Let’s start by measuring it. 

How do we measure Magento performance?

Performance is not all about speed. In fact, there are several factors that go into measuring the performance of a website. 

But firstly, let’s look at the tools we use to measure performance.

Page Speed Insights

We use a website called Page Speed Insights, based on Lighthouse, an open-source, automated tool for improving the quality of web pages. Lighthouse has audits for performance, accessibility, progressive web apps, and even SEO.  

It measures your page performance as well as the information on what your customers are seeing when they look at your website.

It breaks down what you need to fix on your website, and also separates out your Desktop and Mobile scores.

Run a test now and let’s break down your results.

Page speed insights are broken into two areas. Mobile and Desktop. Flicking between these areas will give you the scores for your website on each device.

The second thing you will see are the Core Web Vitals: Largest Contentful Paint (LCP), First Input Delay (FID) and Cumulative Layout Shift (CLS).

Field and Lab tests

The two tests that are being run on pagespeed are Field and Lab tests.

Field tests shows you what your customers are experiencing on your website, as well as any issues that you may need to fix.

You can also expand this view and see more detailed information on what people are reporting for this score. You may find that actually 80% of your users are loading the site fine but there is a cause for concern for 20% which could be having a real issue with the site loading in a non-performant way. 

Lab tests are done from the website itself and is essentially what you would see if you were running a Lighthouse test from your own personal browser.

With field tests being spread across so many different devices and over a 28 day period you may find that these scores are slow to increase, so don’t get disheartened at the beginning. 

You can also expand this view to see a small description of what the measurement is and a link to more information about it.

Lighthouse

The second tool we use is Lighthouse, available in your Chrome developer tools. This report allows you to run a test on a local website or environment and to see the results of that page. 

This is really useful from a development perspective as you can monitor performance in real time as you are making changes to a page, and see the differences that you are impacting. 

A suggestion for all Lighthouse tests is to run an Incognito browser window. This stops any caching from happening as well and additional extensions you have running in your chrome browser that could impact your scores.

The other advantages of Lighthouse is that you can also analyse the Checkout and other pages that require a user to have an item in their basket before proceeding.

What do these values mean?

Okay so you have your test results – What do they mean?

Largest contentful paint (LCP)

Largest contentful paint. It’s a measurement that Lighthouse uses to analyse the speed on which the page is loaded. It is used in both the Field and Lab tests of your website. It focused on the heavier components such as hero banners on the Homepage or product images on PDPs.

Be aware we have no control on what Lighthouse deems as the LCP so this could change or switch over time on your pages.

First input delay (FID)

First input delay is a test that is only done on Field tests and is not used in Lab tests. It is a way of testing how quickly an input from a user can be handled on your website. This is why you might find that it is high when you first load your website if you click on a link or interact with the page.

Cumulative layout shift (CLS)

Cumulative layout shift is a test that is done on Lab and Field tests and is around how much your page changes layout as it is loading. You may see this on any websites that are using Javascript to load in ads. As the page is loaded the content can jump around causing issues if a user is trying to interact with buttons that could easily just change and move position causing accidental clicks (which advertising companies might not be too worried about – but you should!)

First contentful paint (FCP)

First contentful paint is the time it takes for any of the content of your website to be loaded on top of the page. This can be any content and doesn’t have to be images.

Interaction to next paint (INP)

This test is only ever used on the field tests and is also at this time an experimental test (hence the little chemistry bottle). However this test is to see how all interactions happen for a user and how responsive they are. It will only ever return a single value for these interactions so you could find that the number is low but to improve it could be a single interaction.

Time to first byte (TTFB)

This test measures the server response time of your website. This test will normally measure the time it takes for your website to return the HTML of your website. This test can affect all other tests being performed so be aware if this test is high that it will make all other tests slower in comparison.

Time to interactive (TTI)

Time to interactive is a Lab only test so will only appear here. For the field test you will need to look at First input delay and Interaction to next paint for a similar metric. This measures the time it takes for a page to be usable for a user. This can be problematic as if a page looks like it isnt working a user could leave the website thinking that the website is broken.

Total blocking time (TBT)

Similar to TTI, total blocking time looks at the time when the browser was blocked from dealing with a user’s input. This is normally when something else is stopping the re-render of the page due to other elements being loaded. Again this is a lab only test and as the same with TTI you would be looking at FID and INP in field labs to spot issues with this.

Speed index (SI)

Speed index is a lab only test which is dealing with how quickly your page is visually loaded for a user. In lab tests you will be focusing on TTFB, FCP and LCP to see a similar metric. To pass this test you should be aiming for around 3.4 seconds for your page to be loaded. 

What pages should we measure?

The main pages to analyse are the Homepage, Category page (PLP), Product page (PDP) and in Lighthouse, we also measure the Checkout page.

You can also look at Google Analytics to find out your most popular landing pages, and measure these as well. 

Interpreting your results

Mobile Desktop
60%Some work to do No good
70%Target scoreSome work to do
80%ImpressiveTarget score
90%IncredibleImpressive

You are probably thinking – why don’t we just always aim for 100% for all of the Lighthouse scores. Who doesn’t like to score a 100?  

It’s a fine balance between having good features that your customers benefit from, and 100% on a performance test. 

Tests will change and scores will fluctuate per test run. So it’s not perfect. You will also note that the more images and javascript that is loaded on a page or even content the worse the scores will become, if this is not properly optimised. If you follow the rules above you should be aiming for around 70-80% on Mobile with 80% – 90% on desktop. Squeezing those extra points might actually be more hassle than benefit.

Apart from the overall score lets just briefly look at what the other figures and numbers mean in a test.

To start with, let’s go back to our results page from before.

You can see like we said before that the tests are broken into two areas. Fields tests which are above and the 

You will also always see that Lighthouse has improvements and tweaks to its versions. This is important as the weighting of each score can change per version.

You can take a look at what does what here – https://web.dev/performance-scoring/

Looking at this article here we can see that most industries and sectors are well above the performance lines.

So don’t overthink it.