---
title: "Speeding Up Sprockets for Faster Asset Pipelines"
description: "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."
---

# Speeding Up Sprockets for Faster Asset Pipelines

[Heroku](https://yomu.fyi/company/heroku) · Richard Schneeman · Feb 22, 2016

**Type:** Explainer

## 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.

## Context

The Rails asset pipeline is slow because Sprockets reads, processes, fingerprints, compresses, and resolves assets and their dependencies. Cache reuse also broke when Capistrano and Heroku compiled the same project from different absolute paths, producing different cache keys and forcing unnecessary processing.

## Approach / What changed

Sprockets 3.3+ introduces UnloadedAsset for normalized cache keys and URITar for compressing absolute paths and URIs before they are stored in the cache, then expanding them when retrieved. Additional filesystem portability fixes were released in Sprockets 3.3.4.

## Takeaways

- Sprockets cache keys based on absolute paths were not reusable across changing Capistrano release directories or Heroku build paths.
- URITar compresses project-relative paths and URIs in cached data, addressing absolute paths found in asset filenames, dependencies, load paths, and related metadata.
- An example application's initial compile stayed near 38 seconds, while a cached second compile took 3 seconds.

**Tags:** [Caching](https://yomu.fyi/topic/caching), [Performance](https://yomu.fyi/topic/performance), [Ruby on Rails](https://yomu.fyi/topic/ruby-on-rails), [Sprockets](https://yomu.fyi/topic/sprockets)

- Source: [Heroku](https://www.heroku.com/blog/speeding-up-sprockets)
- Source URL: https://www.heroku.com/blog/speeding-up-sprockets
- Ingested by Yomu: 2026-09-09T14:24:28.524Z

[Read original post](https://www.heroku.com/blog/speeding-up-sprockets)