We're hiring!

How can you make WooCommerce fast?


Article by Thomas Audunhus. Published on March 26, 2018

Steadily more people are having difficulties with the speed of their WooCommerce, and that might not be so surprising – because the number of WooCommerce stores is rising every day.  I also read  more and more bad suggestions on how to speed up WooCommerce. At Servebolt, we work with WordPress and WooCommerce performance on a daily basis, without taking the easy shortcuts. In this article you get my best tips on how to build a fast and snappy WooCommerce.

The WooCommerce performance basics

There are a few basic principles you should follow, to ensure that you have a fast WooCommerce. And when you are working with WooCommerce, it is important to keep in mind that WooCommerce itself is fast, it is everything you add to it that can make it slow.

Run as little code as possible

Every piece of code you implement on your site has at some point an impact on how fast a page loads. It is always a great idea to run less code to speed up the performance in WooCommerce. If you write the code yourself, you must make sure to write proper checks for whether or not to run specific pieces of code, and in what context. A simple example is that is is very important to not run code that is only necessary for the product page, on the category pages. Doing so, is a very common mistake.

Plugins – Uninstall and delete plugins you do not need

A common problem in WooCommerce, and WordPress in general, is the use of bad plugins. Plugins is a nice way to extend WooCommerce with advanced functionality, but many plugins contain unnecessary and/or bad code. If you have been running the same store for many years, then it is likely that you are using plugins that are no longer maintained, outdated and contain both bugs and security flaws.

Watch out for these – they kill performance

  • Visual Composer
  • Beaver Builder

Read more to see an alternative solution to page builders

Bugs – Fix all known errors

All webservers have an error-log, and that is one of your most important tools when it comes to making a well functioning and fast WooCommerce. All PHP-errors are logged in the error log, and if there are errors in the log, you should fix them!

There are two reasons for this. Firstly, it is impossible to maintain control of all pages on a WooCommerce site, it often contains thousands of pages – and errors can hide in the strangest places. You won’t be able to test all pages, but your users and robots will visit most parts of your site in aggregate.

Secondly, and more importantly – performance. It’s easy for a developer to think that “it’s just a Warning” or “that bug doesn’t produce any visible error”. But all errors (and notices and warnings) take time to process. How much time these errors consume is always underestimated.

Last week I helped to fix bugs on a WooCommerce that was upgraded to version 3 without checking the errorlog. After a couple of hours with intensive bug-fixing, no fresh entries were posted in the log anymore, and the performance of the website had improved with over 60%. Yes – you read that right, a sixty percent improvement!

PHP is the part of the code that uses server resources. But you should also pay attention to the front-end of your site. The same rationale applies to front-end, any bug will slow down the performance of your site. That means you should pay attention to the console, fix javascript bugs, test and check your CSS and last but not least – your HTML output.

Test and make sure important pages validate with W3C Validator

Properly structured and correctly written HTML is important to ensure fast an smooth rendering. And to check for this, you should use W3C Validator. If you provide correctly formatted HTML, the browser doesn’t need to calculate how it “thinks” this should be visually represented, it can just display it correctly at once – saving resources for other more important operations.

Database table types and indexes

It is important for WooCommerce to have a well functioning database. You should use modern table types for data storage, like InnoDB. In addition, there are many plugins that query the database in ways that are by default unsupported, or very slow. The basic rule is that all queries shall make proper use of indexes. This is an advanced topic for the many of you, but our plugin Servebolt Optimizer fixes table types and creates the most commonly missing table indexes, that very well could be in WordPress and WooCommerce by default. For the average WooCommerce shop we move in on Servebolt, the plugin delivers  20-30% faster loading times.

Last ned Servebolt Optimizer

Keep .htaccess small

The .htaccess file is an Apache Server configuration file. This file is used by WordPress for rewrites, but is is also commonly used for redirects and other functionality. Some of the banned plugins above try to build entire applications in this file, which will guarantee you slow performance. You can place .htaccess files in any folder, and as a consequence, the webserver will search all paths for and .htaccess when you request any file. This is time consuming, and gets worse if the .htaccess is large – because the server will have to re-read and re-parse the results on every access.

