CODEWITHSUNDEEP
ruby-on-railsperformanceasset-pipelineassets
odigity
odigity

Reputation: 8176

If Rails asset pipeline combines all JS files into one to speed up download, doesn't that hurt caching?

The point of concatenation is to improve performance by having just one file to download, but that means that every time you change a bit of your own javascript, the whole package is recompiled and fingerprinted - including large libraries like jQuery that haven't changed, and would have been cached if they were downloadable separately, but now jQuery is going to be redownloaded each time as part of your unified application.js.

What am I missing here? Wouldn't the best approach be to create two manifests - one for your own files (which are small and change frequently), and one for libraries (which are large and change infrequently)?

Upvotes: 2

Views: 290

Answers (1)

mliebelt
mliebelt

Reputation: 15525

I will give it a try, with some speculation inside it ...

First, JQuery is provided by Rails itself, and depending on your layout, it will come from a CDN. So lets look at the libraries that may change over time. What are the scenarios here?

  • A user is visiting the web site for the first time. His browser (depending on the type) has to load all Javascript files before he can show something that comes below that (therefore, move it to the end). Depending on the browser, it may load 2, 4, 6 or 8 resources at one time, if your site consists of dozens or even hundreds of them, this will slow the presentation then.
  • A user is visiting the web site (this page) the second time. Normally on the same day, hour or even minute. The whole thing will be cached, there is only one request, that the cached thing can be used, pretty fast then. If all resources (hundreds) would be loaded one after another, there will be hundreds of requests if the cache is valid.
  • A user is visiting the web site the second time, and there was some time in between (lets say 15 days). Only 1 resource was changed, all other could be cached and reused. How probable is that?
  • A user (the developer) is visiting his work during development. No asset pipeline is used, no caching, because every change should be noticed immediately.

So I think, from a web site view, only the scenario 3 may be (a little bit) slower, and it is the most improbable one. Normally, the overhead of many, many requests is much more relevant than the size of the requests.

If you have the time, just try with a tool that displays it the loading time of all resources. There may be edge cases that one resource will change often, and should therefore not included in the asset pipeline, but normally, every change includes numerous resources, and caching them as one bit blob helps to avoid a lot of requests.

Here are some references to literature that discusses this:

Upvotes: 4

Related Questions