The Rails guide here says
"Any assets under public will be served as static files by the
application or web server when config.serve_static_files is set to
true. You should use app/assets for files that must undergo some
pre-processing before they are served."
I'm using Rails 4.2.4. There is no public/assets folder. This leaves me wondering a few things:
What is meant by "use app/assets for files that must undergo some pre-processing before they are served?"
What is meant by pre-processing?
How is a static asset different from other assets, and what are the performance benefits of using one pipeline over the other?
Do I even need to worry about this if 4.2.4 has no public/assets folder?
Assets like javascript/css etc. need to be pre-processed - eg. minified, hashed for cache busting, passed through transpilers (like coffeescript) etc. Such assets should be kept in app/assets folder.
I believe 1 already answers that.
Passing each asset through transpilers/minifiers etc. as described in 1 during production will be very expensive and wasteful - because these assets don't change dynamically we can just do them once during pre-compilation and let static file server or cdn handle their delivery.
When you precompile your assets in deployment, the compiled files will be generated into the public/assets folder.
I recommend reading this article, which explains asset pipeline in much detail.
Recently, on my latest deploy to Heroku, I got a warning advising not to use AssetSync.
remote: ###### WARNING:
remote: You are using the `asset_sync` gem.
remote: See https://devcenter.heroku.com/articles/please-do-not-use-asset-sync for more information.
The original problem we were trying to solve by using AssetSync was that we were getting a huge slug size caused by the large assets in our application. Out of the 300MB that Heroku allows us, we were probably using close to 230MB - even though our git repo is only around 80MB.
We solved this by using AssetSync to synchronise all our compiled assets to a S3 bucket to be served through Cloudfront. After AssetSync runs, we have a hook that deletes all the precompiled assets to reduce the slug size. Basically, the workflow during slug compilation looked like this:
Let Heroku precompile the assets
AssetSync syncs all compiled assets to S3
All local copies of the compiled assets are deleted
The linked article argues a few points on why it's bad and what to use instead.
Using Asset Sync can cause failures. It is difficult to debug,
unnecessary, and adds extra complexity. Don’t use it. Instead, use a
CDN.
[...]
You should now use a CDN instead. Rather than
copying your assets over to S3 after they are precompiled, the CDN
grabs them from your website. Here are some reasons why that’s better.
Canonical assets
[...] It allows you to have single, authoritative places where you
store information. If you need to change that information, you only
need to change it in one place. [...] What happens if someone has a
failed deploy after assets get synced? What if someone modifies a file
in the S3 bucket? Instead of fixing one copy of assets, now you must
fix two.
Deploy determinism
If you’re debugging inside of a dyno with heroku run bash and you run
rake assets:precompile this doesn’t just modify your local copy. It
actually modifies the copy on S3 as well. [...] The sync part of
asset_sync can also fail if there’s a glitch in the network. What if
you only write part of a file, or only half of your assets are synced?
These things happen.
Although I agree with their points, the question remains: what's the recommended way to deploy a Heroku application that becomes huge when precompiled assets are stored in the slug?
The question is which assets files are making the slug huge?
By default, the Rails assets pipeline should only be used for small and limited internal assets (like JS, CSS, some logos, etc.).
It's not a great idea to store a huge amount of external or big files as Rails assets for many reasons aside the pipeline (like it's making your Git directory big in size too).
I have compiled assets using following command in rails 3.2 for production purpose.
RAILS_ENV=production bundle exec rake assets:precompile
After running above command an assets a folder is created under public. Now I want to removed non-compile assets folder because it is huge. But I have need answers to following questions.
Do I need the assets folder that contains non-compiled assets ?
If yes then what is purpose of having a non-compiled assets folder ?
I will appreciate your help.
Yes, keep them.
The purpose is that when they are taken from assets to public they are usually minified and combined, greatly saving space and helping to reduce download time for end users when using the site. But when you need to make changes, use the originals in assets.
In development mode (local, on your box), the assets version is used and is useful in traces while developing/debugging as they point to the actual source code lines in question and have the original (usually longer and meaningful) variable names.
Most likely you will need to make changes to one of your assets in app/assets in the future.
app/assets has the original source files with original formatting and these are the files you should change.
Theoretically you could delete the source files in app/assets, but then you won't be able to change anything and re-compile with those changes.
It takes an incredibly long time (> 10min) to precompile assets since I have large iconset folders in vendor/images. This makes it really convenient for development since I have all those icons at my disposal but I use a very small number of them. For these small icons I use the asset_data_uri helper throughout my sass files.
Is there a way to have asset pipeline to not compile all of the images, and just the ones I use? Or if it could just not digest compile the images and only make them available for asset_data_uri?
Compiled assets are written to the location specified in
config.assets.prefix. By default, this is the public/assets directory.
You can update config.assets.prefix with your set of locations you want to precompile
http://guides.rubyonrails.org/asset_pipeline.html#precompiling-assets
The default Rails app installed by rails new has config.assets.compile = false in production.
And the ordinary way to do things is to run rake assets:precompile before deploying your app, to make sure all asset pipeline assets are compiled.
So what happens if I set config.assets.compile = true in production?
I wont' need to run precompile anymore. What I believe will happen is the first time an asset is requested, it will be compiled. This will be a performance hit that first time (and it means you generally need a js runtime in production to do it). But other than these downsides, after the asset was lazily compiled, I think all subsequent access to that asset will have no performance hit, the app's performance will be exactly the same as with precompiled assets after this initial first-hit lazy compilation. is this true?
Is there anything I'm missing? Any other reasons not to set config.assets.compile = true in production? If I've got a JS runtime in production, and am willing to take the tradeoff of degraded performance for the first access of an asset, in return for not having to run precompile, does this make sense?
I wrote that bit of the guide.
You definitely do not want to live compile in production.
When you have compile on, this is what happens:
Every request for a file in /assets is passed to Sprockets. On the first request for each and every asset it is compiled and cached in whatever Rails is using for cache (usually the filesystem).
On subsequent requests Sprockets receives the request and has to look up the fingerprinted filename, check that the file (image) or files(css and js) that make up the asset were not modified, and then if there is a cached version serve that.
That is everything in the assets folder and in any vendor/assets folders used by plugins.
That is a lot of overhead as, to be honest, the code is not optimized for speed.
This will have an impact on how fast asset go over the wire to the client, and will negatively impact the page load times of your site.
Compare with the default:
When assets are precompiled and compile is off, assets are compiled and fingerprinted to the public/assets. Sprockets returns a mapping table of the plain to fingerprinted filenames to Rails, and Rails writes this to the filesystem. The manifest file (YML in Rails 3 or JSON with a randomised name in Rails 4) is loaded into Memory by Rails at startup and cached for use by the asset helper methods.
This makes the generation of pages with the correct fingerprinted assets very fast, and the serving of the files themselves are web-server-from-the-filesystem fast. Both dramatically faster than live compiling.
To get the maximum advantage of the pipeline and fingerprinting, you need to set far-future headers on your web server, and enable gzip compression for js and css files. Sprockets writes gzipped versions of assets which you can set your server to use, removing the need for it to do so for each request.
This get assets out to the client as fast as possible, and in the smallest size possible, speeding up client-side display of the pages, and reducing (with far-future header) requests.
So if you are live compiling it is:
Very slow
Lacks compression
Will impact render time of pages
Versus
As fast as possible
Compressed
Remove compression overheard from server (optionally).
Minimize render time of pages.
Edit: (Answer to follow up comment)
The pipeline could be changed to precompile on the first request but there are some major roadblocks to doing so. The first is that there has to be a lookup table for fingerprinted names or the helper methods are too slow. Under a compile-on-demand senario there would need to be some way to append to the lookup table as each new asset is compiled or requested.
Also, someone would have to pay the price of slow asset delivery for an unknown period of time until all the assets are compiled and in place.
The default, where the price of compiling everything is paid off-line at one time, does not impact public visitors and ensures that everything works before things go live.
The deal-breaker is that it adds a lot of complexity to production systems.
[Edit, June 2015] If you are reading this because you are looking for a solution for slow compile times during a deploy, then you could consider precompiling the assets locally. Information on this is in the asset pipeline guide. This allows you to precompile locally only when there is a change, commit that, and then have a fast deploy with no precompile stage.
To have less overhead with Pre-compiling thing.
Precompile everything initially with these settings in production.rb
# Precompile *all* assets, except those that start with underscore
config.assets.precompile << /(^[^_\/]|\/[^_])[^\/]*$/
you can then simply use images and stylesheets as as "/assets/stylesheet.css" in *.html.erb
or "/assets/web.png"
For anyone using Heroku:
If you deploy to Herkou, it will do the precompile for you automatically during the deploy if compiled assets are not included (i.e. public/assets not committed) so no need for config.assets.compile = true, or to commit the precompiled assets.
Heroku's docs are here. A CDN is recommended to remove the load on the dyno resource.
It won't be the same as precompiling, even after that first hit: because the files aren't written to the filesystem they can't be served directly by the web server. Some ruby code will always be involved, even if it just reads a cache entry.
Set config.asset.compile = false
Add to your Gemfile
group :assets do
gem 'turbo-sprockets-rails3'
end
Install the bundle
Run rake assets:precompile
Then Start your server
From the official guide:
On the first request the assets are compiled and cached as outlined in development above, and the manifest names used in the helpers are altered to include the MD5 hash.
Sprockets also sets the Cache-Control HTTP header to max-age=31536000. This signals all caches between your server and the client browser that this content (the file served) can be cached for 1 year. The effect of this is to reduce the number of requests for this asset from your server; the asset has a good chance of being in the local browser cache or some intermediate cache.
This mode uses more memory, performs poorer than the default and is not recommended.
Also, precompile step is not trouble at all if you use Capistrano for your deploys. It takes care of it for you. You just run
cap deploy
or (depending on your setup)
cap production deploy
and you're all set. If you still don't use it, I highly recommend checking it out.
Because it is opening a directory traversal vulnerability - https://blog.heroku.com/rails-asset-pipeline-vulnerability