My site took 1.76 seconds per page. Nothing was broken — the code was just an ocean away from the database.
This one is mine, on this site, the day before it went live on its own domain. I'm posting it because the whole premise here is that the failures are worth more than the wins, and it would be strange to ask that of everyone else and never do it myself.
I'm not a developer. I built this site by directing an AI assistant, and by the time it went live everything worked — pages loaded, accounts worked, nothing errored. It just felt heavy. So I timed it: 1.76 seconds for a page that should take a quarter of a second.
My first instinct was that something in the code was slow, and that instinct was completely wrong. The code was fine. What had happened is that the two halves of the site had ended up on different continents. The database — where all the posts and accounts live — sits in Ireland, because that's where I put it. The servers running the site had been placed in Washington by default, because that's what the hosting platform does when you don't say otherwise. Nobody chose that. It was just the default, and I didn't know there was a choice to make.
So every single page was crossing the Atlantic and back, several times over, because a page asks the database several separate questions before it can be drawn. The fix was a three-line configuration file naming Dublin instead. Same code, same database, nothing rewritten. Pages went from 1.76 seconds to about a quarter of a second.
The reason I think this is worth posting: no amount of asking an AI to 'make this page faster' would have found it, because nothing in the code was slow. And nothing ever showed up as an error. It looked like it was working, and it was working — just badly, in a way that only shows up if you actually measure.
Steps
- 1
Measure before you theorise
I only found this because I timed an actual page load on the live site. Nothing errored, nothing warned me. If I'd trusted 'it seems fine', it would still be there.
- 2
Ask where each half physically is, before touching the code
Two questions: where is the database hosted, and where is the site itself running. They come from different dashboards and they are easy to never compare. Mine said Ireland and Washington.
- 3
Check what the response itself tells you
Most hosting platforms stamp the location into the response headers. Running the command in the artifact below prints it. Mine said iad1, which is Washington — the database was eu-west-1, which is Ireland.
- 4
Move the code to the database, not the other way round
For me that meant a three-line configuration file naming Dublin. I moved the code because moving a live database means moving everyone's data, which is a much bigger and riskier operation.
- 5
Measure again, on the live site, and write down both numbers
1.76 seconds before, roughly a quarter of a second after. Writing both down is what stops you from quietly believing a fix worked when it did nothing.
THE CHECK — run this in a terminal, replacing the address with your own site:
curl -s -o /dev/null -w '%{time_total}s\n' https://yoursite.com/
curl -sI https://yoursite.com/ | grep -i 'x-vercel-id'
The first line prints how long a page actually takes. The second prints where it ran — 'iad1' is Washington, 'dub1' is Dublin, 'fra1' is Frankfurt, 'sfo1' is San Francisco. Compare that against wherever your database says it lives.
THE FIX — a file called vercel.json in the root of the project (this is the entire file):
{
"regions": ["dub1"]
}
Replace dub1 with whichever region matches your database. Then deploy and run the check again.
IF YOU DON'T WANT TO RUN COMMANDS — paste this to your AI assistant instead:
---
My site is deployed on [HOSTING PLATFORM] and my database is hosted on [DATABASE PROVIDER]. Pages take [X] seconds to load and I want to rule out one specific cause before looking at the code: that the servers running my site are in a different part of the world from my database.
Tell me: (1) exactly where in each dashboard I look to find which region each one is in, (2) how to read the region out of the response headers of my live site, and (3) if they don't match, what the smallest possible change is to move the code next to the database — I'd rather not move the database itself.
Don't change any of my code yet. I want to confirm the diagnosis first.
---Where this breaks
This only works if your readers are concentrated somewhere. Moving the code next to the database made the site faster for people in Europe and slightly slower for people in the United States — the distance didn't disappear, it moved onto a different leg of the journey. I picked Europe because that's where I expect most early readers. If that assumption turns out to be wrong, so is my fix, and I'll have to think about it properly rather than just pick a different city.
Running the site on my own laptop told me absolutely nothing about this. Locally the database was on the same machine, so the trip was free and everything felt instant. This entire class of problem is invisible until it's actually deployed somewhere, which is exactly when you've stopped looking for problems.
And it's not fully fixed. The very first page load after the site has been quiet for a while still takes about 1.8 seconds, because the server has to wake up before it can answer. That's a different problem with a different cause, this change did nothing for it, and I haven't solved it.
Did this work for you?
Sign in to report a result. This is the number everyone reads first.