Understanding Page Speed and Server Response Times with Magento

We all know that Magento is a resource intensive and sometimes slow application; the same thing that gives Magento its flexibility and power can at times slow it down too. If you ever had a website with a large amount of stores or lot of active shopping cart rules, you have experienced first hand how Magento’s performance can suffer at different points and by different reasons.

Recently at Demac Media I took upon the challenge to improve our current server stack in order to reduce the resource usage, speed up the sites, and increase the general performance. But rather than focusing on what changes where made to the stack, like PHP-FPM vs mod_php or memcached vs redis; I want to discuss a part of the optimization process that I consider the most important and which seems to be often overlooked by developers (myself included): I’m talking about the application raw speed and the customer perception of speed.

Magento Raw Speed

First of all, let me clarify what a I mean by raw speed. When talking about raw speed, I’m talking about Magento server response time without any caching, flat tables or any other sort of optimization (compilation, opode caching, etc).

Although no Magento site will run (or at least it shouldn’t) without cache, it’s important that we know how fast or slow the site is. This allows us to easily notice bad code by adding seconds to a page load, that otherwise would be ‘hidden’ by the cache.

As developers, we can’t solely rely on the cache to speed up or site or guarantee a good experience for the customer, cache expires and gets invalidated; so you need to know the “cost” of the new code that you are adding. Only when we know the “cost” of our code, then we can start thinking about optimization, performance improvements and caching.

The Different Flavours of Speed

When talking about websites or web apps speed there are two different types of speed metrics that should be considered, one is the Server Response Time and the other one is the Page Load Time; and sometimes it can get confusing, personally my CTO and I had an Abbott and Costello moment a while back:

CTO: Hey, we are getting reports website x being extremely slow

Myself: That’s strange let me take a look. No, that’s wrong. The site is responding in under a second, two without cache

CTO: No, I’m telling the sites it’s slow.

As you probably realized by now, my CTO was talking about Page Load Time while I was refering to the Server Response Time. You might be asking what’s the big difference, so let’s clarify:

Server Response Time: Is the time that takes the server and the app to execute all the code and queries for a specific request before sending back a request back to the browser. Any bad code added will affect this metric directly, if you load a collection twice or try to run a big join query, your server response time will suffer. Most developers are already aware of this and pay try to make their code lean and optimized.

Page Load Time: This one is trickier to clearly define. The page load time is basically the time that takes the browser to fully load and render all the elements in a page. CSS, JS, images and loading external resources are going to have a significant impact on the page load time.

As developers we are primarly trained to think in code, resources, server stacks and so on. We rarely think about the customer experience. After all, that’s the designer guy job, right?

If you agree with the previous statement, I have sad news for you. It’s 2013. We should be equally responsible, if not more, for the customer experience; and so far, it seems that both designers and developers tend to ignore the impact of their code (even html) on how the customer perceives the speed of a site.

Perception of Speed

When talking about the ‘perception of speed’, we are referring to how fast a particular site loads for a particular customer. Page Load Times are critical here. This is going to depend greatly on the customer browser version, connection speed, and even geolocation.

Now it is impossible to cater to every single scenario, connection speed, and even browser version (DIE! IE6 DIE!) but there are steps that can be taken to mitigate possible slowness of a site and provide a better user experience. Here are some to name a few:

– CSS minification and compression
– Javascript minification and compression
– Image size optimization (yeah, having 60 1mb images in your category pages is not a great idea)
– Lazy loading images
– HTML code optimization
– Reducing the number of requests (This means less js,css and images files to load)

Now we could go into detail about how to implement each and every technique, or I could tell you about an amazing tool that can do all this and more for you and it only takes a few minutes to install; I’m of course talking about Google PageSpeed.

PageSpeed speeds up your site and reduces page load time. This open-source webserver module automatically applies web performance best practices to pages and associated assets (CSS, JavaScript, images) without requiring that you modify your existing content or workflow.

So far I have seen really good results on some of our sites, one really cool thing you can do even before considering setting mod_pagespeed is to use the Pagespeed Insights page to analyze your current site and measure the potential gains.

If you would like me to cover mod_pagespeed or the other technologies that we are testing in our new stack (apc,memcached,php-fpm,redis,etc), please drop a comment below and I will do a follow up post!