It’s official now, and the shock waves are still rippling through the SEO-interweb. Site speed is a ranking factor. I have long contended that website architecture is a factor in search marketing (see Professional Search Engine Optimization with PHP), and this is just another example a�� technology and marketing are forever intertwined in a Frankenstein marriage between a talented marketer and computer programmer.
For a long time milliseconds and marketing were words rarely uttered in the same sentence. Not so anymore.
Absolutely a�� site speed should be a ranking factor. When a web page takes more than a second to load, it degrades user experience. Google is in the business of providing you a great user experience in exchange for your eyes on advertisements. While it may not be the most important factor, it truly makes sense to mix it in. We all know what we do when we’re made to wait, even with a polite “please wait” admonition. We leave.
So it’s not the “Google Gestapo” out to crush small business. In fact, a small business with under a thousand products and some simple business rules should pose no problems for a web application. On the contrary, smaller businesses should have an edge a�� there are fewer data to comb through on every page load. Quality commodity hosting costing about $25/mo. should be more than adequate.
The problem comes when one uses a big heavy framework that includes everything and the kitchen sink because someone told you it was great. These frameworks are often slow.
Don’t take my word for it, search for “Magento Slow,” and you will find a wealth of information. http://inchoo.net/online-marketing/site-speed-magento-community-do-not-panic/
Others propose totally reasonable solutions to small to medium-sized businesses such as:
1. Use a dedicated server with 4 CPUs
2. Use a 2nd dedicated server like the above just for the database
3. Use a faster non-free web server, such as LiteSpeed
4. Use a CDN to speed up static content, making up for sub-par dynamic content performance
5. Combining and eliminating images decrease latency
Wow. That’s a long list of stuff to do. And were you to invest those same dollars in another platform, you might then have the fastest website on the planet.
The truth is that a read-biased application, such as one that mostly showcases products a�� in the pie-in-the-sky hopes that 10% add to cart and buy a�� has few excuses to be very slow. Properly written software like this should almost never require any of the above, except perhaps #1, unless it’s a multi-million dollar operation.
OK. I get it. But can I throw hardware at it? Maybe.
Throwing hardware at the problem doesn’t always work because computers double in speed, while a series of poorly written queries or functions can trump that by orders of magnitude in slowness a�� 100x or even 1000x. It will still perhaps be 500x slower. It’s like driving a Corvette on gravel roads a�� it will only get you so far.
Magento, and frameworks like it suffer from complexity. They are frequently slow because they are extremely abstracted and attempt to anticipate everything rather than a reasonable set of common problems. Much like a (properly-functioning) bureaucracy, it might do everything eventually. However, it does everything through many many layers, and the abstraction has a cost. Here’s what’s really at play:
1. At a certain point, software abstraction fosters virtual bureaucracies rather than expedient solutions:
In my opinion, Magento crosses this line. Several sites using Magento at revered (and expensive) dedicated server hosting firms such as RackSpace still provide unimpressive load times. Maybe they need to implement 1 and 2 and 3 and 4 and 5 from above. They didn’t do all of this? They must be very lazy, then.
Magento’s search and layered navigation functionality are sometimes even more hazardously slow. And anyone who uses Google a�� that’s everyone as we recall a�� might be the wiser to pay homage to his internal search box. Toolking.com, for example a�� the poster child of Magento Enterprise (http://www.internetretailer.com/2010/01/06/tool-king-rebuilds-its-e-commerce-site-on-an-open-source-platfor) a�� has totally abandoned Magento Enterprise as a search platform for an SAAS search service. Search is relegated to a subdomain (http://search.toolking.com/), which not-so-surprisingly screams in comparison. Kudos to Baynote.
2. Anyone who has worked within a bureaucracy knows how difficult it is to change things:
Magento’s plug-in architecture is so complex, that many very experienced programmers struggle and wrestle with it. They may even quit over “code politics.” In many of these platforms, the patterns are extremely rigid. Patterns are good, but most intelligent people like some flexibility. And while more business rules may be implemented in such a way without changes to underlying architecture, the changes are made more difficult, and may introduce even more latency. Of course the plug in architecture may also change from version N to version N+1 as well, severely limiting any benefits from easy-to-apply upgrades once one invests in said plug-in-based customizations.
It all comes down to The Clinton Axiom: “The more he denies it, the more you know there is an element of truth.”
Magento zealots are in denial, and will fall on swords to dispel the notion that their beloved has some issues. Software abstraction is good a�� but only to a point. Especially for small to medium-sized business, sometimes a king or oligarchy functions better than a bureaucracy. A smaller operation moves faster, not delegating various tasks to a ridiculous number of layers. Caching is sometimes a fix a�� but only makes up for some performance problems, and then only if the answers to the queries do not change frequently. As a small to medium-sized retailer, I’d prefer to be an oligarchy.
It is important to recognize that both site speed issues and software complexity are hidden costs. As with any design, there is a sweet spot between design complexity/abstraction and functionality. Simpler designs can work, too. Custom web development based on reusable components or simpler frameworks are both viable options. CS-Cart, X-Cart, and Interspire all manage to be quick at what they do on commodity hosting, for example. Our applications based on reusable components run well on an inexpensive VPS.
So, for software, I prefer an oligarchy a�� and anything is better than a bureaucracy. Sorry, Magento. Google might not love you as much as those zealots do. Users don’t like to wait either.