DE{CODE}: 6 WooCommerce Dev Tricks for Building Fast eCommerce Websites
Next to sales, site speed is perhaps the most important metric for your eCommerce websites.Why? Fast eCommerce websites get more traffic, have higher conversion rates, lower bounce rates, and generate more return visitors. In this session, WP Engine Senior Product Manager Jeremy Benoit and Engineering Manager Catherine Kelly explore developer tricks, WP Engine features, and other tools to make your WooCommerce store even faster.
Session Slides
Full Text Transcript
JEREMY BENOIT: Hello, everyone, and welcome to DE{CODE} 2022. This is the e-commerce track. I’m Jeremy Benoit, senior product manager with WP Engine and we’re here to talk about six tips to improve WooCommerce performance. Joining me today will be my colleague, Catherine Kelly and let’s get started.
So I’ll start by sharing a quotation from one of our software engineers, Chris Weigman. And as he put it, According to Google, 53% of users will leave a site if a page load speed takes longer than three seconds. That means you got exactly three seconds to get them all the data on that product page, all the images you’ve sent them, all the information about it, all the little widgets and ads and it goes to show you a bit why we’re talking about speed today, because the speed of a shopper experience is crucial.
Page speed is the time of a single page to load, and it can be measured in a variety of ways. Two critical ways are Time To First Byte, which is used by Google PageSpeed Insights, or Time To Full Page Load or Last Byte, which is often a reflection of what shoppers experience. The page speed also impacts conversion rates on your shopping site, and it’ll also impact the SEO of your e-commerce site as well.
One critical piece of speed is superb hosting for the quality of your shopper experience. At WP Engine’s compute optimized platform we provide an enhanced E-commerce experience for improved performance on all of your shopping content, static or dynamic. And we’ll talk about those two different content types here in just a second as we kick in to the 6 tips and tricks. Now I’ll hand it over to my colleague, Catherine.
CATHERINE KELLY: Cheers. Thanks for that, Jeremy. Today we’re going to cover off six tips in relation to WooCommerce, its configuration, and setting up an E-commerce store. For some of you seasoned developers, these tips and advice will be fairly familiar to you, but for some of the newer developers you might gain some useful insights.
So today we’re going to cover off WooCommerce and caching, media optimization, search optimization, Ajax cart fragments, custom orders table, and the speed of headless. So for the first one we’re going to cover is WooCommerce and caching. Before we get into that, we want to understand what are the different options you have in relation to caching, what it is, and then we can approach how we’re going to make improvements to it.
So caching can give the impression of being a holy grail in relation to performance problems. When in fact, caching was originally created not in relation to performance, but it was really for computers to have an automated response to the same request over and over again, rather than having to recalculate it every single time. Caching is a technique which is used a temporary store a response to a request, and then to deliver that same response to the exact same request to the same resource at a later point in time.
So it’s a bit like one of those annoying children– your annoying child who would ask you the same question over and over again, every single day, like why, why, why, and you just want to give an automated response to it. And this can work really well and when serving up static information for static sites, you’re always giving the same response. However, this approach doesn’t work too well with regards to e-commerce, because it throws a spanner in the works because the requests that are submitted to the server every single time are not always going to be the same, and you have to handle and control in relation to carts, different requests from different users at the same time.
You also want to remember previous transactions that you have in relation to your customers, what’s in their cart, you want to remember what’s no longer available in your store so that cart can accurately reflect what is being served up to that user. You also want to make sure in relation to caching that you’re not giving a cart which is related to customer A to customer B, and they can actually see what someone else is actually ordering, basically leaking information, which you don’t want. There is a finite balance that you can have in relation to caching that you– which is pretty tricky to serve up when you’re attempting to serve what is a personal touch to your customers so they remain engaged on your site. So the different levels and types of cache we have– a server cache.
And server cache is generally like any other cache. It is basically the cache that is on your server in terms of when you build the page and you serve that out to a particular request. When you’re standing right beside that server and you make a request, your response can be instantaneous. However, when you’re, like, 1,000 kilometers away, like your e-commerce individual or user, that responds can take a lot of time to hit them.
You then have application cache. And application cache in WordPress and WooCommerce, you can use plug-ins for managing it. plug-ins like W3 Total Cache, WP Rocket all have options for managing the in-application cache and these plug-ins basically store a temporary version of a requested page and a file on their servers. This can be– however, this can be a very inefficient way of caching and should not be used if you have the ability to cache either on the server itself or in a service like accelerated domains or Cloudflare, which distributes the cache globally.
You then have browser cache. And browser cache is basically the end user’s cache. Have you ever experienced, for example, something on a site that you’ve updated and you don’t automatically see that in the front end when you’re kind of developing and reviewing your site? This is because it’s been cached to that actual browser. It’s basically a temporary version of that page or asset stored in the browser of your user on your computer or your phone.
It’s there so you don’t have to download the same page or asset multiple times to speed up the display of that page, which works, again, pretty well when you’ve got a static site. But when you’ve got a dynamic site like an e-commerce site, we’re always trying to serve up products, descriptions, and information. It can be– it’s not as effective as you would like.
You then have what’s known as proxy CDN cache. A proxy CDN cache is a cache that sits between your origin server– so that’s the server that develops and presents increased the first original page– and the actual user’s browser itself. It’s accelerated domains and Cloudflare is a type of proxy CDN. And all requests and responses go through their domains before hitting the original server.
It is essentially a group of servers that are strategically placed across the globe with the purpose of accelerating the delivery of a static content for your users. So it’s almost like they’re standing right beside the original serving server when they’re 1,000 miles away. So it speeds up the serving of that page. And once your static assets are cached on all the edge servers at a particular location, all subsequent visitors and requests for static information is delivered from what’s known as your edge servers, instead of the original server, thus reducing the load, and speeding up performance, and improving the scalability.
So this all works very well in general with regards to static sites as mentioned. But e-commerce caches put a spanner in the works. And the e-commerce– the reason that there’s a spanner in the works is in relation to your logged in pages, your carts, your checkouts, your wishlists, which are dynamically updating all of the time. So they’re not static as you would require on the normal, for example, blogging site.
Generally, you can cache the GET request. And with GET requests, or like the name suggests, a request to get some resource. Even though the GET requests are often safe to cache, like mentioned, you don’t want to be caching again the logged in page, the carts, and the checkouts. You want to be serving them always up as fresh and new as possible to the customer so it’s up to date and accurate.
So you don’t want to deliver something from the cart and not write– don’t write it with cache. Generally, when you have something in the cart, most servers will bypass the cache completely. Thus, you’re back to the problem of you’re serving it from your original server rather than from your CDN. So what you have to do is you have to be clever about it and figure out, OK, how can I serve static elements from my CDN provider but always apply the dynamic from my actual original server so everything is up to date and accurate?
So the things to pay attention to– for server cache, since the server generates the web page, server caching enables it to remember parts of the page on the whole page that is not generated from scratch every time. And with browser caching, this helps the browser to remember what a web page looks like so it doesn’t have to spend time exchanging data with the server. And this is useful, as mentioned, for visitors who are accessing multiple pages because there can be static files. For example, styleSheets, JavaScript files can all be stored in the browser.
So for best practices with regards to caching, always cache HTML selectively. Basically, as a first level, cache everything to act as like a static anonymous– for a static anonymous content. And then look to bypass cache on cookies and cache everything that is in your cart, in your wishlist using a cookie to bypass particular elements of the cache. And always then set your age cache, your time to live, with it in regards to your Cloudflare configuration. That should ensure that your cache is always kept up to date and matches the original origin.
So one of the things that we understand from talking to our e-commerce customers is this is a problem that generally developers have to go and solve on their own. So as part of our development in WP Engine, we’re actually working on an e-commerce specific solution, which allows, by default, supply and install of WooCommerce with all of these caching rules set by default. So we cache all the static stuff and then don’t cache all the dynamic stuff so it’s always fresh. It’s always refreshed continuously for you. And thus, you have no conflicts like cart fragmentation for your users.
Media optimization– another thing that’s critical with regards to delivering content from your server to your end user, who’s on your e-commerce site, is around media optimization. The first thing to think about is, what is media optimization? What can we do about it? And how can we ensure that customers have a fast, effective, and dynamic experience when browsing and utilizing their site?
So with regards to images and video, they require different types of optimization, again, to give your customers an optimal experience based on the device that they’re actually using. So media optimization is a process of using the best tools, advanced strategies, and experiments, because you always want to be experimenting to deliver the performance of an e-commerce site. You want asset optimization. It seeks to find the balance between efficiency and reliability.
So you want to be always delivering the content for your customer in the fastest way possible that doesn’t end up being detrimental to the performance of your site. You want to serve the best-looking content in the shortest amount of time by taking into consideration the different platforms and assets that the media may be consumed on so, for example, a laptop, or PC, or mobile device, and, as we move into the world of headless, multiple different types of devices like TV screens, iPads, and stuff like that, where content can be delivered as well from an e-commerce store and consumed.
So what you want to think about is improve image optimization to improve the web– the performance of your site to drive more traffic, to increase those conversions, to grow revenue for your store owner, for your brand, or your merchant. And one of the most critical aspects of website optimization, it has an impact into searching and optimization. So if your images and your video are fast and quick, you actually get a better rating within the regards to search engine optimization.
Optimize assets not only make ones– your products more appealing and more visible to prospective clients, it also makes them appear more often in search, again, the search engine optimization. Key things to remember, is to look at lazy loading for images and videos. Lazy loading is basically a strategy to identify non-blocking or non-critical resources and load those only when needed. So the content, basically above the fold, is loaded and displayed to the user as a priority and then we delay all of the rest of the rendering for everything below this screen so anything that they scroll down to.
This optimization technique allows displaying first– the first images and content the user will see. And then we don’t waste resources downloading stuff they’re not actually going to view and see yet. Google itself recommends lazy loading and refers to it as deferring off-screen images, basically. And then I’d say don’t bother loading it.
You can manually, as a developer, tag each of your images if you want or your video as lazy loaded. But as you can imagine for an e-commerce site, doing that would be quite a hefty effort. And also, if you don’t feel comfortable tagging manually each one of those images, you can use a plug-in to do it. If you have a quick search in Google for best loading plug-ins for WordPress, there’s some recommendations there for the best plug-ins to use.
But for us and in e-commerce, we would recommend sticking them in, for example, to WP Rocket. It offers Adobe lazy loading optimization. The things also that you want to consider as well is always remember your mobile users. Their screens and their performance are smaller so you don’t need to load massive images. You want to scale that down.
You want to use compression for all over your images, because that will save huge, 40%, on the bandwidth and also then obviously the loading of that particular screen and file format is key for images. For example, as there are 600 by 600 image in JPEG is 100 kilobytes, PNG is 216, whereas a WebP is only 56 kilobytes. So you want to be very careful in considering, OK, what is the file format I’m going to use for all of these images that are going to be served up? Especially from an e-commerce site, I could potentially have thousands of products, thousands of images, and hundreds of videos to back up those images and that content as well.
You want to always kind of resize your images. You can look at online tools like Imagify, Youoptimizer, TinyJPG, and look at those for optimizing your images in WordPress. Imagify is made by the same team as WP Rocket and it’s a very intuitive plug-in that compresses images automatically using three different types of levels– normal, aggressive, and ultra. And it allows you to tailor that image size that is suitable for your end users.
Pay also attention to your thumbnail sizes. Keep them small, because they’re small anyway. Keep backgrounds simple. Use tools like remove.bg and Slazenger to remove backgrounds and update backgrounds to simplify them. And also then use a CDN for faster global delivery. Always, as well, with your images, always attach alternative helpful labels to those images.
This helps with SEO, search engine optimization. And always make sure that your labels actually reflect the content of your image or your video. As developers, sometimes we can do abbreviations like RDHD or just go a Y band. We know that’s a red hat with a yellow band. But SEO wouldn’t know that is, so try and be more real or language in terms of image presentation.
So video optimization as well, use data compression tools. Again, remember your mobile users. Convert everything, if possible, to HTML5 formats. For any video that has no sound, remove the audio altogether. There’s no point having it because it just consumes bandwidth. Use again, content delivery networks. Specify your video sites and again, also with regards to lazy loading, always defer loading those images until your page is completely downloaded.
Search engine optimization– as we may know, search optimization is basically a method of what we call offloading your search to a particular service provider who are experts in that because they can increase the effectiveness of your search and thus increase your sales for your merchant and user. As we know by default, WooCommerce does come with an inbuilt search feature. But it leaves a lot to be desired in relation to functionality around matches for product attributes, custom fields, and descriptions. It is very slow. It doesn’t offer a good user experience. And at the end of the day, it’s very ineffective.
If you do a search for– a product search with regards to WooCommerce, it is a common feature with regards to it either not working as effectively as you want. Really, what you want to do is have a search feature that has a strong error tolerance so it doesn’t interrupt the customer journey. You want them to be able to have a strong query autocomplete and have it in a natural language processing for better results, all of which is missing from WooCommerce search.
You also then want to have a feature around comprehensive analytics for easy improvements in reporting so you can actually look and see the effectiveness of your search that you’ve built in terms of the responses to it, what are your customers searching for, how well does that match with regards to the products, and then what changes can you do in configuration to actually help that? Basically, help your customer find what they’re looking for faster.
And so what can we do? As I mentioned, what we do is in order to reduce the friction in the search experience and help customers find what they want, we use offloading of search. So it is a process basically performed by a third party. It improves on the WooCommerce search capability because it’s integrated with Woo. It has basically widgets for filtering as you require. It provides results to users, which can help improve brand trust.
It has autosuggest, and you can configure and tailor the weighting. You can give customer results– custom results. You can have instant autosearch and search analytics, as I mentioned, which is critical. There’s no point having a search if you can’t analyze the search to see how effective it is. And also it helps in relation to fine tuning your SEO integration to ensure customers can find what they want. When they go to searching Google, they go it’s on this particular site based on what you’re looking for.
It also helps uncover customer intent and reveals data around customers’ interests. What are they looking for? What are they looking to buy? What attracts them to your site? What are they searching for?
Our recommendation around searching is look for autocomplete. So make suggestions in relation to that. And always have error correction enabled. So if someone typed in something that’s incorrect in relation to a product, try not to remember that. Try and always remember the correct spelling or description in relation to a product. Never, when you have search enabled in your site, allow a user to hit a dead end.
Always have a page. Even if they’re searching for something that’s not on your site, direct them to a page that says, we can’t currently find that particular product. Please contact our sales department and so on, and we can help you to do that. This is a better experience to that particular user and would also generate trust with that customer.
Optimize always. As you do analytics research based on what customers search for, optimize in relation to those terms so when other customers then come back looking for them can actually discover them. Use tags, titles, and descriptions on all of your products. They are the bread and butter of your search.
So make sure all of your data is accurate, it reflects what the product is, and always describe as much as possible individual products that are on a particular merchant site. Configure your search for mobile. And mobile search is a little different to laptop searching in terms of website, shall we say. Just make sure that you’ve configured and enabled that in your search. And always refer back to your analytics.
In terms of WP Engine, we’ve partnered with ElasticPress to an offer to, basically, what we believe to be a premium search plug-in that’s automatically default and installed as part of our e-commerce offering. It offers all of autosuggest, weighting, customer results, and many more.
And now I’m kind of complete on my three tips in relation to advice, guidance for WooCommerce and I’m going to turn it back to Jeremy. So here you go, Jeremy. Thank you.
JEREMY BENOIT: Another area to look at is the AJAX cart fragment. The AJAX cart fragment is a wanted piece of code. It’s known for its generating delays, causing server spikes, and running unnecessarily. But is the AJAX cart fragment really that bad?
Well, its purpose is to update the cart with new products, new product prices, new product quantities, calculate pricing without forcing a page reload. The cart fragments agent script, though, runs on every page– the home page, the product page, and even pages where there aren’t add-to-cart actions. That could be your about us page or even your contact us page.
Now, this running or this execution is often the culprit for, sometimes, server spikes or unnecessary resources being utilized that interrupts the performance of your site and your shopper’s experience. Now ideally, the cart fragment AJAX should only run where you have an add-to-cart action or if you’ve got a dynamic cart on your site where an action may be used to open or dynamically interact with the cart. So what can be done about the AJAX cart fragment?
Well, most often, people suggest, as we do, to disable that cart fragment and there are two ways to disable the AJAX cart fragment. A, you want to add a plug-in that has a cart fragment disabling capability. There are quite a few plug-ins out there that can disable your cart fragment. But the other means is if you’re familiar with editing php, you could disable cart fragmentation through editing the functions.php file of your theme.
There are some risks. Some cart widgets may experience problems when you’ve disabled the cart fragment. So you want to test your cart widgets after disabling them to ensure that they function as desired.
Now the next trick or tip is to utilize the custom order table once it’s released. You may ask, what do you mean? Well later, in this– in DE{CODE}, you’ll hear from WooCommerce about the new custom order table that will be released later this year. And the WooCommerce table is– the orders table has a structure dilemma. Many of you know, this is often pointed to as the reason for poor scaling. But it can also be a problem for speed when relating with interactions that deal with products, or interactions that deal with orders, and, sometimes, even plug-in data.
Right now, WooCommerce uses the post meta table that stores a variety of entities of data, including orders, and products, and some added plug-in data and any time there’s a call for any one of those entities, they’re all hitting the same source. So you can imagine relieving that traffic jam by creating custom order tables will add a structural integrity of WooCommerce of a true e-commerce engine and improve the speed of any kind of order activity. This will be a great support, especially for sites that have high traffic, and high order volume, or even sites that have a very large product catalog.
By having these three different types of tables, new core tables for the core order information, new plug-in tables for plug-in data specifically, and new meta tables for any kind of custom metadata that a developer needs to store, that will relieve the bottleneck that the post meta table previously and currently has for your orders’ interactions. There will also be dedicated indexes for these tables, which will help the speed of retrieving those specific entities in each of those tables. And you’ll hear more about custom order table later on in DE{CODE}.
So let’s take a look at the third improvement, the speed of headless. So this tip is to go headless because headless, the headless stack, increases speed by orders of magnitude. The JavaScript code in the front end of your headless infrastructure will be much faster and, in some cases, 10 times faster than traditional WordPress infrastructure. We even have customers on our Atlas infrastructure that are seeing six-times increases across all Lighthouse metrics.
And at WP Engine, we have a headless infrastructure called Atlas. That infrastructure allows– also has a component called our content engine, which greatly increases the speed of retrieval of all kinds of content static and dynamic across your WooCommerce instance. Headless infrastructures also allow you to customize back-end integrations and creates opportunity for lightning-fast optimizations with those third-party applications that your WooCommerce site needs to integrate with. And that’s my last tip for today.
