Where Your App Runs Decides How Fast It Feels: The One-Line Fix That Cut Our Load Times by Up to 84%

On a developer's laptop the database is a few milliseconds away, so every query is instant and nothing looks wrong. In production the same code runs in a data centre that the hosting platform chose for you, and the database sits wherever you created it. If those two are on different continents, each query pays the round trip, and a request that makes several queries pays it several times.

The arithmetic is unforgiving. At about 230 milliseconds per round trip between Washington and Mumbai, eight sequential queries cost about 1.8 seconds before any of your own code runs. Nothing in the code is slow and nothing shows in a code review. It shows only as a vague feeling that the app hesitates, which is why this is one of the most common reasons a well-built app feels worse than it should.

Vercel's documentation states that the default region for functions is Washington, D.C. (iad1). Your database has a region too, shown in its dashboard. If they differ, you have the problem.

You can see where a request was actually served with one command: request any page that does database work and read the response header called x-vercel-id. It has the form of two region codes joined by two colons. The first is the edge location that accepted the request, which is not the thing to fix. The second is the region the function ran in. A value of bom1 followed by iad1 means a user in India reached a nearby edge and was then sent to Washington. A value of bom1 followed by bom1 means the function ran in Mumbai, next to the data.

The region is a setting in the project's vercel.json file. Setting regions to bom1 (Mumbai) puts the functions in the same city as the database. Nothing in the application code changes, and it deploys like any other commit.

One practical warning: when you add this to an existing project, merge it into the file instead of replacing the file. Several of our apps also keep scheduled jobs in the same file for payment reconciliation and reminders, and overwriting it would have silently switched those jobs off with no error anywhere.

A page that does no database work gains nothing. One of our sign-in pages showed no change at all after the move, because it makes no queries; the gain showed up on the signed-in pages behind it. A static page needs no function in the first place, which is why this website is built fully static and pinned to Mumbai only as a precaution.

It also moves the problem rather than removing it if your users are spread across the world. The function should sit next to the database, because that is where the chatty traffic is. Users far from that region then pay one long trip for the whole page instead of eight for the queries. For a mostly Indian audience that is the right trade. For a global one the next step is read copies of the data or caching, which is a different project.

Latency only hurts this much because the queries run one after another. In one of our apps, working out who the signed-in person is cost six separate queries on every navigation, and one of them was a write. Moving the region helped, but the real fix was to collapse the per-request context into a single call to the database and to wrap that call in React's cache function so the layout and the page do not each pay for it.

The rule we now follow: independent reads go out together, never in sequence, and anything every page needs is fetched once per request. That is a code change, not a configuration change, and it compounds with the region fix: eight queries at 230 milliseconds is two seconds; one query at 10 milliseconds is nothing.

Actual speed and perceived speed are separate. A page that must wait for the server should show something shaped like itself immediately, a skeleton with the real layout, so a click lands on a screen that is already moving. A page that is fully static should not use one, because a loading boundary makes the page wait for the whole document before it appears. We learned that the hard way and wrote it up in what profiling our own site on a phone found and in why a website feels slow on mobile.

None of this needs a consultant to start. It needs the answers to a few questions.

Region choice, query design and monitoring are the unglamorous part of cloud and infrastructure work, and they are the part users feel. If you would like your own app checked, send us the address and we will tell you what we find, in writing.