Consultant web performance expert Ruby on Rails

Optimiser la web performance des applications Ruby on Rails

Ruby on Rails motorise depuis vingt ans des produits ambitieux — GitHub, Shopify, Basecamp. La productivité du framework couvre parfois des dérives ActiveRecord, cache et Puma qui n'apparaissent qu'à l'échelle. J'interviens sur l'ensemble pour livrer un TTFB stable et des Core Web Vitals au vert.

100% de clients satisfaits Données 2023-2026 • 8+ ans XP • 35+ clients accompagnés

Voir mes cas clients

Ils me font confiance

Les symptômes Rails qui appellent un audit

Rails présente des goulets caractéristiques sur ActiveRecord, le cache, Puma et Ruby non-JITé.

🔁 N+1 ActiveRecord silencieux

Les vues qui itèrent (listings, dashboards, feeds) déclenchent une requête par élément. Bullet en local + includes/preload ciblés descendent le TTFB de 40 à 70% sur les endpoints concernés.

💾 Cache Rails sous-exploité

Fragment cache et touch cascades (Russian doll) servent un rendu complexe en 5 ms au lieu de 300. La majorité des apps Rails l'ignorent ou l'implémentent partiellement.

🐢 Ruby sans YJIT

Ruby 3.2+ embarque YJIT, qui divise le CPU Rails par 1.5 à 2 sur les workloads typiques. L'activation coûte une variable d'environnement et un redémarrage.

📡 Puma sous-dimensionné

Workers × threads mal accordés au profil de trafic. Trop peu → queue latency, trop → OOM. Le calibrage descend le p95 de plusieurs centaines de ms.

⚙️ Asset pipeline en retard

Sprockets vieillissant, Import maps mal exploités, préchargement absent. Le passage à Propshaft + Import maps modernise le pipeline sans refonte front.

🚀 Sidekiq et jobs bloquants

Traitements synchrones qui devraient être async, ou Sidekiq sans concurrence adaptée. La bascule ActiveJob + Sidekiq tuné libère les workers Puma.

Méthodologie d'optimisation Rails

4 étapes pour transformer votre performance

Étape 1

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

Identification des N+1 ActiveRecord, des vues lentes, des jobs synchrones à basculer. Cartographie des endpoints LCP-critiques.

Étape 2

2. Optimisation ActiveRecord

Includes/preload explicites, counter_cache, indexes SQL manquants, pluck pour les exports, in_batches et find_each sur les volumes.

Étape 3

3. Cache et rendu

Fragment cache + Russian doll, low-level cache Rails.cache sur Redis, HTTP cache via CDN frontal, Turbo Drive/Frames sur les navigations riches.

Étape 4

4. Runtime : YJIT, Puma, Sidekiq

Activation YJIT sur Ruby 3.3, calibrage Puma workers × threads, tuning Sidekiq concurrency, bootsnap et eager_load en prod.

Étape 1

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

Identification des N+1 ActiveRecord, des vues lentes, des jobs synchrones à basculer. Cartographie des endpoints LCP-critiques.

Étape 2

2. Optimisation ActiveRecord

Includes/preload explicites, counter_cache, indexes SQL manquants, pluck pour les exports, in_batches et find_each sur les volumes.

Étape 3

3. Cache et rendu

Fragment cache + Russian doll, low-level cache Rails.cache sur Redis, HTTP cache via CDN frontal, Turbo Drive/Frames sur les navigations riches.

Étape 4

4. Runtime : YJIT, Puma, Sidekiq

Activation YJIT sur Ruby 3.3, calibrage Puma workers × threads, tuning Sidekiq concurrency, bootsnap et eager_load en prod.

Engagements de la mission

-50% TTFB Rails typique

YJIT Ruby 3.3 activé

Russian doll cache orchestré

Continu stack Rails surveillée

FAQ

Questions fréquentes

YJIT en production, gain réel ?

Oui. Sur Ruby 3.3 (YJIT stabilisé depuis 3.2, mature à partir de 3.3), YJIT descend le CPU Rails de 30 à 50% sur les workloads typiques. GitHub et Shopify l'exploitent en production à grande échelle. Activation via RUBY_YJIT_ENABLE=1 ou --yjit — sans surprise sur les apps standards.

Turbo/Hotwire ou SPA React/Vue ?

Turbo Drive + Frames + Streams couvre 80% des cas de navigation dynamique avec un budget JS minimal — souvent moins de 40 KB. Pour une SPA React ou Vue justifiée (éditeur riche, dashboard temps réel), inutile de convertir toute l'app : garder Rails classique sur le reste et embarquer la SPA sur les sections concernées.

Sprockets, Propshaft ou esbuild ?

