---
title: "My app is slow for everyone but me"
description: "Your app feels fast to you and slow to everyone else. Here are the usual causes, in the order they turn out to be the problem."
url: https://www.fomio.ai/blog/my-app-is-slow-for-everyone-but-me
published: 2026-08-26T18:00:00.515+00:00
updated: 2026-08-26T18:00:00.515+00:00
topic: breakage-by-platform
words: 1955
---

# My app is slow for everyone but me

If your app loads instantly for you and crawls for your users, you're both right — and the reasons are boring and fixable.

**In short:**

- You can't reproduce the slowness because your browser already has a copy of your app saved and your test account has almost no data in it.
- The most common cause is a database reading every row to find the handful that belong to one user.
- Open your app in a private window, on your phone, on mobile data — that removes your saved copy, your fast connection and your closeness to the server all at once.
- Slow is often the early stage of down, and hearing about it from a user is the worst way to find out.

### Why is my app slow for other people but fast for me?

Almost always three things stacked together: your browser already saved a copy of the app, your own account has very little data in it, and you're closer to the server on a better connection. Your users arrive cold, with months of records, from further away, often on a phone.

You open your app. It loads instantly. You click around. Everything is fine.

Then someone messages you: "is it just me or is this really slow?" Then another person says the same thing. You check again on your laptop, and it's still fine.

You are not imagining it and neither are they. Your app genuinely is fast for you and genuinely is slow for them. Here are the reasons, roughly in the order they turn out to be the cause.

## Have I already downloaded my own app?

The first time anyone opens your app, their browser has to fetch everything — the code, the fonts, the images, all of it. After that it keeps a copy so it doesn't have to fetch it again.

You have opened your app several hundred times, so you have the copy. Your users are having the first-time experience over and over, because most of them show up once a week and their browser has thrown the copy away by then.

That's why "let me just check again" never reproduces it. You are the one person on earth not experiencing it. Open a private or incognito window instead. If it's noticeably slower there, you've found part of your answer.

## Why does my database get slower as more people use my app?

When you were building, your app had a handful of test records. Anything is fast with a handful of records — the database can look at all of them and finish before you notice.

Now real people have been using it for months and that same list is thirty thousand rows. When someone loads their dashboard, the database reads every row and checks each one to see if it's theirs, because nobody ever told it there was a faster way.

The faster way is a lookup shortcut on the column you search by — called an index, which is just a pre-sorted list the database keeps so it can jump straight to the right rows. Supabase's own troubleshooting guide says indexes can speed up reads and in some cases improve performance by around a hundred times[^1]. It also warns against adding them everywhere, because they make writing data slightly slower, so it's a trade-off.

You don't feel it because your account is new and your data set is small. The user with two years of history is the one waiting. Supabase's query optimization guide[^2] is a reasonable starting point: find the column your app filters by most — usually the one saying which user a row belongs to — and add the shortcut there first.

## Did it get slow right after I added logins?

If your app has logins, there's a layer deciding which rows each person is allowed to see. It's the thing keeping user A out of user B's data, and you almost certainly want it.

But those rules get evaluated for every row the database looks at. If the rule itself does something slow, and it does that slow thing forty thousand times per page load, you get an app that was fine in testing and treacle in production.

If things got noticeably worse around the time you added logins, or sharing, or anything about permissions, that's where I'd look first.

## Is my app asleep when nobody is using it?

A lot of the places these apps get deployed put things to sleep when nobody is using them. The next person to arrive pays for waking it up, which can be several seconds of nothing happening.

You never see this because you're on the app all day. Your users see it constantly, because they arrive one at a time with hours in between.

The tell: it's slow the first time and fine the second, and the person reporting it says "it's fine now" by the time you reply.

## Does distance and phone data really make that much difference?

Your app lives on a machine somewhere and you might be near it. Your users in another country are not, and every single thing the app fetches makes that round trip.

Add a phone on mobile data and it gets worse in a way that's hard to picture from a desk. If everyone complaining is in one country, or everyone complaining is on a phone, that isn't coincidence — that's the diagnosis.

There's a related habit in a lot of AI-built apps: they fetch all their data first, then draw the page. So the user stares at a spinner for as long as the slowest single piece takes. Showing the page immediately and filling in the slow parts as they arrive doesn't make the app faster, but it makes it feel far faster — which is the thing people are actually complaining about.

## How do I work out which one it is?

