Investigating Website Performance

Ecommerce sites tend to be heavy with a bunch of high quality imagery and increasingly, quite a bit of javascript to parse. The “cooler” a site is, the more javascript and high end imagery it probably has. There are many interesting options these days to make websites more engaging. Each of these options comes with a cost. But how much of a cost? Looking at some website performance tools, you may come to the conclusion that you should have a barebones, static website. But what really is a high performing website is different than several tools will tell you

There is no denying that mobile device traffic is exceeding desktop traffic for most ecommerce store owners. Most people assume that mobile = cellular = slow. A top result when looking for a way to test the performance of your website is the Test My Site page on think with Google … if you’d like to have a bad day, give your site with this tool. A popular, and very useful performance testing chrome extension for developers is Lighthouse … installing this and running it with the defaults will result in some indigestion as well. So why do these tools say my website sucks?

I ran a report on a client website using think with Google. The resulting report said the loading time was poor and it estimated that 30% of users will leave the website due to speed. Reading the fine print I see:

"Loading time: This is how long the primary content of your page takes to appear using Chrome on a Moto G4 device within a 3G network. Loading time can vary based on server location, device, browser, and third-party apps. If your site contains carousels, overlays, or interstitials, this may impact your loading time results. To test using different settings, visit"

OK so the test uses a $150 device on a 3g network. I’m curious how many of our client's customers have a similar situation. Our clients sell largely in the US so most of this data I’ll be looking at is US based. The majority of the developed world is not that different. I looked into network data for mobile devices via Google Analytics for some large client sites. Most mobile users leave wifi on because ~70% of mobile device traffic was over a broadband connection. This leaves about 30% of mobile device traffic using a cellular connection. I started investigating how much of this traffic is realistically over 3g. Using the July 2018 US report and Feb 2018 State of Global LTE report from OpenSignal I can see that about 91% of US cellular traffic is 4g or better. With 30% of mobile traffic being cellular and 91% of that being 4g or greater that leaves about 2.7% of all mobile device traffic using 3g for customers in the US. Looking at device usage and without spending too much time looking up processors for all the mobile devices listed in Google Analytics for our clients, I can confidently say that at least 85% of mobile devices used across client sites are faster than a Moto G4 with over 100 mobile processors being faster on this list. With these numbers in mind, it’s reasonable to calculate that 0.4% of our client's customers could use a similarly slow device on a slow network. The Test My Site claim that 30% of users will leave my example website is really 30% of 0.4%. So for every 999 visitors that are engaged with an advanced website maybe 1 goes away frustrated because of the site speed.

The Lighthouse extension for Chrome by default will slow down your CPU by 4x and throttle your network connection to 3g as well. If you don’t just click the little Lighthouse icon in your toolbar and run an audit within Chrome developer tools instead you’ll get options to pick between desktop or mobile and choose a throttling option. As you run reports, fun facts about performance appear on the screen. One is “75% of global mobile users in 2016 were on 2G or 3G” from GSMA Mobile. That’s an eye catching stat but one that probably doesn't apply to US ecommerce. Another one is “The average user device costs less than 200 USD” from the International Data Corporation. And another is “1MB takes a minimum of 5 seconds to download on a typical 3G connection” from the Webpage Test and DevTools 3G definition. True statistics but so what? What these two testing tools look at by default is not reality for US merchants.

Let’s dive deeper into performance and look at some other stats from Google. From Google’s DoubleClick blog, “14 seconds is the average time a mobile web page takes to load on a 4G connection”. That looks bad. But the count of 14 seconds is the average time to load everything on the page. Again, this is different from reality. What we want to look at is perceived page load time. How much time does it take until the customer sees something and thinks the page is loaded? The First Meaningful Paint metric is a good number to look at. This number represents how long it takes before the customer feels the primary content of a page is loaded. Most of our Magento 2 sites show this primary content to a customer in less than 1 second with nearly all customers under 2 seconds.

The Lighthouse tool does penalize most Magento 2 sites for a few more things that aren’t smart or possible to fix. It will often instruct me to “Serve images in next-gen formats” and suggests to switch jpg and png files to JPEG 2000, JPEG XR or WebP to provide much better compression. These are very cool formats with some amazing compression but they don’t work for the majority of customer web browsers so it would be a bad idea to switch to any of these formats yet. Another suggestion I’ll often get is to “Eliminate render-blocking resources”. What that means is that it’s more efficient to display all the javascript along with all the html in a webpage rather than including separate javascript files. The problem with this is that if you use the same javascript across most pages on your website, you should include it on pages as a file because then your browser can cache that content and not keep requesting it over the network. If the javascript is inline on the page, the browser will not cache it from page to page and your overall load time will be longer. The last thing I often see as a complaint is “Uses inefficient cache policy on static assets”. In our case this complaint often comes from including 3rd party services, Amazon, Google, Facebook where we have no control over the cache policy.

The big savings that can actually move the needle a bit for most of our clients comes with optimizing and efficiently encoding images. This is something that can easily, perhaps tediously, be solved manually by opening images in Photoshop and saving with the highest possible compression per image and no bigger in dimension than it will ever appear on a screen. A CDN service like Fastly offers help real time image optimization. TinyJPG also offers an API you can programmatically send images to and get optimized images back. Also these 3 companies offer image compression extensions for Magento 2:

From then smallprint on the Test My Site Google website, we can see tests come from This is a useful tool to give you an accurate picture of how your website performs without installing any extensions to your browser. Test My Site throttles the connection heavily but going to directly and testing with reasonable parameters will give you in depth data about what your customers really experience. For a quicker checkup on your sites, use Google’s Page Speed Insights. This doesn’t throttle connections anywhere near as much as the Test My Site tool does.

Don’t get burdened about low scores from some website performance tools out there. Read the fine print and see what they are actually testing and how. And always use your website yourself. Try it on different devices and see how it works for you. If you’re not an uber nerd, chances are you’re using a device and network similar to your customers. If the site seems fast to you, there’s likely not a bunch of big problems for your customers. With that said, most sites will have some room for improvement. Work with your developer to see what can be improved on your site and determine if there are valuable gains to be made on your site.