Getting a really high Google PageSpeed score on an e-commerce site is hard. Personalisation, plenty of content, detailed design, large images, custom fonts and third-party scripts all push the score down. So what can you do to raise your PageSpeed score anyway?
Google PageSpeed is a tool you as an e-commerce operator cannot avoid. It is important for several reasons, but it should not be the only tool you use to work with performance. Read more about what Google PageSpeed means for you here.
The most important reason to work with your PageSpeed score is to make sure your Google ranking is as good as possible. Google has probably always factored in PageSpeed as a ranking signal, but has since July 2021 given clear signals that it is a factor in how you rank. Content is still king, so a high PageSpeed score will not suddenly make you sail past your competitors. But it can be the factor that makes you rank past a competitor doing an otherwise equally good SEO job. A good PageSpeed score also means Google can show your site as a suggestion in Google Discover , which makes you visible to entirely new customers without them actively searching.
To succeed in getting a good score you first have to understand the factors behind the grade. And unfortunately these factors go somewhat against the grain of how a modern e-commerce site looks.
The highest grade is given to a site entirely without content. A blank page, quite simply. It is extremely fast to load on all devices and all networks. Every thing you then add risks lowering your grade. But a site entirely without content will not get customers to want to shop, so it is about finding a balance between things you add and the PageSpeed score you are aiming for.
As an e-commerce operator you of course want both to have the cake and eat it. You want tons of content, large and good images, as much tracking as possible to follow and measure the customer's journey and behaviour, and a stylish, detail-rich design. All of these unfortunately contribute to a lower PageSpeed score, but there are ways to at least have the cake and eat half of it.
The two undoubtedly biggest factors in your score are images and JavaScript. An e-commerce site almost always has a large image at the top of the page, either a product image on the product page or an alluring banner on the homepage. It is enormously important for your score how this or these top images are loaded, and how the rest of the images are loaded, for your score. If these are not loaded optimally, it will affect your Largest Contentful Paint (LCP) negatively, and it accounts for 25% of the grade.
The other biggest factor is the amount of JavaScript used on the site. If you have a lot of JavaScript, it will take time to load and run it, which often lowers the grade on First Input Delay (FID), Time to Interactive (TTI) and Total Blocking Time (TBT).
The amount of JavaScript is usually something you cannot control directly, but it is your developers who have to work with it. But what you can do is think both once and twice before you pull in third-party scripts for various tracking services, which often drastically increase the amount of JavaScript loaded. Do PageSpeed measurements with and without these to determine what impact they have.
To get an optimal Largest Contentful Paint (LCP) you need to tell the browser as early as possible which images are to be displayed. A typical page often has many images, and only a few of them are directly visible to the customer before they have scrolled. These images need to be loaded in advance via image preloading. You can use both <link> elements in <head> and HTTP headers for this, and HTTP headers are preferable because the browser discovers them earlier than HTML elements. Using HTTP headers will become even more important when/if Early Hints becomes a standard, because it allows you to send out HTTP headers in several rounds instead of all at once. Then you can send out a preload hint almost immediately and long before the server is done with the total response.
If you have responsive images so that a mobile shows an image at lower resolution than a desktop, you need to be careful about which variant of the image you preload. Because PageSpeed is judged with Chrome as the browser, you can use Chrome-specific functionality, described in this article. Unfortunately, preloading is not supported for responsive images in all browsers, so to be on the safe side the server needs to send out different preload instructions for mobile and desktop through user agent detection. Unfortunately the browser does not send along how large a screen the customer is using, so the only option you have is to guess screen size based on which browser the customer is using.
On a product page it is often fairly easy to know which image will appear at the top, but on a CMS page like the homepage with very dynamic content it is significantly harder. The homepage can have two banners that are both visible on a mobile, or a single banner that takes up the whole mobile screen. Your choice of system is very important here, because these have to be built so that this information can be produced without too much complexity. Your choice of developer/partner also becomes very important here, because they have to understand how to get this information and send it out the right way. Getting it wrong here can cost around 20 points on your score.
Because the score is set based on how long it takes to load and display the images, it is very important that an optimal size is sent out. If you upload an original image at 2000px, it must be scaled down to an optimal size for that customer's specific screen size. It is also important to have a CDN for images, because images loaded via a CDN load many times faster than without.
For pages with many images, it is important that images not visible before scrolling should also not be loaded. This can be achieved with image lazy loading, which tells the browser not to load images that are not visible before scrolling. All browsers do not support this (especially iOS) and until they do, you need to implement it yourself. In the same way as you preload images you determine are directly visible, you lazy-load the rest of the images.
There is a lot of talk about reducing the amount of JavaScript you send out, and that is good advice. But the real cost lies in when the JavaScript code is executed. Loading for example jQuery but then not using it has surprisingly little impact. That is because JavaScript engines are very capable at downloading JavaScript code and only executing what actually needs to be executed. You still have to be careful with the amount of JavaScript, but the first thing you should try to optimise is the code that actually runs.
Today many e-commerce sites are built as SPAs (Single Page Applications) which means the site is built as an application in JavaScript and all rendering requires JavaScript. That means the code first has to be executed once on the server to send out the response, and the same code then has to run in the browser to wake up the application. Which may seem unnecessary, but that is how the application knows which parts are interactive and which parts are more static.
The cost of this only gets higher and higher, the larger and more complex the pages you have. For a page that fits on a mobile screen, it is barely noticeable, but on a page five mobile screens tall with complex interactivity like carousels, it becomes a cost that will affect your score.
The best way to get around it is to wait to render until it is really needed. If a customer comes in on mobile, only what is visible on screen has to be rendered and become interactive, and the rest of the content can be rendered on scroll. If it is content not important for SEO, it is best if the server figures out how much content has to be rendered and instead just sends out the data needed to render the rest. If it is content important from an SEO perspective, you can use so-called partial hydration.
Getting a high score is not a one-off job. It is fairly common for a new solution to launch with a good or passing score, and then over time as changes are made and new features added, the score slowly drops. And you do not really know why. That is why it is important to keep making new measurements, and to measure in test environments before it goes to production.
Google Chrome contains tools for doing measurements locally, which you can do from your computer. But two different people can get completely different scores from their computers because those computers have different processors and memory. It is therefore important to always measure with the official PageSpeed tool , because it is the score there that really matters.
New functionality being built should be written so it can be measured with and without. In some cases it is easy in your CMS to turn content or functionality on and off and do measurements, but usually it is harder than that. Instead make sure the code is written so that functionality can be turned off via URL parameters, which makes it easy to measure in the official tool with and without, but also so you can then measure your own experience on a real mobile.
Making things measurable this way is the best way to start a performance investigation. If you have not done measurements for a long time and see that you have 25 on the score but want to get it up to 75, it can feel like an insurmountable mountain for everyone involved. By putting in the possibility to measure with and without various parts, you can more easily form a picture of what is costing you. There is probably some low-hanging fruit, but to get from 50 upwards, it is many small things that need to be improved rather than single things that can give a lot of points.
Related articles
AI does not only make development faster, it moves the capability out into the whole organisation. Suddenly anyone can build and change things in the systems. It is enormously powerful, but combined with old ways of working it leads to either chaos or no effect at all. Here is how you lead the shift from tree-tender to forest ranger before entropy runs away from you.
Technical debt is more than a technical concept, it is a business-critical reality that affects everything from time-to-market to customer experience. In e-commerce, where every millisecond and every click counts, the choices you make in your technical platform can have far-reaching consequences. When quick fixes are prioritised over long-term durability, an invisible but growing debt is built up. It affects not only development speed and stability, but at worst can slow the company's ability to innovate and compete. To face the future the right way, technical debt has to be understood, quantified and managed as the strategic investment it actually is.
For Swedish retailers there are plenty of ways to meet this threat by building on what the Chinese giants cannot offer: strong local brand stories, product safety and sustainability as competitive advantages, and a presence that ties digital and physical commerce together. Temu has no stores. Yet.
