> But the tricky part is the caching only happens when a request is made > for the first time, so you've got to invoke another task which make a > wget request to a page
This method is problematic if you need to get your assets on a CDN. I think asset packer got it right: in your rails code you need to name just one javascript file per helper method call, and manage what gets included in that javascript file in a separate file and/or process. So don't use the :cache option provided by rails. You can have multiple different such javascript file collections. With that in place, this sort of describes how I'd deploy the assets : http://gist.github.com/95255 http://blog.anthonyeden.com/2009/04/14/capistrano-rails-and-amazon-cloudfront/ Add an additional task to yuicompress before uploading the new assets to get an additional 10% reduction in your javascript files. I'm thinking I might even do something like this if I didn't use a CDN. Several reasons: - You don't need a first request to the webserver to compress assets. - Rails by default sticks the cache key in the query string, but some (misconfigured) proxy servers ignore requests for static resources such as .css, .js and .html, so those proxies will keep your old assets in cache even when you deploy a new version. This setup puts the cache-busting asset id in the path of the URL instead of in the querystring which all proxies understand (does require some rewrite rules in your .htaccess or apache/nginx config file). - Adding 4 CNAME records pointing them to your single rails server makes clients open up 8 connections to download assets instead of max 2. This may improve perceived performance. Lawrence > Something as simple as caching all the js/css files into a single file > not only makes it lighter on the number of requests, but also makes a > single target for creating a cap task to minify/compress each of > these. There's a blog post on this somewhere around, but I can't find > it. > > So, we tackle it in two steps. > > 1. Cache (in production only) using Rails' cache function > > <%= stylesheet_link_tag 'reset', 'base', 'global', 'style', :cache => > "cache/base" %> > <%= javascript_include_tag 'prototype', 'everything', 'else', > 'application', :cache => "cache/base" %> > > 2. Use a cap task to YUICompress each > > task :shrink_assets, :roles => :web do > run "java -jar /usr/lib/java/yuicompressor.jar --type js # > {current_path}/public/javascripts/cache/base.js -o #{current_path}/ > public/javascripts/cache/base.js" > run "java -jar /usr/lib/java/yuicompressor.jar --type css # > {current_path}/public/stylesheets/cache/base.css -o #{current_path}/ > public/stylesheets/cache/base.css" > end > > But the tricky part is the caching only happens when a request is made > for the first time, so you've got to invoke another task which make a > wget request to a page, and then run the :shrink_assets task right > after. > > task :cache_assets, :roles => :web do > sleep(3) > run "/usr/bin/wget -o http://127.0.0.1 >/usr/tmp" > end > > I can see why you'd use Asset Manager to get around the :cache_assets > problem (annoying). Look forward to playing with Sprockets, has some > good concepts. > I'd be keen to hear what others are doing. > > Cheers, > > Nathan > > > > > On Jul 14, 11:56 am, Nathan de Vries <[email protected]> wrote: > >> On 14/07/2009, at 10:51 AM, Chris Lloyd wrote: >> >> >>> The only sort of minifier worth its weight is one that does some >>> sort of lexical analysis of the JS source tree. >>> >> Are you saying that the extra 10% compression gained from using a >> minifier like YUI Compressor is noticeably better than a reduction in >> HTTP requests using concatenation and standard HTTP compression >> (60-85%), to the point where you'd not use any other tool? That sounds >> a little crazy to me. >> >> Cheers, >> >> Nathan de Vries >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en -~----------~----~----~----~------~----~------~--~---
