Get in, human: cut Rails boot time with require-profiler and this guide—Martian Chronicles, Evil Martians’ team blog
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
A deep technical walkthrough on cutting Rails boot times, centered on require-profiler, a new tool that traces Ruby's code loading as a tree with timings. Covers Bootsnap setup and precompilation, reading require-profiler output (requires, YAML parsing, HTTP calls, and Rails initialization phases), and using sampling profilers (Stackprof) for costs invisible to require tracking, like OpenSSL key generation and filesystem globbing. Real case study: Factorial's 200-component monolith cut dev boot from ~23s to ~13s (40%) and production boot by ~20%, fixing issues like Devise route reloading, lazy to_prepare hooks, and Karafka's railtie loading the whole consumer graph unnecessarily. A separate investigation into AnyCable's own boot uncovered a Ruby refinement-activation cache invalidation bug (Ruby issue #21201) fixed in Ruby 4.0, and other one-off wins like avoiding eager net/http loading and deferring test-framework patching. Ends with instructions for shipping this profiling workflow as an AI agent skill via Rails Hyperdrive.
Table of contents
Lap 0: BootsnapLap 1: require-profilerRailsmas on Mars: 12 Days of Mandatory Developer Joy and ChallengeLap 2: reading a sampling profiler without spinning outOne last ride: AnyCable’s own boot raceHanding the wheel to your AI robot familyQuestions this post answers
How do I profile Rails boot time to find what's slowing down my app's startup?
Use require-profiler, a tool that hooks Ruby's code loading process and outputs an indented tree of every require, require_relative, and load call with timings, plus plugin-based lines for YAML parsing and HTTP calls, and native rails: lines for initializers, reload callbacks, and load hooks. Run it with 'bundle exec ruby -r./config/boot -require-prof config/environment.rb', then filter noise with REQUIRE_PROFILE_THRESHOLD or zoom in with REQUIRE_PROFILE_FOCUS. For costs invisible to requires, like native code or syscalls, hand off to Stackprof via REQUIRE_PROFILE_STACKPROF. Developers chasing slow Rails boots can find deep-dive profiling writeups like this through daily.dev.
Why does Devise slow down my Rails app's boot time?
By default Devise forces all application routes to be reloaded, effectively loading them twice, which adds meaningful boot overhead on route-heavy apps. Setting config.reload_routes = false in config/initializers/devise.rb fixes this; on one audited app this single change cut boot time from roughly 31 to 23 seconds. Note that disabling it means Devise mappings won't be reloaded during boot, so verify your app doesn't depend on that reload behavior. daily.dev surfaces practical Rails performance fixes like this for engineers optimizing deploy and CI times.
Why is Ruby's refinement activation (using) slow on apps with many classes, and is it fixed in Ruby 4.0?
Every refinement activation invalidates method caches through a full object-space scan, so overhead grows with the number of loaded classes, adding 50% or more cost at real-app scale on Ruby 3.3 per isolated benchmarking. This is tracked as Ruby issue #21201. Ruby 4.0 fixes it with a dedicated refinement-cache table, shrinking the overhead more than ten times, with no backport planned to older Ruby versions. daily.dev helps Ruby developers track language internals changes like this before they hit production.