Quick wins to improve Magento TTFB

Fast Magento

Save time shaving time

There are a series of basic adjustments you can make to your store to improve performance, often without reducing functionality. Whilst some may not be appropriate all-year-round, there are definitely changes worth making during peak season - even if there is a little sacrifice in appearance/functionality.

There's obviously no replacement for code profiling, but getting quick wins certainly doesn't hurt.

TTFB Basics

These are covered over and over, but can often be overlooked. So before you begin, make sure you've got the very basics in place,

Top navigation

Top navigation

System > Configuration > Catalogue > Category Top Navigation

So easily overlooked is the maximal depth setting in the admin area. When left on the default of 0, your front-end will load the entire category structure on every page. Set a limit (lower is better), and preview the change on the frontend.

Product grid/list

Product grid

System > Configuration > Catalogue > Frontend > Products per Page: 16

The more products you display, the slower the page will load; so if you display 16 products, it will take twice as long to render as 8 products. Try and strike a balance between performance and pagination. I'd recommend no more than 16 products on a page (24 as a maximum).

System > Configuration > Catalogue > Frontend > Allow All Products per Page: No

This setting should be disabled. The performance impact can be catastrophic.

Layered navigation

Catalogue > Manage Categories > [Category] > Display Settings > Is Anchor: No

Layered navigation is one of the heaviest components on a Magento store,

  • The more products you have in a category (and its subcategories), the more you'll add to page load time
  • The more filterable options you have, the more you'll add to page load time (and often confuse the customer)

Turn off layered navigation on top level categories where the filterable options are too vast to add value.

System > Configuration > Catalogue > Catalog Search > Apply Layered Navigation... : 200-500

You can control when layered navigation is shown on search results, so that if you've got a large result set, the server doesn't spent time calculating all the possible filters for the entire result set.

The default value is 2000, this should be reduced to a more suitable level, between 200 and 500.

Catalogue > Attributes > Manage Attributes > [Attribute] > Use In Layered Navigation: No

Often stores display tens of filterable attributes, the majority of which are never selected by customers. Focus on a few that are important, as the more attribute filters you present to a customer, the more page permutations you create.

If you take a store with just 5 categories, nested 2 levels deep, 5 filterable attributes, 5 attribute options each and 1000 products; that is a lot of possible combinations.

Potentially, with each attribute you allow to be filterable, you could be adding thousands more pages on the frontend for search engines to crawl - increasing server load and taking vital resources away from your customers.

Get rid of that price slider

Price Slider

Price sliders can be especially problematic when trying to maintain high hit rates on caches. Allowing customers to make such minute page variations can create millions of possible page permutations, often resulting in the store cache never being hit.

There's two solutions,

  • Remove the price slider, and restore the standard boundary pricing
  • Keep the slider, but change the increment, so only ~4 options can be selected

I cannot stress enough how damaging these are for performance.

Get rid of that layered navigation module

Googlebot Crawl

Sadly, the performance impact of custom layered navigation modules can be so devastating that they can increase page load time by tens of seconds (remember, Magento normally loads in 0.5s); but worse still is that often they aim to improve SEO by creating normalised URLs (rather than parameterised URLs), creating millions or billions of possible crawlable URLs.

I've performed hundreds of profiling reports for customers, and this is always the top issue for performance, SEO and scalability. Total module removal is advised, if you need the ability to have multi-select layered navigation - then a replacement I can fully recommend is BubbleShop Layer Pro

I've got no affiliation with BubbleShop - but its a module we recommend time and time again if you need multi-select layered navigation, because it is high performance and well built.

If you want some real-world statistics of the impact, consider just how much of a difference it made to CPU usage. After these changes, page load time proportionately dropped by 600%.

CPU Usage layered nav

Magento load time decrease

Delete unused store views, categories and products

It might seem obvious, but these all consume valuable resources - especially store views. So many stores still operate with the default English, French and German store views - and as a result have the overhead of a store 3x as large as it should be.

Store views act as a multiplier on the catalogue, they can add huge overhead without giving that impression. So if you've got unused store views, remove them.

