Improving Performance on your Miva Merchant Site
One of the most common complaints we hear from customers is that their site is slow. Either customers are complaining, the client is having trouble using it in-house, or they’ve heard that speeding it up can help with SEO. All of these are great reasons to consider working on making your site faster. In case you need more motivation, consider the fact that Google is about to start using your mobile site speed as a ranking factor, too. It’s definitely time to take a look at performance…even if you already have before.
The Two Pieces: Front-end versus Back-end
Unless you’re a developer, the terms "front-end" and "back-end" may not make a lot of difference to you. And different software architectures may have different meanings for these terms. (Software architecture is the way software pieces are put together, just like putting together pieces of a building.)
With MIVA, the terms mean this:
Back-end: MIVA Merchant itself, any modules you’ve installed, and the SMT code in your page templates. It also includes your database.
Performance optimization should include both sets of code.
Getting a Baseline
There are several tools you can use to get a baseline – basically, to measure the speed of your site – before you start to make changes. These tools will also identify areas where improvement is needed. Some of the tools we particularly like for this task are:
- WebPagetest – does a similar analysis as the above, adding in CDN usage, displaying a waterfall image (that shows elements as they are downloaded, against a timeline)
- GTmetrix – includes results from PageSpeed Insights but also adds YSlow, a waterfall, and even a video of the page elements loading.
There are also nice tools in Chrome, particularly Google Lighthouse.
Many of these tools give the same information, but slight differences make them all useful in different ways. The optimization suggestions they provide are particularly useful, though their recommendations are all front-end ones (other than the generic "improve time to first byte" which can be translated as "make your back-end faster").
Having baseline measurements – page load times and sizes – of key pages such as your homepage, important landing pages, and sample category and product pages will help you determine the results of the efforts you make going forward. You’ll retest after making changes and compare the numbers to see the effects on your site’s speed.
The area where we commonly see the biggest need for improvement is image filesize. Many times designers make images that look nice, but they don’t think about download time, compression, and image optimization. The result is bloated images that take way too long to transfer across the web, especially for users on a cellular connection.
The downside of this approach is that it’s fairly manual. You have to do one page at a time, and often you’re uploading optimized images one at a time. For a bulk approach, try Kraken.io. Using this tool, you can upload images in bulk or even have a developer write a script to process images from your server. This is great if you have hundreds or thousands of product photos that need to be optimized. And it’s the approach we use here at NetBlazon.
Your site should automatically use GZIP compression. This is usually an easy fix on MIVA sites if it’s not already enabled. To test, go to https://checkgzipcompression.com/ and put in your domain. If the results indicate that GZIP compression is not enabled, email MIVA support and ask them to turn it on. Nothing else should be needed.
Settings Expires Headers
A note about that last sentence: When files change often, your visitors’ cached copies may get outdated too fast. If you change something that’s not cached, but it depends on a new version of a file that is cached, you’re bound to have problems. So save this for once your site is pretty stable and not changing often. When you do make critical changes, you may want to change your filenames. Say you’re making CSS changes on a file called mystyles.css that has a one-week expires header. The change is pretty important. So change the file to mystyles1.css and change your website to point to the newly-named file. That will "bust the cache" for visitors, forcing their browsers to download the updated file.
Let’s move inside of MIVA and see what can be done to speed things up before anything is even transferred to the visitors’ sites. MIVA recently added several features that you should be sure you’re taking advantage of.
Automatically Delete Expired Baskets
When a person or a bot shops your site, a basket is created. The more baskets that exist at any one time, the slower it is to make changes in the database. So you want to make sure that your site isn’t keeping expired baskets around longer than necessary.
An expired basket is one that can no longer be used, because it hasn’t been accessed within the window of time set as the "basket timeout" in your store. For instance, if your basket timeout is one day, as soon as the basket has gone longer than a day without any activity, it expires. Expired baskets do nothing both take up time.
In MIVA 9.6, they added something called Scheduled Tasks. These are tasks that run automatically in the background. There are two scheduled tasks that are super-important to MIVA’s performance, and Delete Expired Baskets is one of them. Make sure that ask is on and set to run fairly frequently. Remember, it only deletes expired baskets, not those still in use (or still able to be used), so it’s ok to have it run fairly frequently, say, once an hour.
Cache Product Lists
In Miva 9.7, they added the ability to cache the entries in product lists – namely the list of products in a given category, and for a specific search. They claim a 3X increase in performance from this task alone. Follow the link above to find out how to set this up, and to make sure the scheduled task for deleting expired cache entries is on. (Yep, that’s the second super-important task!)
Thanks to one of Miva’s in-house developers, Tess Guefen, you can also cache sections of your site code that are built dynamically but don’t change often. You do this using a module called Transients. The module takes the output of a template and caches it so that it can be reused until it expires…without having to be rebuilt from the database.
We love this module particularly for sites that build their navigation dynamically, either directly from the store’s categories, or via ReadyTheme navigation sets. You can even use it in the Levels ReadyTheme – see this forum thread for more information.
Optimizing SMT within Templates
You can also optimize the SMT (store morph technology) code within your page templates by getting rid of things that are unneeded, or offlining certain processes.
One example we had for a client involved choosing the image for a subcategory by finding the first product within the subcategory that had an image. If the category in question didn’t have products, but only had additional subcategories, then the code looped through the sub-subcategories of each subcategory to find an image. Confusing, right? Definitely time-consuming on the server! And it did this on every page load. So what we did was make a custom category field to hold the subcategory image (or maybe we used the title or tree fields, I forget). When this looping process ran and it found an image, we saved it to the field. Subsequent loads could just look at the field instead of looping through all the subcats and sub-subcats. But if the customer added a new section to the site, the original code would still work. It ran the same, BUT ONLY THE FIRST TIME.
That’s all a bit hard to describe. The important part is knowing how to find this code, though….finding out where the bottlenecks are to begin with. For this task, we use the Miva-provided tool mvprof. mvprof allows you to see what elements of a page are using the most cycles when loading a given page. A description of how to do use mvprof is beyond the scope of this article, but I’ll point you to this forum post and this video by Jon Burchmore that describes the tool.
Retesting …and Retesting…Your Site
Once you finish – and possibly even as you go along – you’ll want to retest your site with the tools mentioned at the beginning of this post. Hopefully you saved the numbers from your baseline tests, so that you can get accurate values for the improvements you’ve made.
And as your site is likely a living, growing entity, you’ll want to continue regular testing. This helps ensure that new features and new assets (especially images) aren’t undoing all your previous hard work. The benefits of a faster site are ongoing, as long as you keep the site itself clean and fast!