Flowdock

This module provides methods for generating HTML that links views to assets such as images, javascripts, stylesheets, and feeds. These methods do not verify the assets exist before linking to them.

Using asset hosts

By default, Rails links to these assets on the current host in the public folder, but you can direct Rails to link to assets from a dedicated assets server by setting ActionController::Base.asset_host in your environment.rb. For example, let’s say your asset host is assets.example.com.

  ActionController::Base.asset_host = "assets.example.com"
  image_tag("rails.png")
    => <img src="http://assets.example.com/images/rails.png" alt="Rails" />
  stylesheet_include_tag("application")
    => <link href="http://assets.example.com/stylesheets/application.css" media="screen" rel="stylesheet" type="text/css" />

This is useful since browsers typically open at most two connections to a single host, which means your assets often wait in single file for their turn to load. You can alleviate this by using a %d wildcard in asset_host (for example, "assets%d.example.com") to automatically distribute asset requests among four hosts (e.g., assets0.example.com through assets3.example.com) so browsers will open eight connections rather than two.

  image_tag("rails.png")
    => <img src="http://assets0.example.com/images/rails.png" alt="Rails" />
  stylesheet_include_tag("application")
    => <link href="http://assets3.example.com/stylesheets/application.css" media="screen" rel="stylesheet" type="text/css" />

To do this, you can either setup four actual hosts, or you can use wildcard DNS to CNAME the wildcard to a single asset host. You can read more about setting up your DNS CNAME records from your ISP.

Note: This is purely a browser performance optimization and is not meant for server load balancing. See http://www.die.net/musings/page_load_time/ for background.

Using asset timestamps

By default, Rails will append all asset paths with that asset’s timestamp. This allows you to set a cache-expiration date for the asset far into the future, but still be able to instantly invalidate it by simply updating the file (and hence updating the timestamp, which then updates the URL as the timestamp is part of that, which in turn busts the cache).

It’s the responsibility of the web server you use to set the far-future expiration date on cache assets that you need to take advantage of this feature. Here’s an example for Apache:

# Asset Expiration ExpiresActive On <FilesMatch "\.(ico|gif|jpe?g|png|js|css)$">

  ExpiresDefault "access plus 1 year"

</FilesMatch>

Also note that in order for this to work, all your application servers must return the same timestamps. This means that they must have their clocks synchronized. If one of them drift out of sync, you’ll see different timestamps at random and the cache won’t work. Which means that the browser will request the same assets over and over again even thought they didn’t change. You can use something like Live HTTP Headers for Firefox to verify that the cache is indeed working (and that the assets are not being requested over and over).

Constants

ASSETS_DIR = defined?(RAILS_ROOT) ? "#{RAILS_ROOT}/public" : "public"

JAVASCRIPTS_DIR = "#{ASSETS_DIR}/javascripts"

STYLESHEETS_DIR = "#{ASSETS_DIR}/stylesheets"

JAVASCRIPT_DEFAULT_SOURCES = ['prototype', 'effects', 'dragdrop', 'controls'] unless const_defined?(:JAVASCRIPT_DEFAULT_SOURCES)

Attributes

Show files where this module is defined (1 file)
Register or log in to add new notes.
January 27, 2010
1 thank

Alternative hostname generation method

Instead of using a random number to generate the hostname for the single asset, I prefer using source.hash.modulo, so that a given file is always served from the same host. This makes the content more cacheable by browsers and proxies.

ActionController::Base.asset_host = Proc.new { |source|
  "http://assets#{ source.hash.modulo(9) }.example.com"
}

I didn’t benchmark how long it takes, but String#hash should be reasonably fast.

December 16, 2010 - (>= v2.0.0)
0 thanks

RE: Alternative hostname generation method

According to compute_asset_host as of rails 2.0.0 the %d expansion works in the same way, it’s not a random number generated on each call but the source hash mod 4.

In my brief testing in rails 2.3.9, %d doesn’t appear to work if you use a Proc, so manual generation is of use in that case.