Why Is My App Slow on the First Request but Fast After That?
6 min read
If your app takes three or five seconds to respond the first time you load it, then feels instant on every request after, you are almost certainly looking at a cold start. Your backend runs as serverless functions that go to sleep when nobody is using them, and the first request has to wake one up before it can answer. Nothing is broken. This is normal serverless behaviour, and it is worth understanding before real users hit it.
Why this happens
Most vibe-coded apps deploy to a serverless platform: Vercel, Netlify, AWS Lambda, Supabase Edge Functions, Cloudflare Workers. Instead of one server that stays on, your code runs as small functions that spin up on demand. When a function has not been called for a while, the platform shuts it down to save money. The next request has to start a fresh container, load your code, connect to the database, and only then respond. That cold start is the lag you feel. Once the function is warm, it stays ready for a few minutes, so every request after the first is fast.
The AI agent that built your app made a sensible default choice by deploying serverless. It never mentioned cold starts because you did not ask, and in the demo you were clicking constantly, so the function never got a chance to sleep. The gap only shows up when someone loads your app after a quiet hour.
How to check
- Leave your app alone for ten to fifteen minutes so the functions go cold.
- Open your browser's Network tab (right-click, Inspect, Network), then load the page.
- Look at the slowest request, usually an API or data call. If its time is several seconds and the Waiting (TTFB) portion is most of that, you are waiting on a cold start.
- Reload immediately. If the same request now takes a few hundred milliseconds, that confirms it: the first one paid the wake-up cost, the second hit a warm function.
If the first load is slow but the "waiting" time is small and the delay is in downloading files, that is a different problem. See why your app is fast on your laptop but slow for users.
The fix
- Decide if it even matters. A cold start on a low-traffic beta is often fine. Once you have steady users, functions stay warm on their own. Do not spend money solving a problem your traffic will solve for you.
- Trim what runs at startup. Heavy imports and large dependencies make cold starts slower. Remove packages you no longer use and avoid loading big libraries at the top of a function if only one path needs them.
- Reuse the database connection. Opening a new connection on every cold start is slow and can exhaust your database. Use a pooler (Supabase and most platforms offer one) and initialise the client outside the request handler so it is reused while the function stays warm.
- Turn on the platform's keep-warm option if the pain is real. Vercel has Fluid Compute and Functions that stay ready. AWS Lambda has Provisioned Concurrency. Cloudflare Workers barely cold-start at all. These cost money, so switch them on only after you confirm cold starts are hurting real users.
- Show something instant while you wait. A loading skeleton or spinner on first load makes a two-second wake-up feel intentional instead of broken.
The trap to avoid
Do not reach straight for a paid always-on server or provisioned concurrency the moment you see the lag. It is the most expensive fix and usually the wrong first move. Most founders confuse a cold start with a slow app and start optimising code that is already fast. Confirm the pattern first: slow once, fast after. If that is what you see, the function was simply asleep, and trimming startup work plus a decent loading state is often all beta needs.
Where this fits
Cold starts are a classic thing that looks fine in your own testing and then greets your first visitor with a frozen screen. Knowing whether your numbers are actually a problem is half the battle, so it helps to know how fast an app really needs to be for beta before you optimise anything. The free Readiness Report checks your real deployment for this pattern and tells you whether it is worth fixing yet. If you would rather have the changes made for you in priority order, that is what the Finishing Pass is for.