Performance
Response Time & Cold Starts
Slow response times drive users away - and free hosting tiers put your server to sleep, causing 10-30 second cold starts.
high severityWhat is this?
Response time is how long your server takes to send back the first byte of a response. Two different problems can cause slowness:
- Cold starts: Free/hobby tiers of Railway, Render, and Fly.io spin down your app after 15-30 minutes of inactivity. The first request after idle wakes it up - typically taking 10-30 seconds. Subsequent requests are fast.
- Genuinely slow server: Slow database queries, heavy computations on the request path, or servers deployed in the wrong region.
Why it matters
- 53% of mobile users abandon a site that takes more than 3 seconds to load (Google research)
- Cold starts hit first-time visitors hardest - the worst possible impression for someone trying your app for the first time
- Google uses Core Web Vitals (including Time to First Byte) as a ranking factor
How to fix it
For cold starts:
- Upgrade to a paid plan on your hosting platform (always-on instances)
- Use an uptime monitoring service that pings your health endpoint every 5 minutes to keep it warm
For slow responses:
- Check your server's region - deploy in the same region as most of your users
- Profile slow database queries - add indexes for common query patterns
- Move heavy computations out of the request path into background jobs
- Add a CDN (Cloudflare) in front of your origin server
Providers & tools
| Platform | Always-on option |
|---|---|
| Railway | Hobby plan ($5/mo) - no sleep |
| Render | Starter plan ($7/mo) - no sleep |
| Fly.io | Paid machines - always running |
| Vercel | Serverless - no cold starts on paid; edge functions always fast |
Keep-alive ping services (free):
- BetterStack - uptimerobot.com - ping every 5 mins, free tier
- cron-job.org - HTTP cron job, free
- GitHub Actions - scheduled workflow that hits your health endpoint
Check if your domain has this issue