Lighthouse in the 90s but still feels slow? Fixed with the Vercel region
My portfolio project is currently built on Next.js and Supabase, and it is deployed and managed through Vercel.
Over time I have worked on various optimizations I could do as a frontend developer, such as improving the Lighthouse score, SEO optimization, and image optimization. As a result, I got decent numbers: Performance 97, Accessibility 85, SEO 100.
Apart from the numbers, though, there was a loading delay that was hard to understand when the page loaded its question data on entry. Here is how I solved it by going beyond the code and changing an infrastructure setting (Region).
Why were the metrics good but the perceived speed slow?
Lighthouse mainly measures static resource loading and initial rendering performance, but the data loading speed that real users feel is also heavily affected by the physical distance between servers. The bottlenecks I faced came down to two things.
- Inefficient middleware: unnecessary multiple redirects on first entry
- Network latency: an inefficient route where data went around the globe and back
To fix this, I started checking things step by step.
1. Code-level optimization: checking the middleware
The first thing I suspected was middleware.ts. After analyzing it, I found that a conflict caused by duplicate middleware declarations and unnecessary conditional redirects were keeping a white screen up for a long time on initial load.
- Fix: I unified the redirect logic and optimized the conditions for running the middleware, which improved the entry speed as a first step.
- Related issue: Issue #16 - Loading delay on first visit to the site
2. Infrastructure-level optimization: changing the Vercel region setting
Even after optimizing the middleware, the underlying slowness in loading question data did not go away. I was taking a course to build Next.js experience outside work, and when a session on Vercel optimization covered the Region setting, I realized I might have missed something. When I checked, my project's infrastructure looked like this:
| Service | Configured region | Physical location |
|---|---|---|
| User | - | South Korea (KR) |
| Supabase (DB) | Northeast Asia (Seoul) | South Korea (Seoul) |
| Vercel (Server) | Washington, USA (sfo1) | US West (San Francisco) |
Data traveled [User (KR) → Vercel server (US) → Supabase (KR) → Vercel server (US) → User (KR)], crossing the Pacific twice just to fetch a single list of questions.
To fix this, I went to Functions -> Region in the Vercel settings, changed the Region from the default US region to Seoul, South Korea (icn1), and redeployed.
Result and reflections
Changing the Vercel setting by itself was not what solved everything. The key to this troubleshooting was matching the region across the infrastructure.
Luckily, my Supabase project had been created in the Seoul region from the start. If the database had been in the US and I had moved only Vercel to Korea, every DB call would still have had to cross the Pacific, and the performance gain would have been minimal.
Placing the serverless functions (Vercel) and the database (Supabase) physically close to each other was the key to this optimization.
After changing the infrastructure setting, without changing a single line of code, the API response time (TTFB) dropped noticeably, and I saw a dramatic change: the sluggishness when loading the question list was completely gone.
Until now, when I hit a performance problem, I habitually looked for the cause only inside the code and tried to improve the logic. This experience reminded me once again that infrastructure settings also have a decisive effect on performance.
- #Next.js
- #region
- #Supabase
- #Vercel
- #performance optimization
- #portfolio project