1. **Ask four questions** — What page, what time, phone or laptop, and roughly where in the world. Two or three answers and the pattern usually names itself.
2. **Test the way a user does** — Open your app in a private window on your phone, on mobile data rather than your wifi. That removes your saved copy, your fast connection and your closeness to the server in one go.
3. **Read the slow request list** — Most database dashboards have a report of the requests taking longest. The top item is usually the whole problem.
4. **Go back to your AI tool with specifics** — "My app is slow" gets you a shrug. Naming the table, the column and the row count gets you a fix.

**Paste this into your AI tool**

```text
The dashboard page runs a query that filters the orders table by user_id. That table now has about 30,000 rows and there is no index on user_id. Add one, show me the change you made, and tell me if any other query on this page reads the whole table.
```

## Is slow a warning that my app is about to break?

Often, yes. A database straining under queries that read every row doesn't stay slow politely. It reaches its limits and starts refusing requests, and then your users get a broken page instead of a slow one.

Which is why the awkward part of all this isn't the fixing. It's that you found out from a message. Someone had a bad experience, decided it was worth telling you, and told you. Most people don't do the last part — they just leave.

## What can watch my app so users aren't the ones telling me?

There's a whole category of tools that open your app on a schedule and tell you when it stops responding properly. Worth being straight about the options.

UptimeRobot and Better Stack are where most people land, and both are genuinely capable. They check from lots of countries, keep long histories, and let you build detailed rules about what counts as broken and who gets told. If you want to compare response times from six regions on a chart, they're better at that. The catch is who they were built for: setting one up asks what to check, how often, and which server replies count as failures — questions that assume you already speak the language.

Fomio is the same idea built for the other person. You paste your app's link and it works out what to watch, checking from outside. It reports one of three things: Working, Having trouble, or Down. That middle one is the state this article is about — your app is answering, but badly.

*Watching tools compared, in plain language*

| Tool | Who it was built for | What setting it up asks of you | What it tells you when something breaks |
| --- | --- | --- | --- |
| UptimeRobot | Engineers and technical teams | What to check, how often, which server replies count as failures | Technical alerts, with long history and many places to check from |
| Better Stack | Engineers and technical teams | Detailed rules about what counts as broken and who gets told | Rich technical detail and regional charts |
| Fomio | People who built an app with an AI tool | A link. There is nothing to configure. | Working, Having trouble or Down, plus plain-English likely causes — and on paid plans a prompt to paste into the tool you built with |

> **What "Having trouble" means** — Your app is still answering, just badly or inconsistently — exactly the thing your users message you about and you can never reproduce.

The free plan watches one app, checks every five minutes, emails you when it breaks, and keeps a week of event history. No card. Builder covers three apps, checks every minute, and includes those fix prompts. Pro covers fifteen apps, keeps a year of history, and gives you a status page your users can look at instead of messaging you. Current prices are on fomio.ai/pricing.

## What should I do this week?

Open your app in a private window on your phone, on mobile data. Then look at the slow request list in your database dashboard and add a lookup shortcut on whatever column the top query filters by. That one change fixes this for a lot of people.

Then put something in front of it that watches, so the next time your app goes quiet you hear it from a machine at 7am rather than a user at 7pm.

## Questions people also ask


### Why can't I reproduce the slowness my users report?

Because you're the least representative user you have. Your browser has already saved a copy of the app, so you skip the download everyone else pays for. Your test account usually has very few records, so database queries finish quickly for you. And you're often physically closer to the server, on wifi rather than mobile data. Open a private window on your phone, on mobile data, and you'll usually see what they see.

### How do I know if the problem is my database?

Look for the slow request report in your database dashboard — most of them have one. It lists the queries taking longest, and the top entry is often the whole problem. If that query filters a large table by something like a user ID, and there's no lookup shortcut on that column, you've found it. Supabase's own guide says adding one can improve read performance dramatically, sometimes by around a hundred times.

### Does slowness mean my app will go down?

Not always, but it's a common path. A database repeatedly reading whole tables uses more and more resource as your data grows. Eventually it hits a limit and starts refusing requests, and then users see a broken page instead of a slow one. Fixing the slow query now is usually cheaper than diagnosing an outage later, and it's the same fix either way.

### Should I pay for a watching tool or use a free one?

Start free. If you have one app and email is enough, a free plan that checks every few minutes will tell you about real outages. Paying gets you more apps watched, checks every minute, longer history, and with Fomio the prompts you paste into the tool you built with. If you need checks from many countries or detailed regional charts, the engineer-focused tools do that better.


## Sources

[^1]: Steps to improve query performance with indexes — Supabase Docs. https://supabase.com/docs/guides/troubleshooting/steps-to-improve-query-performance-with-indexes-q8PoC9
[^2]: Query Optimization — Supabase Docs. https://supabase.com/docs/guides/database/query-optimization