How is Amazon.in/com or Flipkart.com superfast?

Question

I have an eCommerce site and I am comparing the performance with the top players in the market.

I want to know what they do differently so I can do the same or set up an action plan to achieve that.

Amazon.com:

• Amazon website page weight is - 7.5mb
• Requests to server - 329
• Load time is - 3.11s
• Pingdom test result http://tools.pingdom.com/fpt/#!/dv5aUz/amazon.com

Flipkart.com

• Page weight is 1.7mb
• Requests to server - 168
• Load time is - 1.93s
• Pingdom test result http://tools.pingdom.com/fpt/#!/etA4uQ/flipkart.com

My website

• Page weight is 1.8mb
• Requests to server 80
• Load time is 6.45s
• Average wait time is 74.23%

This is what I use

• I use Magento 1.8.1
• I use EC2 m3.medium also tried c3.xLarge
• I use Cloudfront CDN
• I do not use compiler
• I do not use Varnish or any other full page caching modules

I tried to use compiler earlier and it did not give me any notable performace boost. So, I disabled it because, there were some regular issues when I try something new on site. I am not using any full page cache yet. But will use one shortly.

I use cloudfront - But the funny part is, when I request a single object directly from cloudfront, the wait time is still higher. I have read some posts on AWS forum that cloudfront getting slower and wait time is higher for some other people too.

What could be the issue here?

• Is this is the best performance I can get from using Magento
• Is this is the best I can get from AWS
• If I can achieve what amazon does, will it cost me a fortune every month? Right now, I spend about $150 for AWS hosting expense (Max)
• Or is there anything else that I can do to get my site load in 3-4 secs

Your advice will be very very helpful.

Answer 1

It's probably not fair to compare performance to massive ecommerce sites like amazon, but the techniques they use can never the less still be applied to your Magento store.

The first thing it's important to note is that these sites are not actually loading all of their content as quickly as it seems like they are, they are actually flushing a part of the page to the browser very quickly, but before the page is actually entirely built, then flushing more pieces of the page as they are generated by the server. You might have heard of this approach as BigPipe which is an approach 'invented' by FaceBook.

Normally what happens is that the entire full page HTML for a page is built by the server and delivered to the browser at which point the browser starts to render and display the page. It's only at this point that assets can load, so images, JS, CSS and so on as the URL's for these assets are of course contained in that HTML.

So the browser will only start rendering page contents once the server has sent it some HTML to actually display. In a complex system like a Magento store, building the HTML for the page takes the server quite some time to do as many thousands of lines of code must be executed and along with many requests made to the database. This will take the server differing amounts of time to do depending on hosting and the server spec but it's never going to be 'superfast'.

But what if we could just build part of the page quickly, and send this to the browser first so the page begins to render at that point, then send the rest of the parts of the page once they have been built? Well that's exactly what BigPipe does and what sites like Amazon and FaceBook use to have their pages start rendering very quickly in the browser.

Have a look at the 'waiting' and 'receiving' times for this request (screenshot from firebug, the stats are for the first request at the top, ignore the rest):

The 'waiting' time is the time it takes the server to generate HTML and send it to the browser so the browser can start rendering the page. In this case the 'waiting' time is very short, just 49ms. So the time the first byte of data is sent to the server (TTFB) is very quick. The 'receiving' time is the take it takes for the browser to receive all of the data for that request from the server. Oddly you will notice that it's very much longer than the waiting time at 1.29s. So even though the server first starts sending data after just 49ms, it takes a further 1.29s to send all of the HTML to the page. This kind of profile of a request is a tell tale sign of using a BigPipe approach which flushes a part of a page down the connection to the browser to achieve a good TTFB, then keeps the connection open until the rest of the page has been built and also flushed down the connection.

Compare that request to this one from the Magento demo site:

You can immediately see the total reverse of proportionate timings for 'waiting' and 'receiving'. Here the waiting time is much longer compared to a very short 'receiving' time. This indicates that the server is generating the entire pages worth of HTML before delivering it to the browser. We can therefore conclude that the TTFB is much slower as so the page will begin to render in the browser after a much longer period of time - 299ms vs just 49ms for Amazon. The receiving time is very short at just 2ms as at this point all the server has to do is deliver HTML as text to the browser as the page has been completely built. Interestingly you may notice that it takes around 1.3s to build the entire pages HTML on Amazon, but only around 300ms on the Magento demo - so Magento is actually quicker, it's because of BigPipe that it appears the reverse.

So 'superfast' performing websites may in fact not be performing as fast as you think, with the performance in fact just being 'perceived' - though the end result as far as the user browsing the site is concerned is still a 'fast website'.

You can of course also go down the full page caching route with Magento although I'm not sure than any solutions except ours use BigPipe. Full page caching is a good solution to achieve good TTFB, and there are plenty of both paid and free extensions out there, feel free to check out ours, Evolved Caching, which we really feel is a great option.

In simple terms full page caching will store the entire pages worth of HTML for a request and then serve that cached HTML the next time a request for that page comes in. Most solutions pull the full page HTML, populate it with dynamic content (i.e. mini cart, header links etc) and then deliver the complete HTML to the browser. This gives a decent TTFB, but Evolved Caching instead pulls the cached full page HTML, delivers it to the browser immediately and then populates the page with dynamic content either via BigPipe or AJAX. This gives an excellent TTFB as you are delivering full page HTML to the browser totally outside the Magento framework (which is slow to initalise).

So both BigPipe and full page caching are both approaches you may want to look at (although BigPipe without using Evolved Caching would likely need to be a custom build).

Anyway, all of the above deals just with the first request to the server which generates the HTML for the page, after that all further requests are after assets on the page like images, JS and CSS or for external services. Each of these requests take a finite time to complete so the more requests the page makes, the longer it takes for the page to finish loading entirely. you should try to minimise the number of assets on your pages as much as is realistic, and a CDN will help by spreading requests across multiple domains (meaning the browser can request more assets at once as the request limit if per domain).

Having said all this, over and above everything you need to make sure the hosting you have your site running on is sufficiently highly specced to run your Magento store well. What spec this needs to be exactly and what you need to spend on it is very specific to each particular store and the traffic that store sees, but essentially the larger the load the webserver has to deal with the higher the spec the hosting needs to be.

When the store is of sufficient size you can also look at other options like a master/slave database setup, database sharding, splitting admin to another server and so on - Magento is pretty scalable. Remember that the hosting is the foundation for the entire store - if it's not right then no amount of BigPipe, caching or any other implementation will give you a store which performs well.

Hopefully some points for consideration. Let me know if you want any more details on anything (although someone else would be more qualified than me to answer hosting related queries).