Anything you add to .htaccess can potentially slow WooCommerce down. We recommend using the clean, default WordPress standard, and to use plugins like Redirection to take care of redirects.

Don’t combine and aggregate files in PHP, use HTTP/2

Explanation of HTTP/2 by Cloudflare

HTTP/2 introduced a technology called multiplexing. Multiplexing enables the server to send multiple files to the client over one connection, as opposed to HTTP/1 where every element on the page required a separate roundtrip. This means that any gains we once got from aggregating and bundling files, now will just make your site slower – because it is unnecessary work. It is perfectly fine, and recommended, to use compilers as Grunt or Gulp – but avoid combining elements and files using PHP. This also means that you should not combine files with plugins like Autoptimize and similar.

Not all hosts use HTTP/2 yet. Servebolt has been using HTTP/2 (or it’s predecessor SPDY) since we started up in 2013.

Optimize your images, and use correct sizes

Modern web shops use many images. WooCommerce uses WordPress’ media function for image management, which means that all images that are uploaded are automatically produced in a variety of sizes. Even though this is a slightly old school way to scale images, it works perfectly fine – if you make sure to use the correct image sizes.

Adjust WooCommerce image sizes

Under WooCommerce Settings -> Products -> Show, you will find WooCommerce’s three standard image sizes. Adjust these dimensions to be exactly the size that you use in the store. That makes sure the browser does not need to recalculate and resize the image. That will save time, and you might also save transfer time when the image is as small as possible.

Optimize your images

Images contain a lot of data that is not used when displayed on the web. If you optimize your images, you can reduce the page sizes in your shop, and by that get faster and more snappy loading. On Servebolt we use a plugin called Resize Image After Upload that changes the size of the original version of the image to given max-values, and compresses it with a default setting. This generally works good enough, and makes sure none of the images on our site are oversized.

This plugin works only when you upload images, so it will not traverse over the items already in your media library. To optimize existing images in the media library, you can try one of these:

Choose fast hosting

No matter how much, and how hard you work to make WooCommerce fast – your site’s speed will always be limited by the speed of your hosting. Therefore, you should choose the fastest hosting you can get hold of. Our hosting is proven to be fastest, and we are delivering continuous speed improvements and optimization that ensure that you at all times get the fastest possible hosting. We have built the World’s fastest hosting by solving the problems at the right places, and save resources and time where ever possible – instead of adding more technology (read bad make-up) to the stack. This means that it is simpler to develop and maintain solutions on Servebolt, but also dramatically faster than alternatives. If you are having trouble with a slow WooCommerce, you should check out our hosting for WooCommerce.

Database performance is specifically important when choosing hosting for E-commerce. Shops are always heavy on databases, so faster database reads means faster performance in your shop. It’s also crucial to choose hosting that does not depend on caching to perform. Hosting that depends on caching, will at some point deliver bad performance to someone, because it’s impossible to cache everything – and caches need to refresh quite often. An example is the cart. The cart can not be cached, and should not be cached – and is a vital part of any e-commerce store. A slow cart or checkout will have a great impact on your conversion rate.

Use Caching Correcly

I’ve previously written about How does caching work in WordPress?, and various types of caching are important when it comes to WordPress and performance. But you need to use it right. You should not use Full Page Caching (like W3 Total Cache, Varnish etc) as an performance enhancer in WooCommerce. That will get you in to trouble either right away, or later. What you should do though, is to use Object Caching and Transients where it belongs.

The Object Cache is a mechanism that stores the result of a database query temporarily to the memory (RAM) so that the result can be reused at blazing speed later on the same pageload. This is a technique you should use if you are reusing data across sections of your page. An example can be when you are displaying products, and are fetching all product information – before you start using product information throughout your template. To avoid unnecessary duplicate queries, and to speed up the re-use of this information – Object Caching is the right thing.

Transients is a similar type of cache, but where results are stored in the database. This means that it lives across pageviews. A transient can be filled with whatever you like, but if you want to use transients right – you should store results of queries that are slow, or require a lot of computing power, and that seldom change. Remember to set a reasonable expiry date based on how often you estimate the data to change, or th frequency of the updates. To identify slow queries and find the queries you might want to cache in transients, you can use  Query Monitor fra John Blackbourn.

