ActionView::Helpers::AssetTagHelper

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 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 http://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 http://assets1.example.com and http://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" media="screen" rel="stylesheet" type="text/css" />

The proc takes a single source parameter which is the path of the source asset. This can be used to generate a particular asset host depending on the asset path.

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

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