Google Webmaster Tools now reports 1.4 second load time across all pages for Windshield Guru. This includes many of our database intensive pages accessed via the backend – where we still include Google Analytics tags to track employee site usage. The chart can be seen below.
It’s difficult to draw correlations to organic traffic due to the penguin update that is plaguing the seo industry, however organic search has climbed 5.5% over the last thirty days compared to the previous thirty. Additionally our bounce rate has dropped slightly, time on site has jumped by 3% and pages per visit is up as well.
We recently moved Windshield Guru to Amazon Web Services to help us scale up to meet the demands of both visitors and our customer service department. While we’ve seen gains in page load time from the switch, we really weren’t squeezing every ounce of performance we could from Amazon’s scalable infrastructure. Our server architecture consisted of a large mysql DB instance an apache instance serving the front end and an instance we used for development of new functionality. Our worst metric across a ton of webpagetest.org tests was time to first byte. As apache had to read a file, interpret php, then query the database, the logical first step to increase performance was to serve our content up via a reverse caching proxy. There are a few ways to setup a reverse proxy for caching but the two most obvious are nginx and varnish. We’ve played with both pieces of software and settled on Varnish.
Varnish works by loading up your static content into memory – effectively eliminating any disk i/o constraints (which are common on AWS – especially on EBS backed instances). As no disk seek is necessary – the only function varnish does is checks to see if the content requested is in the cache (in RAM) and serve it to the end user. Working from memory is much faster than reading from a disk.
[Jack notes...] Be aware that there are often assets you don’t want cached on your site. On Windshield Guru, visitors are presented with a map of nearby shops, looked up from their IP address. Obviously, this doesn’t help when they show a cached map of Washington state and you’re in Phoenix. What we chose to do is isolate these assets as iframes, and then serve them up from a seperate subdirectory with a less liberal caching policy, so every user gets them fresh. Other alternatives include drawing the info in client side with AJAX calls from a script not tied to the main caching rules.
Time to first byte dropped from 0.665 seconds to 0.029 seconds – a 2200% reduction. Overall page load time dropped from 2.547 seconds load time on first visit to 1.393 seconds – a 46% decrease!
2.547s Load Time via Apache
1.393s Load Time via Varnish