How to get 90+ in page speed with WooCommerce

Page speed has come up as one of the most important things many look at when choosing to invest digitally. In this article, we go through what performance is, its different aspects – and how we managed to get a near-perfect page speed score in WooCommerce.

What is performance?

Performance is a complex subject and involves many things. When we talk about performance, we usually divide it into Backend performance and Front-end performance (often referred to as “Page speed”).

What is Backend performance?

Backend performance is how efficiently the application performs various operations – or simply avoids performing operations. Good backend performance means for you as a customer that your e-commerce can handle massive spikes in traffic for a short time, for example during a product launch or a campaign. Backend performance is tricky to deal with, in other words, it makes it difficult as a customer to see the problems before it’s too late.

Professional hosting

We have our own hosting company, Synotio, with which we are totally vertically integrated. This means that everything we do, all the tools, and all the configurations, are adapted to work throughout the whole process.

It is unusual to have an integration like this, but it gives us great advantages – above all, the assignments take less time to complete. Synotio is built to scale and builds upon multi-node clusters as standard. We want our customers to grow and then this is a prerequisite. Most hosting companies do not provide this as a service before £2000 / month, but Synotio already does it at £150 / month.

Elaborate cache

All modern applications make use of well-designed cache. As a beginner, it’s easy to resort to various cache plugins, and these work to some extent – but they rarely do a good job and rarely handle any larger loads. When using a http accelerator like Varnish, it is possible to write efficient and complex cache logic whose performance is unmatched by plugins.

Most WordPress niche hosting companies include a simpler cache service, and so does Synotio, but with the difference that our packaging Qala uses the methods available with Varnish (e.g. Edge Side Includes) for ultimate performance.

This is not a solution that can be easily turned on at any hosting, this is the fruit of seamless integration between the hosting and the developers who build the site.

A very well-designed cache for a site with WooCommerce provides a platform in line with a static page generator or headless solution in terms of performance.

Remove uncacheable requests

Most of the plugins available for WordPress and WooCommerce are created for the consumer market. That can make it problematic to know if the plugins are professionally developed, with backend performance in mind. It is therefore important to choose a web agency with professional developers who actually think about this.

With a tool such as Blackfire or xdebug, developers can find out which uncacheable requests occur during page loads and ensure that these are avoided.

It is not unusual that during the development you unintentionally create some uncacheable requests. Continuous maintenance is therefore an important part for websites to continue to perform well over time.

We carry out this type of maintenance so that you as customers can continue to run your campaigns, and sell without the website crashing, and so that traffic peaks do not create a slow or unavailable page and protection against overload attacks.

How do we help our customers with backend performance?

We have collected all our “best practices” in one offer, Qala. We have worked for a long time with our WooCommerce solution and this has resulted in us collecting all the good things we have done in one place. Our focus has been to do what no one else can do – Scale WooCommerce so that the platform can handle hundreds of thousands of products, millions of orders, large amounts of discount codes and so on. Simply; Backend with performance.

Through its unique pricing and functionality, the platform has helped companies such as iDeal of Sweden, Equestrian Stockholm, Maya Delorez & Djerf Avenue to scale their sales to unimagined heights using a technology that is relatively cheap – WordPress and WooCommerce.

What is Front-end performance?

Front-end performance is how well the website performs in the visitor’s browser. Unlike Backend performance, it is easy to measure this performance, for example through a tool like https://web.dev/measure/. With this tool, the website is measured in 4 ways; Speed, accessibility, best practice and Search Engine Optimization (SEO)

Speed

Speed is of course how fast the website is. This is ultimately very multifaceted. To begin with, the design of the page affects a lot. Does the page have heavy images? Does it use video elements? Are the pages very long? Are there a lot of features?

The effect of this design is then that different features are created by developers, and each one must be optimized to perfection in order to give a high rating. The different parts can be optimized in several ways, including

