10 API Design Mistakes That Kill App Performance (and Fixes)

10 API Design Mistakes That Kill App Performance (and Fixes) — cover image

Most slow apps are slow because of their APIs, not their screens. The usual culprits are endpoints that need many round trips to render one page, responses that return far more data than needed, lists without pagination, database queries that multiply with each item, and slow work done while the user waits. Fixing these rarely needs new infrastructure: shaping endpoints around what each screen needs, paginating, caching and moving heavy work to the background usually make the biggest difference.

Key Takeaways

Why API Performance Matters

Every extra second of waiting costs users. Google's Core Web Vitals treat loading and responsiveness as core quality signals, and Deloitte's Milliseconds Make Millions study found that a 0.1 second improvement in mobile site speed increased retail conversions by 8.4%. On mobile, slow APIs are amplified by network latency: each extra round trip adds delay that users feel.

Mistake 1: Chatty APIs

A screen that needs the user, their settings, their notifications and a list of items might make four or more separate requests, each waiting on the network. On a mobile connection that adds up fast.

Fix: design endpoints around screens or journeys, or use a query layer that lets the client request what it needs in one call. Our comparison of GraphQL, REST and tRPC covers the trade-offs.

Mistake 2: Over-fetching

Returning full objects with every field and nested relation when the client needs a name and a thumbnail wastes bandwidth and server time.

Fix: return only the fields each client needs, offer lightweight list representations, and let clients request detail views separately.

Mistake 3: No Pagination

Endpoints that return every record work fine in testing and fail in production as data grows.

Fix: paginate every list endpoint, preferably with cursor-based pagination for large or frequently changing datasets, and set sensible maximum page sizes.

Mistake 4: N+1 Queries

Loading a list of 50 orders, then running a separate query for each order's customer, turns one query into 51. This is one of the most common reasons APIs slow down as usage grows.

Fix: load related data in bulk with joins or batched queries, and use query logging in development to catch the pattern. See slow database queries: indexing and tuning.

Mistake 5: Missing Indexes

Filters and sorts on unindexed columns force full table scans.

Fix: index the columns used in common filters, joins and sorts, and review slow query logs regularly.

Mistake 6: Slow Work Inside the Request

Generating a PDF, resizing an image, sending email or calling an AI model while the user waits ties up the server and the user.

Fix: accept the request, queue the work, return immediately, and notify the client when it is done. See background jobs and queues for web apps.

Mistake 7: No Caching

Recomputing the same data for every request, such as product catalogues, dashboards or configuration.

Fix: cache at the right layer (CDN, application cache or browser), with clear expiry rules, and use HTTP caching headers for responses that rarely change. Our caching strategy guide explains the layers.

Mistake 8: Large, Uncompressed Payloads

Uncompressed JSON and full-size images slow down every response, especially on mobile data.

Fix: enable compression, serve images in modern formats at the size needed, and use a CDN for media. For uploads, let clients upload directly to storage with presigned URLs.

Mistake 9: No Rate Limiting

A single misbehaving client or bot can slow the API for everyone.

Fix: apply rate limits per user, key or IP, return clear error responses and monitor for abuse. See API rate limiting and abuse protection.

Mistake 10: No Versioning or Contract

Breaking changes force clients to update at the same time as the server, which leads to rushed releases and workarounds that hurt performance. Mobile apps are especially affected, because users don't all update at once.

Fix: version your API, keep changes backward-compatible where possible, and document the contract. Designing the API before the UI helps; see API-first development.

How to Find API Performance Problems

  1. Measure per endpoint. Track response times (median and slowest 5%) and error rates.
  2. Trace slow requests to see where time goes: database, external calls or application code. OpenTelemetry helps here.
  3. Test from real conditions, including mobile networks and realistic data volumes.
  4. Load test before launches with a tool like k6.
  5. Fix the biggest bottleneck first, then measure again.

The Business Impact

Slow APIs show up as lower conversion, more abandoned sessions, poorer app store ratings and higher cloud bills. They also slow the team, because performance firefighting crowds out feature work. For the wider architecture picture, read the hidden cost of poor backend architecture.

Related reading: 10 Lessons From Products That Scaled to a Million Users.

How We Help

Mavani Solution designs APIs for mobile and web products and audits existing APIs for performance. Explore our mobile app development and web development services.

Frequently Asked Questions

What makes an API slow?
Common causes are too many round trips per screen, returning more data than needed, missing pagination, N+1 database queries, missing indexes, slow work done during the request and no caching.
What is the N+1 query problem?
It happens when code loads a list of records and then runs a separate query for each one to fetch related data. One request becomes many database queries, which gets slower as the list grows. Loading related data in bulk fixes it.
How do I improve API performance for a mobile app?
Reduce round trips by designing endpoints around screens, return only needed fields, paginate lists, compress responses, cache where possible and move heavy work to background jobs.
Is GraphQL faster than REST?
Not inherently. GraphQL can reduce over-fetching and round trips because clients request exactly what they need, but poorly designed GraphQL resolvers can cause N+1 queries. Either approach can be fast with good design.
How do I measure API performance?
Track response times per endpoint, including the slowest 5% of requests, along with error rates. Use tracing to see where time is spent, and load test with realistic traffic before launches.