We’re putting together the presentation materials for our five-city “Rails Performance in the Cloud” Roadshow at the end of the month (Boston, Austin, Seattle, LA and Chicago). We’ll be presenting some findings on page load performance for a casual survey sample of 100 North American Rails web-sites. Since some of the findings are not what you’d expect, we thought we’d share some of these early findings with you (come to the Roadshow and be the first to hear the rest of the analysis!).
1. It’s easy to forget to compress your JavaScript and CSS
It seems like people are pretty good about gzipping their HTML and images, but for whatever reason, a lot of people forget to tell mod_deflate to compress JavaScript and CSS files. JavaScript payloads are becoming a much bigger percentage of total downloads (even a majority of the payload for many sites), and they’re blocking the rest of the page from loading.
2. Watch out for slow third party services
Some of the big outliers in page load performance are caused by poor response times from third party services. Services like Google Ads and Analytics, Doubleclick, and Facebook Connect can kill your performance if you loading them early, so almost all sites (sensibly) put them as late as possible in the page load. Response times of up to eight seconds from Google Analytics are not uncommon, so this can result in a big road-bump in your page load if it’s in the wrong place. Google Analytics, in particular, uses document.write, so most people have to work around it, but a significant minority of sites don’t.
3. Using multiple image hosts doesn’t always mean higher performance
There’s nothing magical about using multiple image hosts. It should produce higher performance by allowing parallel downloads, but only if you’ve put the necessary resources to work. An interesting performance outlier in the survey was a site that had configured multiple image hosts, but response times from those hosts were multi-second — probably a good sign that they were under-resourced.
4. S3 is NOT a Webserver!
Amazon S3 is a reliable, cheap storage service, but don’t treat it like just another web-server. Response time in the wild was regularly between 0.5 and 1.5 seconds, so make sure that you’re not serving performance sensitive content from it. And if you do, try to use pre-loading to hide latency. Unlike a regular web-server, S3 (still) does not gzip content, so you also need to use a pre-compression utility like Yahoo’s Smush.It to reduce image sizes before you put them up there.
5. Most performance variability is NOT attributable to page factors
When we did the analysis, we found that less than half of total page-load time in our sample was attributable to front-end factors like the number of http requests made by the page, the size of the page payload and whether or not you were scaling images in HTML. A majority of performance variability (a little surprisingly) was attributable to stuff that had nothing to do with page construction (basically network and back-end factors).
To learn more about what we found about average page response time, page size targets and http chatter, as well as what the analysis said about front-end performance, sign up for the Rails Roadshow, coming to a city near you in two weeks time. We’ll be presenting along with our partners New Relic, Soasta, Amazon, CVSDude and more.
See you there!
Loading ...
Watch a Live Demo of Engine Yard AppCloud
The Engine Yard Newsletter
Following on from point 5, none of the other four items were related to Rails specifically, so they apply to all Web apps.
A note on 1 – with our AJAX heavy app, we just increased our responsiveness on some actions massively by adding text/javascript into our nginx config under gzip_types. The x-application/javascript gzip_type just didn't cut it.
So as well as compressing the source javascript files, compressing javascript also compresses your AJAX responses (inserts, updates and the like) – which can result in a massive speed boost if you have moderate to large async responses.
Awesome post :D
We've been experimenting with Amazon CloudFront for client applications in which assets such as photos are getting consistent hits in medium and high volume scenarios. Latency is much lower than serving directly off of S3. Plays nicely with Paperclip. Check out http://www.webficient.com/2009/10/21/using-amazon...