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 -- - Ramin http://www.getintothis.com/blog _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
I don''t think so - It would defeat the browser''s cache if the timestamp was the time when the page is loaded. This would change with every refresh. However, I believe the timestamp is the last-modified time of the asset, so the browser will try to reload the asset only when its last- modified time changes. This way, the browser''s cache is still effective. Brad On Nov 10, 2005, at 1:31 PM, rails-request-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org wrote:> Message: 5 > Date: Thu, 10 Nov 2005 15:37:17 -0500 > From: Ramin <i8ramin-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> > Subject: [Rails] Asset Timestamping defeats browser cache? > To: rails <rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org> > Message-ID: > <6f7563250511101237u46346c9dv1f69982e5867097b-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> > Content-Type: text/plain; charset="iso-8859-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 > > > -- > - Ramin > http://www.getintothis.com/blog > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/ > 20051110/f6a0ba7e/attachment.html_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
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/26607In 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
> 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
I understand now. Sounds awesome. Great plugin. Definitely gonna use it. Thanks! On 11/10/05, Forrest Thiessen <thiessen-I0D8NflN0vzU+KD/reu1CkEOCMrvLtNR@public.gmane.org> 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? > > 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 > > > > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- - Ramin http://www.getintothis.com/blog _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails