Speeding Up Sprockets for Faster Asset Pipelines

Summary

The Rails asset pipeline can take over 20 times longer than dependency installation because Sprockets consumes memory, disk I/O, and CPU while reading, fingerprinting, compressing, and resolving dependent assets. Reusing its disk cache failed across Capistrano releases and Heroku builds because cache keys and dependency data embedded absolute paths, so identical files appeared different when compiled from changing directories. Sprockets 3.3+ addresses this with UnloadedAsset, normalized relative cache keys, and URITar, which compresses paths and URIs before caching and expands them when loading; Windows portability was fixed in 3.3.4. In an example app, the initial compile remained about 38 seconds, while the second took 3 seconds, a roughly 1,200% speed increase when compiled assets were reused.

Takeaways

1. 1

   Sprockets cache keys based on absolute paths were not reusable across changing Capistrano release directories or Heroku build paths.

2. 2

   URITar compresses project-relative paths and URIs in cached data, addressing absolute paths found in asset filenames, dependencies, load paths, and related metadata.

3. 3

   An example application's initial compile stayed near 38 seconds, while a cached second compile took 3 seconds.