The DevTeam Alpha News Aggregation service has sourced the following article originally published on SiteGround:
Whether you’re adding functionality to your website through a plugin, a theme, or carrying out bespoke development, it’s important to review any changes you make and the impact they have on your site performance.
For any website, but especially for ecommerce, performance is extremely important. Your website speed has an impact on how you rank on search engines and on your customers’ experience when shopping with you. Slow websites result in fewer page views, reduction in customer satisfaction, and fewer conversions.
Setting up a website that’s optimized for speed is not a one-time deal. As your site grows, any changes you make can impact the work you’ve already done. If you’ve made a change that seems to be affecting your performance, you should immediately address it to get your site back on track.
Creating the foundation
Before getting into all the considerations when making adjustments to your existing website, it’s very important to start with a solid foundation. For the purposes of this article, we’ll assume you are using WordPress, but much of the process still applies when working with other platforms.
From the outset, ensure you are hosting your website on a high-performance provider such as SiteGround. You should enable some form of caching (with SiteGround you can enable SuperCacher) which will keep things fast. For caching, although there are some amazing techniques that will make everything faster for the vast majority of people landing on your website, you still have to keep in mind visitors receiving an uncached piece of content. Caching is not a solution to all performance issues, especially since not all content can be cached.
It’s important to start with an optimized foundation for key areas of your website such as the home, product, cart and checkout pages. Ideally, you should also have a staging environment in order to carry out future tests in a safe way.
Setting a baseline
First of all, you’ll want to get a baseline of your current performance to know what you are working with.
To do this, I recommend using a selection of different tools, some of which serve the same function but ensure your results are more representative of your visitors. These tools are all free.
- GTMetrix, provides an in depth analysis of your page speed scores, fully-loaded times, page size and even total request generated on the page along with resolutions.
- Pingdom, this serves the same purpose as GTMetrix but using multiple versions of a similar tool increases the accuracy of your results.
- Google PageSpeed Insights, provides information on how your page loads along with additional audits and how to resolve issues if they are present.
- Query Monitor, a WordPress plugin that gives insights into what your website is doing behind the scenes, how much memory it’s using, how many database queries it’s making, how many outside requests it makes and much more.
- Chrome Developer tools, these are tools built into the Chrome browser that allow you to review, monitor and debug certain performance-heavy areas and even test things such as page speed yourself. If you’ve never used these tools, right-click on a website in Chrome and select inspect.
Start by using the first three tools above to run through your homepage and a product page. These first steps are easier to work with right in the browser without technical knowledge.
Once you’ve gone through these and made a note of the applicable load time, page size, etc., it’s time to move on to testing the cart, checkout and add to cart in your browser. To do so, head over to one of your product pages and open the developer tools (you can do so as above, use F12 or option + command + I)
Clear the log of any entries using the stop icon on the left hand side, enable preserve log and disable cache. Once you’ve done so, add an item to your cart and make a note of the information along the bottom bar, repeat the same steps for the cart and checkout ensuring you have at least one item in your cart when you do so.
You can even use the menu highlighted in the image above to limit the speed of your tests. This is helpful when it comes to mobile users who are likely to be on slower connections such as 3G (always remember to switch this back to online if you change it though).
Building for the future
Now that you have a baseline to work with you can use this in the future whenever you make significant changes to your website. You can also use this to create certain targets for how fast the website should be.
If your baseline numbers seem slow, I would highly recommend going through Andrea Zoellner’s article which provides a brilliant starting point to boost performance all round.
Moving forward, you can use your staging website to test out new plugins, themes, or custom code, ensuring they provide what you are looking for. Make sure they aren’t causing any performance regressions by running through the tests again. You might be surprised at what can have an impact on your website speed. When companies like Amazon note that for every added 100ms in loading time, it cost them 1% in sales, it’s important to keep on top of these things.
A real world example of naive bespoke development
Now that we’ve gone through some of the basics, I’ll provide a real world example of a very small piece of code that had a significant impact on the speed of adding to cart, viewing the cart and using the checkout. This is a little more technical, but provides a good insight into how a seemingly minor piece of code can have a big impact.
In this example, I addressed the general performance of the site but quickly noticed that there was still a major issue with the cart and checkout. It was taking anywhere between 5 and 20 seconds to load these two pages, which is way beyond an acceptable level (you want to aim for 1 to 3 seconds at most if you can). In return, this was causing a major decline in purchases. If a customer can browse your site, add items to the cart but then they get to the cart or checkout and it takes a long time to load, they are likely to give up after 5 seconds and your conversion rates drop significantly.
At this point, I decided to install the Query Monitor plugin on the site to see if anything obvious would jump out. After installing the plugin and activating it, I then went to the cart to see what diagnostic information it would give me. The first thing that jumped out was that the page was using a large amount of memory —60mb in fact! This may not sound like much, but it adds up quickly when you have a large amount of visitors on your site. This high memory usage lead me to believe that perhaps the page was loading a large amount of data from the database. I switched the query monitor tab to queries and scrolled through the list to eventually come across a particular query that had a very high row count and was taking a long time to process. This confirmed my initial suspicions for the reason of the high memory usage.
Then, we disabled every plugin except WooCommerce, repeated our test and still had an issue. We changed the theme, repeated our test and the issue was gone. Now we knew it was theme-related.
Knowing this, we re-enabled the plugins, carried out a further test and found that everything was running smoothly and at a much more acceptable: 2 second load time on the cart. We then re-enabled the bespoke theme and starting digging into it, starting with the functions.php file.
During this time, I also had a discussion with the client to establish if they’d had anything in particular added recently because this issue was relatively new. They noted some functionality was developed for them. The new functionality was that a particular coupon would be automatically added to the cart if a customer was logged in and they had not made a previous purchase.
As you can imagine, there was a little back and forth here but it wasn’t long before I found what seemed to be the offending code. I commented it out and ran another test: 2 seconds load time again. Bingo! We found the issue. But now, how do we solve it?
The code before and after
Upon initial inspection, this particular piece of code looks fairly innocent. First, it loads all completed orders for the current customer based on their user id, counts them and then returns true or false depending on how many orders it counted.
However let’s highlight some problems:
- It loads all orders, notice the -1 for numberposts
- It loads all orders even if the customer isn’t logged in (one of the requirements was only for logged in users)
The biggest issue with loading all orders, especially for a guest, is that for every new order made by a guest, this function will start getting exponentially slower as it has to query the database for all records. Because it’s using the get_posts function, WordPress will then parse all of those to a WP_Post object.
So issue one was addressed by altering numberposts to only 1 because we only need to load one completed order to know they’ve made a previous order. We also don’t need to run this if they are a guest, so we can add a further check at the start to return early if they aren’t logged in. This in turn means the query won’t run. We can also change this to use WP_Query instead of get_posts. It’s generally more correct to use WP_Query and it provides additional functionality. Lastly we can actually reduce the fields that the query returns because we don’t need them all to know there is an entry either.
Following this fix, the cart and checkout loaded with in an acceptable 1 to 2 seconds for both guests and logged in customers. The best part is not only did the website go back to its usual sales, it further surpassed expectations by doubling them! This goes to show that taking care of performance can have a significant impact on your bottom line and is well worth the investment. You can do it yourself or have a third party carry out an audit and work with you on optimizing your site.
Be wary of copy and pasting code
Just for fun, I decided to see if I could find this problematic piece of code in the wild, to see if it had been taken from somewhere. I happened to find it on Stack Overflow which by all accounts means it was just copy and pasted with no thought given to how it might affect the site.
I even took a look at some of the additional answers in that particular thread and although they are generally of higher quality, they all still suffer from the same issue of loading more data than necessary. This isn’t to say ours couldn’t be improved, we could in fact write a raw database query, but this would give a very minor improvement and become considerably less workable. There is a fine line between optimising code while keeping it understandable.
Scaling well to maintain speed
Changing your site carefully is an important part of maintaining a successful online business. The tips above like creating a solid and powerful foundation with a good host that has caching, using a staging site to test any of your changes, and evaluating any changes with speed tests can help you avoid major mistakes. Never implement any questionable code without testing it first and when in doubt, reach out to someone for a second opinion. With time, you’ll be able to scale your site and your revenue without worry.
This was the 10th installment of our Black Friday series. Eager for more tips on optimizing your ecommerce performance? Stay tuned for more posts just like this one featuring industry experts and some of our technical partners. Learn how to improve your website design, conversions, online marketing, and more.
Learn more about SiteGround by visiting their website.