Sur Rails 7+, Propshaft + Import maps est le défaut recommandé — pas de compilation, pas de bundler côté serveur. Pour du JS moderne avec TypeScript ou bundling avancé, jsbundling-rails avec esbuild reste léger et rapide. Sprockets ne se justifie plus sur les nouveaux projets.

Comment se structurent vos accompagnements Rails ?

Mes accompagnements Rails s'inscrivent dans la durée. Le diagnostic initial pose la roadmap (ActiveRecord, cache, YJIT, Puma, Sidekiq). Les sprints suivants déroulent les optimisations et valident chaque release. Sur une application Rails complexe (multi-tenant, marketplace), la performance se maintient par une présence continue, pas par une intervention ponctuelle.

Faire baisser votre TTFB Rails

ActiveRecord optimisé

Cache orchestré

YJIT + Puma tuné

100% de clients satisfaits
Données 2023-2026

Témoignages

Ce qu'en disent mes clients

Excellent travail.
Paul a nettement amélioré la vitesse du site et l’a parfaitement aligné avec les recommandations Google.
Professionnel, rigoureux et efficace, je recommande vivement.

Nicolas - April Moto

Directeur digital & e-commerce

Nous sommes très satisfaits du travail de Paul. Il se montre rapide, disponible et particulièrement efficace. Depuis son arrivée, de très bons résultats ont été constatés, tant en termes de performance que de réactivité. Un vrai atout pour notre équipe.

Léo - Maison de luxe

E-commerce Product Owner

Je sais pas si on l'a assez répété.
Mais si vous voulez améliorer votre vitesse de chargement,
Faire plaisir à Google et mettre vos Signaux Web Essentiels dans le vert,
Contactez Paul Delcloy.

Florian Darroman - Les Makers

Co-fondateur

Ruby on Rails, l'écosystème mature qui exige de la discipline

Ruby on Rails motorise depuis vingt ans des produits majeurs — GitHub, Shopify, Basecamp, Airbnb à ses débuts. Convention over configuration, ActiveRecord, Turbo/Hotwire, ActiveJob : un stack cohérent qui accélère massivement le développement. Ce niveau de productivité couvre parfois des dérives de performance qui ne se voient qu'à l'échelle : N+1 ActiveRecord, cache mal orchestré, Puma sous-dimensionné, Ruby non-JITé.

L'angle d'optimisation web performance sur Rails est full-stack : profiling via rack-mini-profiler, Bullet, Skylight ou AppSignal, chasse aux N+1 ActiveRecord, fragment cache et Russian doll caching, tuning Puma (workers × threads), Redis cache_store, activation YJIT sur Ruby 3.3+, et Turbo Drive / Frames / Streams côté rendu.

ActiveRecord, premier levier de perf Rails

ActiveRecord est l'ORM Rails et la source la plus fréquente de dérives TTFB. N+1 sur les vues qui itèrent, includes/preload mal ciblés, requêtes déclenchées dans les partials, absence d'index sur les foreign keys : le coût s'accumule silencieusement au fil des sprints.

Bullet expose ces motifs en local et staging. Le refactor (includes explicite, counter_cache, indexes SQL manquants, requêtes scalar via pluck) descend le TTFB de 40 à 70% sur les listings et les dashboards concernés. Sur les gros volumes, .in_batches et find_each évitent les blow-ups mémoire.

Cache Rails et Turbo pour tenir les Core Web Vitals

Rails intègre un système de cache multi-niveaux — fragment cache avec touch cascades (Russian doll), low-level cache via Rails.cache, HTTP cache via Rack::Cache ou un CDN frontal. Bien orchestré, il transforme un rendu qui consomme 300 ms en un rendu servi en 5 ms.

Turbo Drive et Turbo Frames complètent l'angle côté front : navigation sans reload, morphing DOM, Streams pour les updates ciblées. Sur les pages riches, cela stabilise LCP et INP sans SPA lourde. C'est ce qui distingue les Rails rapides des Rails qui rament malgré Ruby 3.3 et YJIT : la discipline de cache et la maîtrise du rendu, pas la puissance du serveur.

Technologies

Autres expertises Technologies

Angular

Angular optimisé : lazy modules, OnPush change detection, SSR Universal ou Analog, signals, zone.js élimination. Core Web Vitals stables sur SPA enterprise.

Découvrir

Astro

Astro optimisé : islands architecture, image optimization, view transitions, content collections. Sites quasi-statiques avec Core Web Vitals au vert.

Découvrir

Drupal

Drupal optimisé : Render API et cache contexts, Dynamic Page Cache + BigPipe, Views performance, MySQL tuning. Core Web Vitals au vert sur les templates stratégiques.

Découvrir