Workweargiant.co.uk | Topline Parts

Client Requirements

Before the project starting, workweargiant.co.uk had been running on a well-specced server, with adequate resources. Its main downfall was it was reliant on an outdated version of Woocommerce ( e-commerce suite built for WordPress ). 

Due to the site’s reliance on the outdated e-commerce suite, it was also suffering from poor database performance. Woocommerce upgraded its database model in later versions for stability, scalability and performance. Unfortunately, if the client had decided to update their existing Woocommerce install at that time, the site would have been rendered unusable. Other issues existed also. Some of these were small problems, which with some development hours could perhaps have been overcome. Examples include;

Plugin / Database bloat

The existing site had been forged using a combination of large, heavy plugins which, while they served their purpose, often included large amounts of code that wasn’t necessarily required and would often load additional libraries that were never used. Each time the site loaded it would load these plugins in their entirety, regardless of required features. As the end result, loading each page would become slower and slower.

Outdated Custom Code

To understand how we could make the code more efficient, we had to reverse engineer the code that already existed. We needed to understand what it was doing, why and also when. We got to know it like an old friend. Firstly, it wasn’t bad code. It was just outdated, a product of its time some five years earlier. Built with and for a version of PHP that had already passed its end of life. When a method is called in PHP by WordPress it takes time to process. Older versions of PHP would process methods in a certain order and achieve their result in a certain amount of time. Over the past couple of years, the geniuses behind the language have made every effort to get the most out of the framework. With each revision its processing times became quicker, its processing overheads became smaller and we’ve been able to format our methods to be as efficient as possible. 

Slight digression, the point was that had we updated to the latest versions of PHP the existing code would not have continued to function.

Page Speed

Google announced that page speed was going to be a big part of their 2021 algorithm update. A scary announcement. One that would send a shudder down the spine of anyone managing a website. The crux was, the longer the pages on your website load, the less chance of ranking well you have. For workweargiant.co.uk this was perhaps the largest mountain to climb. It was certainly at the centre of the client’s focus. The majority of their sales came through Google, with most people landing directly on a product page via a shopping ad or similar. Spoiler, they were the slowest pages. For good reason too, the site itself was home to an enormous collection of products, some with over 50 individual variations of colour and size. 

The Customiser

One of the site’s largest selling points, a customer could upload an image or logo, or choose to add some custom text and have that either embroidered or printed in a range of sizes, in a range of positions. The customer would select these options and upload their images while they were on the product page. This all happened before adding the product to the basket. The existing implementation used a mix of plugins and custom code to achieve the result. The plugin was problematic here. Although it did what was needed, every time it loaded to do the task of showing a small form on each product page it also loaded an epic amount of features that were never used. Slowing the page down even further. The only approach we could live with here was to build this from scratch. No libraries, no plugins. It would have to be vanilla. It would have to be fast and light.

The Data

The product dataset for this particular site is built up from different foundations. A product set from supplier A and a product set from Supplier B. Both in different formats. This would cause issues with regular stock updates and product changes. Often the import of both datasets would be enough to bring the site to its knees. It’s hardly surprising though, what with set A being some 92,000 rows and set B being some 50,000 rows. 

Work Begins…

With page speed at the top of the list, we worked our way down through every plugin, every method, every image and every product. We

 needed to save seconds of each page load. Many, many seconds. One of the largest offenders on each product page was the related products section. This was surprisingly exhaustive, both in time and resources.

Decision made, we’d load that after the page had fully loaded. We’d lazy load it. It was a good start. Feeling pleased, it was time to take a look at the theme. The previous theme had a lot of overheads. A good theme, built to make it easier for people to build beautiful e-commerce sites without the need to write much code. Unfortunately, it also brought a lot of bloat with it and with each instance, the theme had to be loaded, the page speed and general performance would suffer.

We needed a theme that was built for Woocommerce, that would be able to consistently receive security and performance updates without causing too many headaches. We also needed to be able to customise it easily, without the need for any additional plugins. The obvious choice was Storefront. 

Storefront offered us assurance that it would be well maintained and kept up to date with each new release of Woocommerce. Solving an issue the previous site had suffered greatly from. To make sure we were going to see some great improvements in performance we removed all inline styles we could. Anything that wasn’t set by the themes CSS stylesheet. Each time an inline style is loaded it decreases the overall performance, impacting the page speed. 

With that out the way, we needed to tackle the data. Import the datasets from A and B and create a set of products. We settled on a popular plugin to achieve this, one we felt could be reliable and scalable and wouldn’t impact too much on the performance of the site. We went with WP All Import. I won’t lie and tell you that when we loaded our CSV’s from Suppliers A and B they fired off and loaded a perfect set of product data, ready to go. There was a lot of manual effort, tweaking each import template carefully to make sure th

at the data was accurate for each of the tens of thousands of rows in our product CSV’s. The data was important as it would be viewed by Google when deciding where to rank the site. A few late nights and more cups of coffee than are likely to be recommended by any medical professional and it was done. All products were in the database, all images were accounted for and correct. It was beautiful.