• Minification – Remove junk characters and spaces that take up space in code
• Minimize the number of heavy fonts
• Better image formats
• Correct image sizes
• Tree shaking – Remove items that are loaded more than once or not needed
• Delay / Timing: Tell the browser to load the resources needed when they are needed, and not otherwise.

Accessibility

Accessibility is also a function of Design, but also of the design of the code. For example, people who have difficulty perceiving colours may find it very difficult to find their way around the website if the designer of the website did not consider this. If the person who built the menu has not thought about accessibility, it will be next to impossible for someone with impaired vision to use the website.

Many people in our society have these needs and are effectively excluded if these things do not work. It is also a requirement for government authorities, and in some countries (eg Norway) it is a requirement for everyone.

Best practices

Best practices are about how well the site is programmed and that “normal things” that you should expect are in place.

• Does the site use HTTPS?
• Does the site use JavaScript that has known security flaws?

You could say that this part is a kind of “Other” category for Google.

Search Engine Optimization (SEO)

SEO is simply about how well the website looks to Google and their crawler. Most often, the problems here are caused by you as an editor and can be easily changed, but some things developers have to do.

Why do you want the page to have high front-end performance?

To increase conversion

Website speed is the first impression on your visitors and if the website takes longer than four seconds to load, the odds are that your visitors will leave the website and up to 46% of users will not visit a poorly performing website.

A slow site can cause unnecessary frustration and these days people don’t have the time or energy to sit around waiting for a website to load – especially if there are competitors they can turn to instead.

To position yourself better in the search engine rankings

A couple of years ago, Google decided to expand the parameters of its search engine and add website speed to the list of ranking factors. This is logical – the visitors to your website appreciate high speed and short loading time, as mentioned before, the odds are that they will leave the page if it takes more than four seconds to load, and Google wants to serve the best for its users.

But this doesn’t mean you should prioritize speed over content quality, reputation and relevance on your website. But it’s a factor to keep in mind when working on your SEO because not only does it improve SEO rankings, but it also gives your audience a better experience, which in turn leads to a better conversion rate.

Example: How we got Qala E-commerce to get 90+ page speed score.

On April 8, 2022, we launched Qala 3.2, which largely solves all backend problems and uses everything we’ve learned in recent years to be able to scale E-commerce. Finally, we had a solution that solved the most common customer problems! What was not as good, however, was the Page Speed Index.

