10 Things That Cripple Your Magento Store (That You Might Not Even Realize You're Doing)


simple_helix_guest_blog_1.pngWhy site speed is key to users

The first thing your potential customers see of your site will normally be the blank browser window that displays as your site begins to load after they clicked on a search result link to your website. That’s the moment the countdown begins: from that moment on, your website is being judged, albeit subconsciously, by the customer. Hopefully within a few seconds your customer is presented by the slick, clean interface of your Magento storefront.

Making sure your site loads fast and stays fast is serious business and as you can expect, there are a lot of ways for flies to get into the ointment and wrenches to get into the cogs, so to speak. Sadly, most of these flies and cogs are more often than not self-inflicted and many web site developers don’t realize the negative consequences for many well-intentioned design decisions that are common in the Magento ecosphere.

Here at Simple Helix, we don’t just specialize in building fast Magento hosting servers; we spend a lot of time helping people tweak and tune their existing stores to make them run at their best all the time. We’ve encountered several things that seem to recur over and over which stymie Magento’s performance. Most of these could be entirely avoidable with a little education and proper planning.

How To Completely Wreck Your Magento Performance, Without Even Trying Too Hard

Costly Database Queries

All database queries are extremely costly, in fact they’re the single most computationally expensive thing you can do on a web site. A mere 5% increase in the number of database queries is enough to dramatically skew your performance metrics for the worse. The most egregious abuse of database queries normally happens on the entry of a store page; the more products you load on your entry, the longer it will take to build the page and render for each customer, and double that time if you have to process price rules.

Cut down the number of products displayed on your entry pages and funnel customers into other parts of your site where you can showcase your products in a much more refined manner.

Doing Things in the Back-End of Your Store While You’re Having a Sale

You should do all preparation before a sale, not during the middle of your highest traffic periods. Don’t index your site, add products, run reports, or do anything that requires server resources during a sale. Your site needs all of its resources to serve customers at its best.

Failing to Optimize Your Images

Aside from excessive database query overhead, the second easiest way to negatively impact your site’s performance is by having several megabytes of images that haven’t been sized to proper dimensions and/or compressed correctly. All of those gigantic images have to be downloaded and rendered in the browser, so if you’re using a 3MB 2048x2048 pixel image that is ultimately going to be rendered in a 256x256 pixel box, all of that excess image real-estate is simply wasting bandwidth. 

Take the small bit of extra effort required to properly resize and recompress your images to get your total load time down. Many consumers are cursed with low-quality internet connections, so taking your site weight down from 25 megabytes of images down to 5 megabytes makes a huge difference.

Not Leveraging Compression

We’re talking about compressing the traffic between the web server and browser here. Just about everything in Magento is text and can be compressed on the wire, therefore compression can and should be leveraged whenever possible to reduce the amount of data that have to be transferred to the visitor’s machine. It’s a free performance win.

Not Using the Built-In Magento Compiler 

There are nearly 6000 files scattered across nearly 3200 directories in Magento. The compiler takes that rather broad outlay of files and puts them all into a common directory to the tune of a 25-50% performance improvement in most cases. Sure there are reasons where you wouldn’t want to run the compiler (in cases of broken add-ons) but why turn performance off to cater to a broken extension? Speaking of which...

Crimes Against Humanity Magento

Using Bad or Untested Extensions 

Does the extension you’re using require you to turn half of the features in Magento off just to get it to run correctly? Did you even test it in a non-production environment before you deployed it on your production site? This is one of the easiest and quickest ways to completely break your site. Plugins are nice but they’re not a panacea. You should always approach plugins and the promises made by their developers with a wheelbarrow full of salt.

Editing Magento Core Files 

The core files that make up Magento are not meant to be directly edited. For quite a while now, Magento has had a defined and well documented way to allow developers to customize their stores without having to modify any core PHP files, yet people still edit the core files, which eventually comes back to haunt them whenever they’re ready to update Magento to the latest version. 

Ignoring Security

Not Applying Security Patches or Updating to New Versions in a Timely Manner 

This is key. If you’re afraid to apply patches or update your Magento store to a newer version of Magento out of fear it will break your site, you’re doing it all wrong. Magento has been developed with customization and end-user modification in mind for years, and if you’re not following their best practices, you’ll have to sooner or later. Hopefully sooner because Magento 2 has already been released and is starting to show great promise in the performance and customization front.

Not Using Any Kind of Front-End Protection like a Web Application Firewall or CDN

A CDN is actually one of the biggest bang-for-your-buck upgrades you can for your site. One great benefit from using a CDN is that it protects you from DDoS (Distributed Denial of Service) and other nasty botnet attacks that can kill your store’s performance. Not only that, it allows your site to potentially serve up 50-75% more traffic than a normally aspirated store would.

Hosting Considerations

Using Shared Hosting When You Really Need Dedicated 

A common mistake a lot of people make is using shared hosting for sites with steady load and higher-than-normal numbers of database calls. A good rule of thumb is: if someone else dominated the CPU on the server, would your site still load in a reasonable manner? If your site is large and popular enough to consider a separate database server, then you should be looking at a dedicated front-end web server as well. Sure its more expensive, but your hosting bill is a cost of doing business just like any other: if you scrimp on it your customers will be able to tell.  Hosting is certainly one of those places where “a penny wise and a pound foolish” applies.

These steps are just a start at getting your Magento store performing well. If you want to get the most out of your Magento storefront, contact Briteskies and Simple Helix to let us help you. Our experts will optimize your site performance by employing advanced tuning techniques and innovative hosting solutions. We look forward to working with you. 

Download 10 Tips to Improve Site Speed

A Great Offer, Just a Click Away

Lorem ipsum dolor sit amet, consectetur adipiscing elit

Subscribe by Email

Comments (1)