module 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:

image_tag("rails.png")
# => <img alt="Rails src="/images/rails.png?1230601161" />
stylesheet_link_tag("application")
# => <link href="/stylesheets/application.css?1232285206" media="screen" rel="stylesheet" type="text/css" />

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 asset server by setting ActionController::Base.asset_host in the application configuration, typically in config/environments/production.rb. For example, you’d define assets.example.com to be your asset host this way:

ActionController::Base.asset_host = "assets.example.com"

Helpers take that into account:

image_tag("rails.png")
# => <img alt="Rails" src="http://assets.example.com/images/rails.png?1230601161" />
stylesheet_link_tag("application")
# => <link href="http://assets.example.com/stylesheets/application.css?1232285206" media="screen" rel="stylesheet" type="text/css" />

Browsers typically open at most two simultaneous connections to a single host, which means your assets often have to wait for other assets to finish downloading. You can alleviate this by using a %d wildcard in the asset_host. For example, “assets%d.example.com”. If that wildcard is present Rails distributes asset requests among the corresponding four hosts “assets0.example.com”, …, “assets3.example.com”. With this trick browsers will open eight simultaneous connections rather than two.

image_tag("rails.png")
# => <img alt="Rails" src="http://assets0.example.com/images/rails.png?1230601161" />
stylesheet_link_tag("application")
# => <link href="http://assets2.example.com/stylesheets/application.css?1232285206" 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 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 like this:

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

The example above generates “assets1.example.com” and “assets2.example.com” randomly. This option is useful for example if you need fewer/more than four hosts, custom host names, etc.

As you see the proc takes a source parameter. That’s a string with the absolute path of the asset with any extensions and timestamps in place, for example “/images/rails.png?1230601161”.

 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 alt="Rails" src="http://images.example.com/images/rails.png?1230601161" />
stylesheet_link_tag("application")
# => <link href="http://assets.example.com/stylesheets/application.css?1232285206" media="screen" rel="stylesheet" type="text/css" />

Alternatively you may ask for a second parameter request. That one is particularly useful 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. If you don’t have SSL certificates for each of the asset hosts this technique allows you to avoid warnings in the client about mixed media.

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

You can also implement a custom asset host object that responds to call and takes either one or two parameters just like the proc.

config.action_controller.asset_host = AssetHostingWithMinimumSsl.new(
  "http://asset%d.example.com", "https://asset1.example.com"
)

Using asset timestamps

By default, Rails appends asset’s timestamps to all asset paths. 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 drifts out of sync, you’ll see different timestamps at random and the cache won’t work. In that case 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.