Choose one slow experience
Start with a specific page, endpoint or report. Capture the inputs and data volume that make it slow. A dashboard with ten records and one with thousands may expose different problems. Define a repeatable observation before changing code so the comparison has meaning.
Look at the shape of the work
Review query count, execution time and the amount of data loaded. A sequence of small queries can become expensive when repeated for every row. Rails provides eager-loading tools such as includes and preload; use them when they fit the access pattern, then verify that they reduce the unwanted work.
Load only what the feature needs
Ask whether the page needs every record or every column it currently loads. Consider pagination, scoped summaries and narrower queries. Review generated SQL and the database execution plan before adding an index. An index should address an observed access pattern, with its write and storage costs understood.
Give cached data an owner
Caching introduces another question: when does the result stop being correct? Document the cache key, the relevant account context and the invalidation rule. Check whether a change in permissions or source records should invalidate the result. A fast response containing stale or cross-account data is still a failure.
Measure the same request again
Compare under a similar workload, and inspect both the response and its correctness. Record what improved and what remained expensive. Our preferred outcome is a small change with a clear explanation, so future developers know why the query or cache is shaped that way.