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" rel="stylesheet" media="screen" 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" rel="stylesheet" media="screen" type="text/css" />

To do this, you can either setup 4 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 www.die.net/musings/page_load_time/ for background.

Alternatively, you can exert more control over the asset host by setting asset_host to a proc that takes a single source argument. This is useful if you are unable to setup 4 actual hosts or have fewer/more than 4 hosts. The example proc below generates assets1.example.com and assets2.example.com randomly.

ActionController::Base.asset_host = Proc.new { |source| "http://assets#{rand(2) + 1}.example.com" }
image_tag("rails.png")
  => <img src="http://assets2.example.com/images/rails.png" alt="Rails" />
stylesheet_include_tag("application")
  => <link href="http://assets1.example.com/stylesheets/application.css" rel="stylesheet" media="screen" type="text/css" />

The proc takes a source parameter (which is the path of the source asset) and an optional request parameter (which is an entire instance of an ActionController::AbstractRequest subclass). This can be used to generate a particular asset host depending on the asset path and the particular request.

 ActionController::Base.asset_host = Proc.new { |source|
   if source.starts_with?('/images')
     "http://images.example.com"
   else
     "http://assets.example.com"
   end
 }
image_tag("rails.png")
  => <img src="http://images.example.com/images/rails.png" alt="Rails" />
stylesheet_include_tag("application")
  => <link href="http://assets.example.com/stylesheets/application.css" rel="stylesheet" media="screen" type="text/css" />

The optional request parameter to the proc is useful in particular for serving assets from an SSL-protected page. The example proc below disables asset hosting for HTTPS connections, while still sending assets for plain HTTP requests from asset hosts. This is useful for avoiding mixed media warnings when serving non-HTTP assets from HTTPS web pages when you don’t have an SSL certificate for each of the asset hosts.

ActionController::Base.asset_host = Proc.new { |source, request|
  if request.ssl?
    "#{request.protocol}#{request.host_with_port}"
  else
    "#{request.protocol}assets.example.com"
  end
}

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"

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).