Diagnosing a slow Rails page, layer by layer
"This page feels slow" is a vague bug report. Before changing any code, it helps tohave a fixed way to locatewherethe time goes. A Rails request passes through a fewpredictable layers, and each layer has its. . .
"This page feels slow" is a vague bug report. Before changing any code, it helps tohave a fixed way to locatewherethe time goes. A Rails request passes through a fewpredictable layers, and each layer has its own tools and its own typical failure mode. Here is the mental model I use, and a real example of walking it end to end. The layers of a requestMiddleware → Controller → SQL → View → external calls → browserEnter fullscreen modeExit fullscreen modeMost slowness lives in one of these:LayerTypical problemHow it shows upControllerheavy logic in the requestlarge "Executing" timeSQL (count)N+1 — many tiny repeated queriesquery count explodesSQL (single)a slow query, usually a missing indexone query dominatesViewrendering logic, or N+1 hiding in the templatelarge "Rendering" timeExternala synchronous API/email calla gap that isn't SQLBrowserlarge images, heavy JSbackend fast, page still slowThe point is not to guess. It's to read the numbers and let them point at the layer. Step 1 — read the numbers (development)In development I lean on two tools:rack-mini-profiler— a badge in the corner that breaks a request into controller / view / SQL time, and counts every query. bullet— watches for N+1 and tells you exactly which association to preload. On a storefront page that lists a page of 48 products, rack-mini-profiler showed:Executing: stores#show 2 sqlRendering: show. html. erb 49 sql ← 49 queries just to render? SQL Summary: 51 sql totalEnter fullscreen modeExit fullscreen modeFifty-one queries to render one page of products is a red flag, and the fact that 49 ofthem happen duringrenderingpoints straight at the view. bullet confirmed it:USEeagerloadingdetectedProduct=>[:image_attachment]Addtoyourquery:. includes([:image_attachment])Enter fullscreen modeExit fullscreen modeStep 2 — understand the N+1The products use Active Storage for their images:classProduct 0")# after@products=Product. where("stock > 0"). with_attached_imageEnter fullscreen modeExit fullscreen mode(with_attached_imageis just an Active Storage flavouredincludes. )Re-measured on the same page:BeforeAfterSQL queries513ActiveRecord time~210 ms~12 msbullet warningsyesnoneThe query count is now flat regardless of how many products are on the page — O(1) instead of O(n). That's the real win: N+1 isn't scary because of its cost on any single request, it's scary because it grows with your catalog and your traffic. The same page under a few hundred requests a minute turns a handful of extra queries into thousands of extra round-trips against the database. The other kind of slow: a single heavy queryN+1 is about querycount. The other common case is one query that is slow on its own — usually a missing index. HereEXPLAINis the tool: it shows how Postgres plans to run a query without running it. Looking up orders by a column with no index, over anorderstable with ~800k rows:SeqScanonorders(cost=0. 00. . 21450. 00rows=1width=93)Filter:(customer_email='someone@example. com')Enter fullscreen modeExit fullscreen modeSeq Scanmeans Postgres reads the whole table row by row to find one order — wasteful when there are hundreds of thousands of them. After adding an index on that column:IndexScanusingindex_orders_on_customer_emailonorders(cost=0. 42. . 8. 44rows=1. . . )IndexCond:(customer_email='someone@example. com')Enter fullscreen modeExit fullscreen modeSeq Scan → Index Scan, and the planner's cost estimate drops from ~21,000 to ~8 — the index turns "scan everything" into "jump straight to the row. "Two gotchas worth knowing:Data volume matters. On a small table Postgres picksSeq Scaneven when an index exists — scanning a few rows is cheaper than an index lookup. The index only earns its keep once the table is large, so test against production-scale data, not a dev seed. Selectivity matters. An index only helps when the query matches a small slice. A query that returns most of the table will be aSeq Scanregardless. How this plays out in productionDevelopment tools (rack-mini-profiler, bullet) catch problemsbeforethey ship. But dev never fully mirrors production — you don't hit every page, your data is small, and some N+1s only appear with real data shapes. So production needs an APM (I use Scout) watching real traffic to catch what slipped through. The end-to-end flow when something is slow in production:APM flags a slow endpoint → reproduce locally with realistic data → EXPLAIN the suspect query → add the index / preload / cache → deploy, confirm in the APM that it actually got fasterEnter fullscreen modeExit fullscreen modebullet is the prevention, the APM is the evidence. They're not redundant — they're defense in depth, because dev can never be a perfect copy of prod. TakeawaysDon't guess where a page is slow — read it layer by layer. Two distinct DB problems: many queries (N+1, fix withincludes/preload) vs one slow query (missing index, find withEXPLAIN). N+1 matters because it scales with data, not because it's slow today. EXPLAINresults depend on data volume and selectivity — test with realistic data. Prevent in development, verify in production.