Web performance consultant for Ruby on Rails

Optimize web performance on Ruby on Rails applications

Ruby on Rails has powered ambitious products for twenty years — GitHub, Shopify, Basecamp. The framework's productivity sometimes hides ActiveRecord, cache and Puma drifts that only surface at scale. I work across the whole stack to deliver stable TTFB and green Core Web Vitals.

100% satisfied clients Data 2023-2026 • 8+ years XP • 35+ clients partnered

View my client cases

They trust me

Rails symptoms calling for an audit

Rails shows characteristic bottlenecks on ActiveRecord, cache, Puma and non-JIT Ruby.

🔁 Silent N+1 ActiveRecord

Iterating views (listings, dashboards, feeds) fire one query per element. Bullet locally + targeted includes/preload drop TTFB 40 to 70% on affected endpoints.

💾 Rails cache underused

Fragment cache and touch cascades (Russian doll) serve a complex render in 5 ms instead of 300. Most Rails apps ignore it or implement it partially.

🐢 Ruby without YJIT

Ruby 3.2+ ships YJIT, which halves Rails CPU on typical workloads. Activation costs one environment variable and one restart.

📡 Undersized Puma

Workers × threads mis-tuned for the traffic profile. Too few → queue latency, too many → OOM. Calibration drops p95 by hundreds of ms.

⚙️ Asset pipeline lagging

Aging Sprockets, Import maps underused, no preloading. Moving to Propshaft + Import maps modernizes the pipeline without a frontend rewrite.

🚀 Sidekiq and blocking jobs

Synchronous work that should be async, or Sidekiq without adequate concurrency. Switching to ActiveJob + tuned Sidekiq frees the Puma workers.

Rails optimization methodology

4 steps to transform your performance

Step 1

1. rack-mini-profiler, Bullet, Skylight profiling

Identify N+1 ActiveRecord, slow views, synchronous jobs to switch. Map LCP-critical endpoints.

Step 2

2. ActiveRecord optimization

Explicit includes/preload, counter_cache, missing SQL indexes, pluck for exports, in_batches and find_each on large volumes.

Step 3

3. Cache and rendering

Fragment cache + Russian doll, Rails.cache low-level cache on Redis, HTTP cache via frontal CDN, Turbo Drive/Frames on rich navigation.

Step 4

4. Runtime: YJIT, Puma, Sidekiq

YJIT activation on Ruby 3.3, Puma workers × threads calibration, Sidekiq concurrency tuning, bootsnap and eager_load in production.

Step 1

1. rack-mini-profiler, Bullet, Skylight profiling

Identify N+1 ActiveRecord, slow views, synchronous jobs to switch. Map LCP-critical endpoints.

Step 2

2. ActiveRecord optimization

Explicit includes/preload, counter_cache, missing SQL indexes, pluck for exports, in_batches and find_each on large volumes.

Step 3

3. Cache and rendering

Fragment cache + Russian doll, Rails.cache low-level cache on Redis, HTTP cache via frontal CDN, Turbo Drive/Frames on rich navigation.

Step 4

4. Runtime: YJIT, Puma, Sidekiq

YJIT activation on Ruby 3.3, Puma workers × threads calibration, Sidekiq concurrency tuning, bootsnap and eager_load in production.

Mission commitments

-50% typical Rails TTFB

YJIT Ruby 3.3 activated

Russian doll cache orchestrated

Continuous Rails stack monitored

FAQ

Frequently asked questions

YJIT in production, real gain?

Yes. On Ruby 3.3 (YJIT stabilized since 3.2, mature from 3.3), YJIT drops Rails CPU 30 to 50% on typical workloads. GitHub and Shopify run it in production at scale. Activation via RUBY_YJIT_ENABLE=1 or --yjit — no surprises on standard apps.

Turbo/Hotwire or a React/Vue SPA?

Turbo Drive + Frames + Streams covers 80% of dynamic navigation with a minimal JS budget — often under 40 KB. For a justified React or Vue SPA (rich editor, real-time dashboard), no need to convert the whole app: keep classic Rails on the rest and embed the SPA where relevant.

