A slow app with unhappy users is stressful, but it is usually fixable. If you are asking “why is my app slow?”, the answer is rarely the framework. In most cases it is one or two bottlenecks, most often in the database or the API layer.
This guide shows you how to find the cause in under an hour. It also covers the five problems we see most and how to tell a fix from a rebuild.
Diagnose it yourself in under an hour
You do not need to read the code to find where time goes. You need to time a few slow screens from the outside in. Write down the three actions users complain about most, then run these checks on each.
1. Measure the web front end (15 minutes)
Open Chrome DevTools and run a Lighthouse report in mobile mode. Then reload with the Network tab open and cache disabled. Google's Core Web Vitals guidance sets the “good” thresholds: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 ms, and Cumulative Layout Shift under 0.1.
The rough guides we use for first load:
- Healthy: typically under 2 MB transferred, under 60 requests, and under 500 KB of compressed JavaScript.
- Trouble: 5 MB or more, hundreds of requests, or a single API call that takes several seconds.
2. Time the API calls (15 minutes)
In the Network tab, sort by duration and click the slowest API responses. Look at “Waiting for server response”, the time to first byte. A healthy API typically answers in under 300 ms; over one second points at the server, not the browser.
Also count calls per screen. If one page fires 40 requests to the same endpoint, you have a chatty front end.
3. Check the mobile app's vitals (10 minutes)
For Android, open Android vitals in Google Play Console. Google's Android vitals documentation treats a user-perceived ANR rate above 0.47% as bad behavior. Crossing that threshold can hurt your visibility on Google Play.
For iOS, the Xcode Organizer shows launch time, hangs and memory use from real devices. Apple covers these reports in its Xcode documentation.
4. Look at the database (15 minutes)
Turn on the slow query log, or open your cloud's query tool, such as AWS RDS Performance Insights or Cloud SQL Query Insights. Sort by total time, not time per query. A 40 ms query that runs 2,000 times a minute costs more than a 3-second query that runs once a day.
5. Check the server (5 minutes)
Look at CPU, memory and database connection counts in your hosting dashboard during peak hours. CPU pinned above 80% or a maxed-out connection pool means raw load is the problem. Low CPU with slow responses usually means the server is waiting on the database or a third-party API.
If you would rather have a second pair of eyes on these numbers, you can request a free code or performance audit and get a ranked list of what is slowing your app down.
Why is my app slow? The five usual causes, ranked
This ranking reflects how often we find each cause in our rescue work, not a published study. Most slow apps have two of these at once.
1. Inefficient database queries
This is the most common cause by a wide margin. The classic pattern is the N+1 query: the code loads 50 orders, then runs one more query per order to fetch each customer. That is 51 round trips where one join would do.
The second pattern is a missing index. A query like SELECT * FROM orders WHERE customer_id = 42 scans every row until you add CREATE INDEX idx_orders_customer ON orders (customer_id);. On a table with a few million rows, that change alone typically takes a query from seconds to milliseconds.
2. APIs that send too much, too often
Endpoints often return whole objects with every nested record when the screen needs five fields. Lists come back unpaginated, so a page that worked with 200 rows breaks at 20,000. The fixes are pagination, field selection, and one endpoint per screen instead of a dozen small calls.
3. Heavy front-end bundles and images
Single-page apps tend to grow until the whole app ships on first load. Code splitting by route, removing unused libraries, and serving correctly sized WebP or AVIF images usually cut first-load weight by half or more. On mobile, large images and heavy startup work hurt launch time the same way.
4. No caching
If the same dashboard totals are recalculated for every user on every request, you pay for work that rarely changes. A Redis cache with a 60-second expiry, plus caching headers and a CDN for static files, often removes most of the load. The trade-off is staleness, so decide per screen how old the data can be.
5. Blocking work and slow third parties
Sending emails, building PDFs or calling payment and CRM APIs inside the request makes users wait on someone else's server. Move that work to a background queue such as Sidekiq, Celery or BullMQ. On mobile, the same mistake shows up as network or disk work on the main thread, which causes frozen screens and ANRs.
Fix or rebuild: how to tell
Almost every performance problem is a fix. Speed alone is rarely a reason to rebuild. The real question is whether the bottleneck is local or built into the design.
Usually a fix (days to a few weeks)
- Missing indexes and N+1 queries
- Unpaginated lists and oversized API responses
- No caching or CDN
- Emails, exports or third-party calls made inside the request
- Bloated bundles and unoptimized images
Possibly a rebuild of one part (weeks to months)
- A data model that forces a dozen joins for every screen
- Business logic spread across the front end, so every change is risky
- A framework or runtime years out of support that blocks upgrades
- No tests at all, so every speed fix breaks something else
Even then, we usually rebuild the worst module behind the existing API rather than the whole app. A full rewrite delays every user-facing fix by months.
If your agency relationship is failing, protect yourself first
Slow apps often come with a slow or unresponsive agency. Before you raise the problem formally, make sure you can run the product without them.
- Source code: the repository lives in a GitHub, GitLab or Bitbucket organization you own, with you as an owner. Not a fork and not a zip file.
- Cloud and hosting: owner-level access to AWS, Google Cloud, Azure or your host, billed to your company.
- App store accounts: your company holds the Apple Developer and Google Play Console accounts. Transferring an app later is possible but slow.
- Domains and DNS: registrar logins in your name, plus the email and SMS provider accounts.
- Secrets and keys: a list of API keys and signing keys, and where each one is stored.
- Documentation: a README that explains how to run and deploy the app, plus the database schema.
Contractually, check that your agreement assigns IP to you on payment. It should also require handover of code and credentials on termination. If it does not, fix that before you escalate, and pay for work delivered rather than work promised.
What the first week of a rescue looks like
This is how we run the first five days of a performance rescue. The goal of week one is a ranked, costed plan, not a heroic rewrite.
- Day 1, access and baseline: we get read access to code, hosting, monitoring and the database. We record current timings for the three worst user journeys.
- Day 2, instrument: if there is no monitoring, we add an APM tool such as Sentry, Datadog or New Relic. Real traces beat guesses.
- Day 3, profile: we trace the slowest requests end to end and read the query plans behind them.
- Day 4, quick wins: we ship low-risk fixes, typically indexes and caching headers, with monitoring in place so we can roll back.
- Day 5, report: you get issues ranked by user impact, with effort estimates and a clear fix-or-rebuild call per area.
Quick wins often improve at least one bad screen within that first week. Structural fixes take longer and follow in planned sprints.
FAQ
Why is the app fast for me but slow for users?
You probably test on fast Wi-Fi, a recent phone and a small dataset. Real users have older devices, mobile networks and accounts with years of data. Test on a mid-range Android phone with network throttling and a production-sized copy of the data.
How much does it cost to fix a slow app?
It depends on the cause. Query, caching and pagination fixes typically take days to a few weeks of developer time. Architectural problems can run to months, which is why diagnosis comes first.
Will adding more servers fix a slow app?
Only if the servers are genuinely overloaded, and even then it is usually a stopgap. If the bottleneck is the database, more app servers can make things worse by opening more connections. Measure first, then scale.