You can read more about how object caching and transients work in my article about How does caching work in WordPress?.

If you build or extend WooCommerce

Use actions to extend WooCommerce

WordPress has a Action API that makes it possible to add functions to different parts of WordPress or WooCommerce. Explained in layman’s terms the actions represent different points of time in your  code. This makes it easy ta add elements on specific places on your front-end, or functions that only run when WordPress or WooCommerce load etc. In addition to WordPress’ builtin actions, WooCommerce also has a list of actions which makes it very easy to extend WooCommerce.

To add your own function to an action, you have to make an add_action() like this:

<?php

add_action('action_tag', 'name_of_your_function', PRIORITY);

?>

 

action_tag = All builtin actions have a tag, and you have to specify for which action_tag your code is supposed to run.
name_of_your_function = All functions must have globally unique names. This specific function name is what you add to add_action to tell WordPress what code to run when action_tag is triggered.
PRIORITY = The priority this function has if there are several functions that are running on the same action. This can for example tell in what order code is triggered in the front-end.  1 runs first, higher numbers run later.

Avoid use of init

The init action is triggered very early in WordPress. It runs on all pages, every time. But don’t be lazy. Your code almost never has to run on  every page, and if you use the init action, it will. This will affect the speed of all your pages, both in the front-end and the back-end. You should always avoid the use of the init hook, unless this is the only right place to hook into WordPress. Being very specific about where your actions run, will make your code both more performant, more secure and steadier.

This is how you create your own actions, for others to extend

You can make actions yourself too, so that you for example easily can add function to the product pages.

do_action('your_own_unique_action_tag');

When you have made your own action tag, your templates – or other parts of your code can hook into this point of time in your site – and extend it with custom functions.

Don’t use Visual Composer or other Page Builders

Visual Composer and other page builders are often included in themes you buy. That’s because the page builders contain a lot of functionality, and make themes easier to sell and simpler to configure. Like mentioned earlier, more code (read more functions) does always run slower than less code. To get full flexibility in the page builders, they load a bunch of variables from the database, and trigger tons of PHP code. How much padding do you need? What color? Border or not? Round images or squares? etc. All these configuration options are usually run in realtime, making them decisions on every page load. This is why you should avoid page builders, and especially if you are building WooCommerce stores from the ground up.

There are no valid reasons to use a page builder like Visual Composer, if you know how to write PHP code.

You can get flexibility from without using page builders like Visual Composer

I am not opposing flexibility as a concept, but I am opposing flexibility that is unnecessary, not used, or comes at the cost of performance and efficiency. That is why we at Servebolt recommend using ACF Flexible Content Fields to make your own page builder. This enables you to define the specific fields you actually do need when building a page, and it allows you to convert your needs in to flexible types. On the flipside; this requires basic knowledge of PHP, HTML and CSS. But if you are building a store from the ground up, ACF is an easy match.

PHP template files are used when you make a page builder with ACF Flexible Content Fields. You can picture that every template file is a section on your page, that can repeat as many times as you like. And you can decide the order of these template files are used in when building a page. This is what we use for our own site (Yes, this one!).

What about Gutenberg?

Gutenberg will provide much of the functionality ACF already has been providing for a long time. You’ll will be building pages, articles and other content the same way we do this in ACF Flex Fields. This works like Flex Fields in the same way where you get blocks of content you can build with. Gutenberg is the future content editor in WordPress, and worth a tryout already now.

Read more about Gutenberg here.

Short summary

  1. Switch to Servebolt hosting, it will save you and your site’s visitors a lot of time
  2. Run as little code as possible
  3. Delete plugins you don’t need, and don’t use a large plugin to solve a small issue.
  4. Fix all known bugs, keep your error logs and console clean
  5. Validate the most important pages with W3C Validator
  6. Make sure you use HTTP/2
  7. Extend WooCommerce with actions to stay in control of what happens, where and when.
  8. Don’t use Visual Composer

Is all of this easy for you? Then you might want to check out our open positions, we would like to get to know you!