Alfa Jango Blog Engineering, Software, and Entrepreneurship

In this article, we’re going to speed up our Rails application by up to 75%, simply by optimizing our Rails asset host. We’re going to serve our components (stylesheets, javascripts, images, etc.) from a combination of our app’s server and Amazon CloudFront (Option A, recommended), or entirely from CloudFront (Option B – easier).

The best option for you may depend on your specific needs, but I’ll cover both processes below. For a an in-depth analysis of why Option A is recommended over Option B, see the last article in this series, How to Combine GZip + CDN for Fastest Page Loads.

(more…)

In my last post, I discussed the three techniques used to improve asset load speed. In this post, I will discuss how to combine the use of GZipping and a Content Delivery Network (CDN) for the fastest possible page loads.

Pitfall of Amazon S3 + CloudFront

Everyone’s favorite CDN these days is Amazon’s CloudFront service, which serves files directly from Amazon’s scalable “simple storage system”, Amazon S3. It is very easy to work with, has widespread support in Ruby gems and plugins (and countless other libraries), and is very inexpensive with it’s pay-as-you-go billing.

However, there is one large pitfall to using Amazon S3 + CloudFront, and that is that neither S3 nor CloudFront support GZip detecting and encoding. It would seem that we need to now decide whether we’ll do without GZipping or using a CDN. Not so! There is another way.

(more…)

In my last post, I discussed why it’s becoming increasingly important to ensure your website loads quickly for users (and Googlebots). At the end of the article, I mentioned a quote from Yahoo!’s article, Best Practices for Speeding Up Your Web Site:

80-90% of the end-user response time is spent downloading all the components in the page: images, stylesheets, scripts, Flash, etc. This is the Performance Golden Rule.

In other words, you can get the most “bang for your buck” when it comes to page load optimization by speeding up the loading of your site components (a.k.a. “assets”, such as javascripts, CSS stylesheets, images, etc.). In this post, I’ll discuss the 3 main techniques used to improve asset load speed.

Asset load optimization often results in a reduction in asset-load-time by 75-90%. Since asset-load-time accounts for 80-90% of your total page-load-time, this equates to an overall reduction in page-load-time by up to 80%!

Below are graphs showing the load time of RateMyStudentRental.com before and after (respectively) implementing the asset-optimization shown here. Using Google’s Speed Tracer extension, we can see that total load time decreased from 40 milliseconds down to 15ms.

(more…)

Page load speed is becoming increasingly important as rich web applications become more interactive. It’s not just about usability anymore; it can now directly affect your placement in search engine results, now that Google uses page load speed in their ranking algorithm. Are you ready for a reality check? Get Google Webmaster Tools for your site, and go to the Labs >> Site Performance to view your average page load time, as seen by Google’s web crawlers. That’s right, Google is already tracking your site’s performance history.

Google Webmaster Tools is even kind enough to tell you how you stack up against the rest of the web. Here is what Webmaster Tools had to say about one of our sites before optimizing it for quick page loading:

On average, pages in your site take 4.5 seconds to load (updated on Feb 21, 2010). This is slower than 70% of sites. These estimates are of low accuracy (fewer than 100 data points). The chart below shows how your site’s average page load time has changed over the last few months. For your reference, it also shows the 20th percentile value across all sites, separating slow and fast load times.

Ouch. Did I mention this would be a painful reality check?

Now to be fair, there’s a very reasonable explanation for this. Google claims that the majority of users will click “back” to the search results page if a link takes too long to load. So, if a webpage is too slow for the visitor to read it, the relevance of the content is…well, irrelevant. I should point out, however, that it’s unknown precisely how much page load speed affects your placement in search results.

(more…)

I recently wrote a lightweight jQuery plugin called EasyTabs, and it is now released on the official jQuery plugin website. Most front-end developers are familiar with the jQuery-UI tab plugin. However, it is a very magical plugin with a complex structure, which completely styles your tabs for you, and limits your options when deciding how to structure the tabbed content.

For instance, it is very difficult to place your tabs below the tabbed content with jQuery-UI tabs.. You must perform some crazy CSS trickery, because jQuery-UI tabs forces you to place your <ul> before your content <div>s. Not to mention all of the jQuery-UI styling it does to your tabs by default, making it difficult to override and apply custom stylization to your tabs.

This new plugin, jQuery EasyTabs, is very flexible for the required markup and structure of your tabs and content. Also, it handles only the functionality of creating in-page tabs, leaving all of the styling up to you and your own CSS.

To check it out, see our documentation and demos. Then when you’re ready, you can download it from the jQuery plugins website.

It has become common practice to use JQuery as the javascript library of choice for Ruby on Rails applications. If you have a Rails app already using Prototype, it usually isn’t feasible to replace it in one swoop. And sometimes, you just simply need both to work at the same time. Whether you want to use both in unison (not recommended as a long-term strategy), or you want to gradually migrate from Prototype to JQuery, it’s not as scary as you may think.

The secret is that it is difficult to get Prototype to play nicely with JQuery, while it is rather trivial to get JQuery to play nicely with Prototype. This may seem like a minor distinction, but it is one that will save you a lot of headaches.

Use Prototype/Scriptaculous with JQuery

First, in our application layout, we’re going to get rid of <%=javascript_include_tag :defaults %> and include each javascript file explicitly just to make things a little less magicky and a little more straight forward.

(more…)

Last week, we added functionality to one of our web apps to show just the main content of any web-page, without all the other stuff. You may think of this as creating a printable view of any web-page, with all images, videos, ads, etc. removed. Here is an example of an original webpage vs. the printable view we create:

Feel free to skip straight to our “Meat” Algorithm, as we’ve so endearingly named it, if you’re not interested in the specifics of implementing it.

The Tools: Ruby and Nokogiri

Thanks to Ruby and a Ruby gem, called Nokogiri, it’s far easier to create this printable view than you may think. If you haven’t heard of it before, Nokogiri is a gem that reads and parses HTML, XML, and SAX, and allows you to easily search and manipulate these documents based on CSS selectors and XPATH.

(more…)

Phusion Passenger (aka mod_rails) allows for easy and scalable deployment of Ruby on Rails applications on Apache or Nginx servers. Part of what makes it so easy is that it comes with suitable default settings right out of the box, so that you don’t need to concern yourself with any of the details when deploying your application to production.

However, once you’ve launched your application and people start actually using it, you may find server experiencing excessive swapping once the traffic begins to pick up. Before getting too deep into scaling, caching, upgrading your server, etc., there are a few Passenger settings you can tune to wring out the best performance your existing stack. I’ll address these settings with a few rules of thumb we’ve gathered from the Passenger documentation and simple trial-and-error.

Before getting started, we highly recommend employing Munin (instructions for Munin with Passenger here) and NewRelic Performance Monitoring for your Passenger/Rails application, so that you can fine-tune your settings for the best performance.

Note: the following settings are specific for Apache, you will need to modify the syntax/file-names for Nginx.

Per-server Settings

These settings are set per-server, meaning if you have multiple applications running on the server, these should be set only once throughout all of your .conf files. If you have only one Rails/Passenger app on the server, then you may set these in that application’s .conf file. On Ubuntu, this may be found at /etc/apache2/sites-available/yourapp.conf.

(more…)