Page speed is an important factor in search rankings and conversion rates. Every improvement to page speed will likely result in more sales.
We’ve addressed page speed at, most recently, “10 Ways to Increase Ecommerce Site Speed” and “Google Analytics: Using Site Speed Data to Improve Conversions.” However, we have not addressed how backend software can improve page speed. After all, the faster that servers create and send the page to your visitor, the faster the overall page speed is.
In this article, I’ll describe three tactics to improve backend performance and page speed.
More and Faster Servers
Adding more and faster servers to your store can dramatically improve page speed. Additional servers add capacity to handle more traffic and maintain quick performance.
A good analogy is a highway system. Each road can handle a certain level of traffic. With fewer vehicles, there is plenty of room and traffic moves quickly. But as the traffic increases, highway speeds slow down and you can end up with a traffic jam.
Web servers, too, can accommodate only so much traffic. Traffic spikes can overwhelm a server, as can denial-of-service attacks. Both can create traffic jams — and a crash or two.
The two typical choices for improving server performance are:
- Move to larger and faster servers, which will make processing web pages much faster;
- Add more servers to share the traffic.
Using the highway analogy, larger servers are like raising the speed limit: traffic can go faster. Adding servers is similar to building additional highway lanes: more traffic can be in transit at one time.
There are advantages and disadvantages to each approach. Development costs are typically lower for adding servers (renting or buying). But, eventually, adding more servers won’t likely improve performance — it sometimes even reduces performance. Moreover, your ecommerce platform may respond better to one method over the other. Your developer should know which one would likely work better for your company.
Regardless, for slow-loading websites, my first recommendation is nearly always to replace servers or add to them.
Data and SQL Optimizations
The second technique to speed up your backend system is to evaluate how your site loads its content, such as photos, text, and prices. This will likely be SQL queries to your database.
The more frequent your application requests data, the slower the page will be. The difference can be significant between a page using one SQL query and 10 queries. The same goes for queries that obtain one MB of data versus 100 MBs.
There are usually half-a-dozen queries in single ecommerce site that create slowdowns. Tools called profilers can analyze how a system is performing and discover the bottlenecks.
I recently optimized an ecommerce site to accommodate holiday traffic. The site would process and analyze customer orders in batch jobs every night. Each order would take 200 to 300 milliseconds to process (one-fifth to one-third of a second). That’s reasonably fast.
The problem was that this store had 300,000 orders — every night. Each nightly batch job would take 16-25 hours to complete. If the processing took a bit longer and fell behind, it could still be working on the previous night’s job when the current day’s batch would start. This caused both batches to fail.
After a few days of optimizations I was able to reduce the processing time to 30 milliseconds per order — about 2.5 hours for the entire customer base. The problem was that even though each of the queries ran quickly, the quantity of queries per order made the entire process slow. Luckily this didn’t affect the front-end page speed. But it could have in another setting.
The third technique to improve page speed is caching. Instead of generating the dynamic HTML for a page every time a visitor requests it, with caching the page gets generated once, saved, and then reused for subsequent visitors.
This means any slow SQL queries and code would only run once and then the cache would skip those for the next visitor.
Caching works on many levels, making it very flexible.
- Entire page can be cached.
- Parts of the page can be cached
- Objects like code, data, and calculations can be cached.
For ecommerce applications, it is usually difficult to cache an entire page. If shopping cart contents were cached, for example, a shopper could see what the previous customer placed in his cart. Not good.
Caching objects and parts of the page are usually helpful for ecommerce applications.
In my example above of optimizing nightly batches, to reduce the processing time for each batch I created a cache of the calculations for each order. That cached data was then used by the store in its nightly reports.
The primary difficulty with caching is to create the rules around when that cache should be refreshed. If your store holds onto the cache too long, you risk showing your visitors outdated information, such as displaying on a page that a product is in stock while in fact it went out of stock hours ago.
On the other hand, refreshing the cache too frequently can be counterproductive. Your servers would do extra work to refresh the cache, which could slow down the site.