Sprockets, Propshaft or esbuild?

On Rails 7+, Propshaft + Import maps is the recommended default — no compilation, no server-side bundler. For modern JS (TypeScript, advanced bundling), jsbundling-rails with esbuild stays light and fast. Sprockets no longer justifies itself on new projects.

How are your Rails engagements structured?

My Rails engagements run long-term. The initial diagnosis sets the roadmap (ActiveRecord, cache, YJIT, Puma, Sidekiq). Following sprints work optimizations and validate every release. On a complex Rails application (multi-tenant, marketplace), performance stays maintained through continuous presence, not isolated intervention.

Drop your Rails TTFB

ActiveRecord optimized

Cache orchestrated

YJIT + tuned Puma

100% satisfied clients
Data 2023-2026

Testimonials

What my clients say

Excellent work.
Paul has significantly improved the site's speed and perfectly aligned it with Google's recommendations.
Professional, thorough, and efficient, I highly recommend.

Nicolas - April Moto

Digital & E-commerce Director

We are very satisfied with Paul's work. He is quick, available, and particularly effective. Since his arrival, very good results have been observed, both in terms of performance and responsiveness. A real asset for our team.

Léo - Luxury brand

E-commerce Product Owner

I don't know if we've said it enough.
But if you want to improve your loading speed,
Make Google happy and get your Core Web Vitals in the green,
Contact Paul Delcloy.

Florian Darroman - Les Makers

Co-founder

Ruby on Rails, a mature ecosystem that demands discipline

Ruby on Rails has powered major products for twenty years — GitHub, Shopify, Basecamp, Airbnb in its early days. Convention over configuration, ActiveRecord, Turbo/Hotwire, ActiveJob: a coherent stack that dramatically accelerates development. That productivity level sometimes hides performance drifts only visible at scale: N+1 ActiveRecord, ill-orchestrated cache, undersized Puma, non-JIT Ruby.

The web performance optimization angle on Rails is full-stack: profiling via rack-mini-profiler, Bullet, Skylight or AppSignal; chasing N+1 ActiveRecord; fragment cache and Russian doll caching; Puma tuning (workers × threads); Redis cache_store; YJIT activation on Ruby 3.3+; and Turbo Drive / Frames / Streams on the rendering side.

ActiveRecord, the first Rails performance lever

ActiveRecord is Rails' ORM and the most common source of TTFB drift. N+1 on iterating views, ill-targeted includes/preload, queries triggered inside partials, missing indexes on foreign keys: the cost accumulates silently sprint after sprint.

Bullet exposes these patterns locally and in staging. Refactoring (explicit includes, counter_cache, missing SQL indexes, scalar queries via pluck) drops TTFB 40 to 70% on the affected listings and dashboards. On large volumes, .in_batches and find_each avoid memory blow-ups.

Rails cache and Turbo to hold Core Web Vitals

Rails ships a multi-layer cache system — fragment cache with touch cascades (Russian doll), low-level cache via Rails.cache, HTTP cache via Rack::Cache or a frontal CDN. Well orchestrated, it turns a 300 ms render into a 5 ms one.

Turbo Drive and Turbo Frames complete the front-side angle: no-reload navigation, DOM morphing, Streams for targeted updates. On rich pages, this stabilizes LCP and INP without a heavy SPA. That's what separates fast Rails apps from Rails apps that lag despite Ruby 3.3 and YJIT: caching discipline and rendering mastery, not raw server power.

Technologies

Other expertise Technologies

Angular

Angular optimized: lazy modules, OnPush change detection, SSR Universal or Analog, signals, zone.js elimination. Stable Core Web Vitals on enterprise SPAs.

Learn more

Astro

Astro optimized: islands architecture, image optimization, view transitions, content collections. Near-static sites with green Core Web Vitals.

Learn more

Drupal

Drupal optimized: Render API and cache contexts, Dynamic Page Cache + BigPipe, Views performance, MySQL tuning. Core Web Vitals green on strategic templates.

Learn more