Asset Timestamping defeats browser cache?

Rails
1

I was just wondering, doesn’t the Asset Timestamping plugin totally
defeat
the caching of your assets (js and css files) by the browser? Wouldn’t
this
increase the page load time on each hit?

Rails plugins page: http://wiki.rubyonrails.org/rails/pages/Plugins
Original post about this plugin:
http://article.gmane.org/gmane.comp.lang.ruby.rails/26607

–

2

On Nov 10, 2005, at 1:37 PM, Ramin wrote:

I was just wondering, doesn’t the Asset Timestamping plugin totally
defeat the caching of your assets (js and css files) by the
browser? Wouldn’t this increase the page load time on each hit?

Rails plugins page: http://wiki.rubyonrails.org/rails/pages/Plugins
Original post about this plugin: http://article.gmane.org/
gmane.comp.lang.ruby.rails/26607

In my experience, the browser caches it, query string and all. Then,
if the query string changes, it can’t find the new resource in the
cache and so reloads it.

You can see this in action if you watch your apache access log (or
equivalent) while browsing your site. Note that reloading a page
(typically) causes all resources to be reloaded, so don’t do any of
those. Just click links and be mellow, and you should notice that the
javascripts/images/stylesheets are only loaded once, in spite of the
query string.

  • Jamis
3

I was just wondering, doesn’t the Asset Timestamping plugin totally
defeat the caching of your assets (js and css files) by the browser?
Wouldn’t this increase the page load time on each hit?

The asset_timestamping plug-in adds timestamps to your assets’ URLS as a
way of
managing the client-side (browser) cache. If those timestamps were the
current time, the effect would be what you’re worried about–browsers
would
think they never had the assets being asked for, so they would never be
able to
satisfy any requests from their cache, and page load times would
increase.

But that’s not what asset_timestamping does; the timestamp it adds to
each
asset URL is derived from the time each of your files was last
modified. That
means that as long as you don’t change the asset files, the timestamps
will stay
the same and client browsers will be happy to cache the files, just as
they
normally do. The only time this situation is changed is when you change
an asset
file–which causes it’s timestamp to change, which makes your browser
think it
needs a different file, which isn’t in its cache, and so it requests it.

It’s exactly the behavior you want–you get the benefit of caching,
except when
you change an asset file, in which case browsers load the changed asset
so the
changes take effect immediately, instead of waiting for all the browser
caches
to be clear out.

I’ve found it to be really useful during the development phase when
I’m
constantly monkeying with CSS files–I don’t need to call everyone up
all the
time and say “hey, I fixed that thing, but you need to type control-F5
on your
browser to see the fix. . .”.

–Forrest

4

I understand now. Sounds awesome. Great plugin. Definitely gonna use it.
Thanks!