Next step is to look into the quality of the code that’s obviously the current bottleneck. But I’m a bit loth to spen that much time on it if I’m looking to shorten the 1.5s TTFB time, when 3rd party stuff is taking 3.8s!
Has anyone got a plan on how I can reduce this? pagespeed + cloudfront has reduced the delivery of my own static content from 32 to 14 files and over 2s down to 0.8s elapsed.
( http://www.webpagetest.org/result/130608_32_40R = before )
Your biggest problem by far is time to first byte. It’s either the database being really slow or your hosting being slow. I see you’re using the Magento CMS on what looks like Amazon Web Services. I’m not a huge fan of AWS but you’ve probably got less options if you’re in NZ. Might be worth having a talk with someone at Rackspace http://www.rackspace.com/ecommerce-hosting/magento/ since you’ll get a lot more help out of their managed cloud service than you do from AWS on the server/db setup side of things. As far as loading the .js at different times there are a number of ways to do that but I don’t think that’s really as big of an issue.
[hr]
Additionally on your third party tags you’ll notice a significant amount of time is spent doing a DNS lookup. You can speed that up by doing DNS prefetching. You can google about it or I wrote a post about it a while back on my blog. DNS Prefetching
Thanks Chris. Rackspace is - in my very recent experience - not reliable enough to put a website upon, and also exceedingly expensive. Yes, you’re right, there are few cost-effective alternatives down here, in fact I was running my own physical servers to both be able to afford, and run powerful enough servers before Amazon came along - with all of the grief and loss of sleep that that entails.
And, once being well enough fed, the barrier to high performance for a Magento site is plain old raw power: the DB load is almost trivial once the caches are filled, as you would expect from what is primarily a read-only process. So much so, that I usually share the web and db servers on the same hardware. However, that may need to change if it becomes easier to use pagespeed rather than train devs to actually write clean html!
But I know all of that, and the query was about speeding up the loading of third party resources. I’m having problems seeing whether DNS prefetching would work on a single page download as in this benchmark test? And surely, once the names have been resolved, they’ll be available locally in the browser if proper expiry times, etc are set. And it is this that is, I think, as the core of the problem, because a lot of them don’t.
If I, who’s spent a lot of time and effort in tuning my resources, could act as an intermediary in some way, and deliver the static proportion of these 3rd party resources, then I could speed the site up appreciably, at extremely small cost. I’m looking for ideas along that line, and devious alternatives
How is Rackspace not reliable enough? Where their servers/data connections going down or was it the setup? I’ve been there on the sys admin side, managing your own servers for high traffic sites is tough. How do you have your server setup now? You’re using NginX as your web server? Memcache? Varnish? Apache?
The benefits of prefetching is great (potentially a second or more) for some and the downsides are very little (extra couple bytes of HTML code). Sometimes you have to look beyond benchmark testing and look at real world usage.
Cloudfront is a dog, AWS calls it a CDN but it really isn’t. You might want to look at MaxCDN, NetDNA, or Rackspace Cloudfiles (which use Akamai).
In addition to a better CDN you should also take a look at Cloudflare.com, I run almost every site I operate through it. Some of it’s biggest users are companies like Stumbleupon.com
I really wish you’d stop trying to hijack this thread Chris. I have used my SysAdmin experience to design and implement my servers, using the most cost effective solutions I can find in the local arena.
You have a different set of experiences, resources and probably requirements. Stop trying to stuff them down my throat!
My experience (and I’m no spring chicken mind you) tells me that Cloudfront is adequate and free, I will never use RackSpace again, and if prefetch is so good, why aren’t these third parties not providing Magento extensions with it ready coded in?
I will be testing prefetch to see what difference it makes, but am sceptical. I’d rather see decent expires values on remote images, for example.
Serious suggestion - not trying to hijack the thread or derail your original question - if you’re looking at a CDN with a POP in New Zealand, you should talk to Fastly. Also if you PM me I might be able to suggest a local hosting alternative.
I think the only 3rd-party I’d worry about is the hubspot code. It looks like that one is blocking the visual experience (not sure what it is doing but maybe it is responsible for part of the UI?). It looks like the hubspot code is injected in the head using a document.write (ugh). If you could move the code down to the bottom of the page it would shave ~1s off of the user experience. If you can use the script source directly instead of document.writing it then it would be even better and browsers will be able to discover the resource using their prefetch scanners.
If you have code that wires up anything in the UI based on the load event then it might be worthwhile to move all of the 3rd-party stuff out to after onload as well but from the visual experience side of things it looks like you are doing really well.
As far as the first byte time goes, AWS is perfectly good but it’s performance is going to heavily depend on the software stack (like any VPS or dedicated server). It sounds like you know what you are doing there - my only recommendation would be to try throwing New Relic on the server to see if it can give you any insight into some slow parts that maybe you weren’t aware of.
Thanks Patrick, I’m trying out the defer_javascript pagespeed page module, which both your site and google insights seem to think have made a difference.
I’m running munin, monitoring most things directly, so I’d say that New Relic would probably be a retrograde step in this instance Problem is lack of grunt to run the code - which is my ‘PC’ way of referring to code quality…
When using nginx nude, there’s almost no CPU hit on the server, and it’s sized for this. Pagespeed comes with a CPU hit, so it’s a bit of a balancing act until the code gets cleaned up a bit.
Have you tried New Relic (not the server monitoring, the APM side of things)? I’d think it would compliment munin pretty well. The more interesting bits are where it tells you how expensive various database calls, web services and API methods are so you can target fixes pretty quickly.
Here is the view of WebPagetest’s performance for workdone.php which is one of the more expensive operations (where the server does some post-processing on test results):
[attachment=287]
That said, if you’re in a position of trying to optimize as much as possible from the outside (code gets thrown at you to run and the quality of said code varies) then it sounds like you’ve got things well in hand, using PageSpeed to modify the code from the outside and get what gains you can.
