If the goal is for the product to feel extremely fast, I prioritize work in the order that delivers the biggest improvement to perceived responsiveness—not necessarily the biggest benchmark improvement.
Here's the order I usually think about it:
-
Measure first
- Identify the slowest user journeys.
- Track metrics like page load, interaction latency, API response times, and database query duration.
- It's common to find that one or two bottlenecks account for most of the delay.
-
Frontend responsiveness (highest impact on perception)
- Show meaningful content quickly.
- Reduce unnecessary re-renders.
- Load only what's needed (lazy loading, code splitting).
- Optimistically update the UI where appropriate.
- Prefetch likely next pages or data.
- Eliminate layout shifts and long main-thread tasks.
Users generally notice a responsive interface more than a backend that's 20 ms faster.
-
Database efficiency
- Optimize slow queries.
- Add the right indexes.
- Avoid N+1 query patterns.
- Return only the fields you need.
- Batch operations when possible.
A poorly indexed query can dominate request latency, so this is often the highest ROI backend optimization.
-
Caching
Cache only after understanding access patterns.
- Browser/CDN caching for static assets.
- API response caching for frequently requested data.
- In-memory caches (such as Redis) for expensive computations or database reads.
- Cache invalidation should be designed carefully; stale data bugs can outweigh performance gains.
-
Architecture
Keep the architecture as simple as possible until scale requires more.
- Modular design with clear boundaries.
- Background jobs for non-critical work.
- Event-driven workflows where appropriate.
- Horizontal scaling when demand justifies it.
Jumping to microservices or distributed systems too early often adds latency and operational complexity rather than reducing it.
A practical rule of thumb
If I were starting a new SaaS product, I'd roughly allocate my optimization effort like this:
- 40% frontend responsiveness and UX
- 30% database and API optimization
- 20% caching
- 10% architectural changes
That balance changes as the product grows. Early-stage products often benefit most from a fast UI and efficient queries. At larger scales—millions of requests per day—caching and architectural decisions become increasingly important.
The key principle is to optimize from the user's perspective: reducing the time until users can see content, interact with the interface, or complete their task typically delivers more value than chasing the lowest possible server response time alone.