Using Google’s website quality service (https://web.dev/measure/) we got the answer that although we had now succeeded in creating a platform that could scale the number of orders – it was really slow in the browser. A real conversion killer. Ouch.

Luckily, we’re pretty good at what we do, so we decided to fix it. How hard can it be? It would turn out to be quite tricky. Note that the screenshots were taken over a longer period, so we have also had time to fix things like Accessibility and SEO. Best Practices started low because we didn’t make the theme compatible with theme.json, which blocked us from making major updates to WordPress until it was resolved.

How did we increase page speed?

In the report, you get a lot of help and tips to improve the website. Thanks to our add-on Qala Imgproxy, the images are automatically adapted to the correct format, and images that are continuously in the content are automatically rescaled to adapt to the device you are on – mobile or computer. Therefore, there weren’t that many things to fix around images. However, what we needed to look into was the amount of JavaScript, because here something was off.

1: Minimize the amount of JavaScript

WordPress’s both strengths and weakness is that there are an incredible number of plugins available. The problem is a standardization problem: Different plugins can use different libraries – sometimes to do the same thing. This means that it is very easy to bring in a lot of unnecessary rubbish.

We came up with this list of measures:

1. Cleanup: Remove unnecessary items and only load resources when needed.
2. Standardization: Make sure not to use different libraries to accomplish the same thing so we allow for a tree shaking process.
3. Streamlining: Use a tree shaking process to go through all components and minimize the javascript.
4. Timing: Make sure the most important components load immediately when the page loads – let the rest load later.

Cleanup: Remove unneeded items and only load items when they need to be loaded.

The first thing we did was review which JavaScripts were needed and not needed. An E-commerce site or an advanced marketing site often has many components that consist of JavaScript. We went through every single component and found a few lines of code that were poorly designed and then caused a chain of other JavaScript to be loaded.

It could be a loading icon that was downloaded, which in turn downloaded a large number of other scripts. Many plugins also call functions and scripts whether they are needed or not. By going through the code base and making sure that this does not happen, many unnecessary scripts and other things can avoid being loaded.

With this improvement, we removed about 1/3 of the weight of the page (-500kb), but Google only gave us a small increase in rating. However, we got a number of improvements for SEO and Accessibility because our solutions for performance were also solutions for these areas.

Standardization: Use fewer libraries

Since we have been developing our framework over a long period of time, it turns out that we accidentally included two different slider libraries. A more modern (swiper.js) and an older variant. These were all converted to the more modern variant so we could discard the older variant.

This point is one of the biggest and most complicated but also one of the most significant. To implement this measure, we needed to dig very deep. For example, some plugin creators can use WordPress “standard” components to display things like a “loading” animation. This in turn means that a huge dependency tree may need to be loaded completely unnecessarily. With the wrong plugin installed this means a number of megabytes.

1. Go through the theme and all plugins and review which components they load
2. Go through the theme and all plugins and blocks and review how they load their assets – a misstep and scripts etc. can be loaded where they shouldn’t
3. Make sure that components such as WordPress built-in libraries use external libraries (otherwise several MB of unnecessary javascript + CSS will be loaded)

Streamlining: Use a Treeshaking process (JavaScript)

Due to the fact that so many different solutions are used and put together, and that each of these has its own components, a very large amount of duplicates of different dependencies are created since each component fetches (mostly the same) things in a dependency tree.

By creating a build job that goes through all components and shakes away (tree shaking) the components that are duplicates, you can reduce the total amount of javascript that is sent. This shaved another 500kb off the weight of the page, but we didn’t get many Performance points.

Timing: Defer / Delay JavaScript that was not needed immediately so that they are loaded later

To facilitate the work with performance optimization, we have created a tool that we call Qala web vitals. In this tool, there are settings to be able to choose what you want to preload, and what you want to delay. What wasn’t there, however, were ready-made settings for our default scripts.

All said and done – we made sure to apply these things to our scripts. Accessibility got a little worse here because we accidentally changed the size of a header in the test environment we run the tests against.

2: Reduce render blocking

At this point it was time to grab our CSS. There are many different solutions here. Many modern frameworks such as Tailwind pre-render the entire site and then have a build job that removes unnecessary CSS, etc.

The downside to something like Tailwind is that it’s simply not compatible with anything else in the WordPress community. It removes a bit of the upside with WordPress as a solution, while at the same time it becomes very consultant-driven, and in 2 years the next new big framework will be released and we will create big problems for our customers. As we say at Angry Creative: Newer is not better – Only better is better.

With that in mind, we instead had to find a solution. For now, we chose to use Perfmatters, which solves many of the problems, even if it is not as good as, for example, Tailwind.

Streamlining: Rebuild CSS so that all critical content loads first

By partly manually rebuilding our SCSS, but also making sure that everything the browser needs to load was in one place that was loaded directly, we were able to increase the rendering speed quite significantly. We took the opportunity to update WordPress here too 🙂

Streamlining: Build in 3rd party components to be able to Defer / Delay (CSS)

By moving things like fonts directly into the website, we could more easily choose what to defer and in which order things were loaded. When fonts are loaded from Google, there is a theoretical possibility that Google is “spying” on your visitors, but it also causes the page to “jump”.

By moving in several third-party components, we can control how they are loaded and when, this allows us to more precisely control what is loaded and when.

Conclusion

There are many aspects to consider when looking at web performance. It’s rarely as simple as just enabling a cache extension and hoping everything will be super fast. Continuous optimizations and professional solutions are usually required and, not least, you should ideally have hosting and website developers working in symbiosis to achieve top results. Load what the visitor needs, no more.