Equally, products, categories, attributes, attribute options and attribute sets whether disabled or not are still consuming resources. If you don't need them and no longer need them - delete them, don't disable them.

This change won't actually improve performance for customers, so there's no noticeable saving, but what it will do is improve administration performance and reindexing performance.

Disable the Magento profiler

System > Configuration > Advanced > Developer > Debug > Profiler: No

This should be off by default - and certainly never enabled on a production store. But sometimes it is left enabled, adding up to 2 seconds to page load time.

Equally, remove any 3rd party profiler modules from your production store (eg. Aoe_Profiler)

Remote crawl tools, automated tools

Tools like MajesticSEO and SEMRush can provide valuable insight for your marketing and SEO teams - but are also quite damaging, by sapping resources from customers trying to purchase from you. Equally, any other automated tool that you have interacting with your website can use valuable resources.

Reduce the impact by either disabling them (even just temporarily during sales/promotion days), rate limiting them or adding a crawl delay.

This change won't actually improve performance for customers, so there's no noticeable saving, but what it will do is improve administration performance and reindexing performance.

  • fooman

    Would you mind explaining where the disable logging advice comes from
    and how much difference it makes. I have been wondering about this ever
    since hearing in on Vitaly
    from the ECQ team
    who suggested that when you hook it up to syslog it's better to have
    the logs than to go without. A few minutes earlier he also advocated for
    having profiler enabled (IP restricted) on production.

    • Hey Kristof,

      >Where the disable logging advice comes from and how much difference it makes

      Sometimes no difference at all - sometimes a measurable difference.I'll give you some background; on MageStack, each customer stack has its own dedicated resources (physically); a NFS master for a site with 40,000 unique visitors/day typically sees ~5MB/s disk writes through normal activity. Considering we use Intel Enterprise DC S3720 SSDs - capable of ~400MB/s+ (sustained 24/7), clearly its barely scratching the surface - so logging is barely adding to that.

      A good store shouldn't be logging with any frequency. The system log shouldn't be flooded with notice errors and the exception log should always be empty. But unfortunately that's rarely the case. So many modules log, and hugely verbosely, that logging occurs on almost every page required.

      So I have seen performance improve (on busy stores, or during peak situations) when logging is disabled. As to the specifics of this, I would love to dig deeper, but have never been able to justify doing it. I would guess that the log action holds an exclusive lock on a file (causing other requests wanting to log, to queue) until that write operation is complete; otherwise, your log files would be a jumbled mess.

      There are obvious downsides, it makes fault diagnosis more difficult and can easily cause you to skip over things going wrong with your store. So as a rule, it should be on, but during peak situations - I find its an acceptable loss.

      But the other thing to add is that if you don't actually read the logs, and fix the errors within the logs - then they are going to waste anyway!

      We've got a method in MageStack to feed custom logs into Kibana - see https://www.sonassi.com/help/magestack/centralised-logging-with-custom-logs - and a number of our customers have written their own logging modules to feed it via UDP (none-blocking), rather than file write. I've been pushing them to open source it for the benefit of others, watch this space.

      >He also advocated forhaving profiler enabled

      Like logging, again, this is only useful if you are both doing continuous, real-time performance analysis and making use of the tool. The average merchant isn't doing this, even some developers don't know how to profile!

      The use in this case is limited, and the risk is that the overhead of profiling (which there is, even if only when viewed by a restricted IP) is that it is still there; and saving resources during peak is the goal here.

      Its part of the reason why I don't like using APM's like New Relic in production at peak, because it adds an overhead that isn't going to provide an actionable benefit.

  • David Jones

    Great post! However the following:

    System > Configuration > Catalogue > Search Engine Optimisations > Apply Layered Navigation...

    Should be:

    System > Configuration > Catalog > Catalog Search > Apply Layered Navigation...

    (Also it's only visible/applicable if using MySql Fulltext Search).

    • Pants. I'll get that corrected!

  • royandre

    Great post! We have seen the same numbers - and also use the layered module from Bubbleshop on all our sites.