Site Speed: It's Official. Can the Magento Zealotry End?

10 comments

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 — 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 — 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 — 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 — in the pie-in-the-sky hopes that 10% add to cart and buy — 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 — 100x or even 1000x. It will still perhaps be 500x slower. It’s like driving a Corvette on gravel roads — 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 — that’s everyone as we recall — might be the wiser to pay homage to his internal search box. Toolking.com, for example — 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) — 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 — 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 — 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 — 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.

About the Author

Jaimie Sirovich is a search marketing consultant. Officially he is a computer programmer, but he claims to enjoy marketing much more. At present, Jaimie is focused on helping clients sell everywhere, and achieve multi-channel integration with major websites such as eBay, Amazon, and even Craigslist. He is the author of Search Engine Optimization With PHP. Jaimie can also be reached directly at jaimie@seoegghead.com.

Add Your Comments

  • (will not be published)

10 Comments

  1. I wrote a similar blog post just a few weeks ago about the effects of slow Magento sites and SEO. We have developed a Performance Magento Module called LightSpeed that can reduce page load times, so you don't have to increase server resources, but a good server is recommended for best performance. We have seen site go from page load times of 6 seconds down to as fast as 120 milliseconds. http.store.delorumcommerce.com

  2. "Magento Zealotry", seriously? :D There are people who need Magento's functionality and there are those who don't. If you are a really small business and don't plan on expanding any time soon, you most likely will not use Magento to it's full potential, so you could totally go with some lightweight platform that's much faster by default. On topic: Well, if you want to have a system with Magento's functionality, the drowback has to be there. It's simply a big system that does a lot of things, it's complex, so it's not very fast. Do you think one could build something with Magento's functionality without slowing down the website? The main reason why Magento is slow on some stores is surprisingly not a hardware issue. It's the fact that their stores make too many server requests per second, so distant server means long load time. For example, I have a demo store on a shared hosting, but it's located pretty near to me. The store is lightning fast without even using the methods of speed improving mentioned in some of the articles you linked ;) .-= Toni Anicic´s last blog ..Magento Developers Paradise featuring Inchoo =-.

  3. I'll admit I have been schooled by the grand master of effective titles, Quadszilla (seoblackhat.com). The title worked, and it's not misleading. It's not so much about power, it's about their attitude in design. Design first, optimize later is a reasonable attitude; but it only goes so far. We're guilty of that as well. But I'd never think to release a product with 5 second response times on reasonable hardware. That's nuts. It means there's something very inefficient going on. It's not just tweaking that's needed in that case. Sometimes caching will work. Other times it won't. That's best to figure out before you release a design. "if you want to have a system with Magento’s functionality, the drowback has to be there" Sorry, that's a misconception. As anyone who took a data structures and algorithms class, usually the problem is related to that big-O. Sometimes you can normalize and then build denormalized data to query against for speed, but -- as I said before, should be validated beforehand, and any release should run at an acceptable speed. It has nothing to do with # of requests, and everything to do with Magento's insistence on a EAV schema. We do have functionality like Magento. We do have tables that are EAV. We do build denormalized tables for speed. As a result, every page loads in under a second, and this is without exotic CDNs, 12 GB of memory, etc.

  4. @Matt Those are some nice modules. The one that caught my eye most is the Endeca IAP module. Endeca is the Cadillac of navigation/merchandising/facets, but I'm not sure how much of Magento's front end is left once you tie in the IAP. Of course if Magento were pure awesomeness as the "zealots" claim, Endeca would be a lot less necessary. I'm not Magento-bashing. I tried to like it. They have lots of great features, but let's face it. It's slow on many web sites we visit. Layered navigation on a 50k+ product web site seems questionable. Add fulltext to the mix, and it's even more fun. I noticed that Toolking.com is now SAAS for search. I do wonder why, and maybe your IAP integration plugin would have been better :) How much does your caching module speed up layered nav? You can't possibly cache a number of permutations and counts with a factorial in it, can you? Caching works for a finite number of queries that aren't volatile. Facets fail for the first criterion. You'd know better than I would ... :)

  5. Yes, LightSpeed does speed up layered nav. It will actually cache every unique url as users request them or as you automate a request for them. You can see a working example of LightSpeed doing this with layered nav at Zumiez.com.

  6. Interesting. But -- Zumiez also looks like it uses Endeca. I see the Endeca-looking giant-integers. So Zumiez is ultimately not using layered navigation at all. It's using Endeca. Correct me if I'm wrong. We only cache the base case. If you have 20k products in a category, even caching the counts can get interestingly slow regardless -- esp. with not-so-selective criteria. And there's a (sparse) power function in there somewhere, right? It's nicer is the counts are actually quick :) It's possible to get it down pretty low if you build an index exactly the way you want it. I admit, you're making Magento usable, but cache only works where it works. Both Toolking and Zumiez are not using layered navigation to varying degrees. http://www.zumiez.com/girls/t-shirts.html?brand=billabong-girls&d=4294967075 looks like Endeca to me.

  7. Sean

    Pretty good estimation, Jaime "If its flash and it's slow, it must be Magento" If Tool King is the epitome of Magento websites, I'm looking at 5-9 second page loads and 15 second loads for the first time I load new categories. Matt needs to go sell them his "LightSpeed" module.

  8. Sean

    @Toni "Too many server requests per second" Care to expound, is this too many customers on the website or a misconfiguration issue?

  9. @Sean He means too many overall requests — including static content. That's bollocks, clearly. He's just grasping at straws. Speed = dynamic-content-speed + static-content-speed. It's a function of both, in other words. Of course we can speed up a slow web site with awfully slow dynamic content by speeding up the static content. I heard rumors about Magento giving up on the EAV schema. That would be a good call. They're talented developers, but that's the fundamental design mistake that's plaguing their performance. If you don't want to use an RDBMS and worry about schema changes, use MongoDB and forget about columns.

  10. mbabazi justus

    i would like to how to conclude an official letter thanks