Como fixamos as funções Vercel na região de Tóquio para melhorar a velocidade percebida — eliminando a ida e volta pelo Pacífico

Resumo deste artigo

• A lentidão do dashboard era causada por "a função Vercel rodar nos EUA enquanto o banco de dados fica em Tóquio", gerando idas e voltas pelo Pacífico a cada requisição
• O cabeçalho de resposta x-vercel-id permite verificar em qual região a função foi executada
• Com o parâmetro regions no vercel.json fixando a região em Tóquio + paralelização das consultas, nossas medições internas mostraram redução de alguns segundos para cerca de 0,2 segundos

"A navegação entre telas do dashboard leva alguns segundos" — este é o registro de como investigamos essa lentidão percebida, identificamos a causa e a corrigimos. Em vez de suposições, isolamos o problema com medições reais.

Sintoma e isolamento do problema

A transição de tela levava cerca de 3 segundos. Primeiro, verificamos se o gargalo estava no "tempo de resposta inicial do servidor (TTFB)" ou na "obtenção do conteúdo em si", e descobrimos que a resposta inicial era rápida — a lentidão estava na obtenção de dados dentro da página.

Cada consulta, isoladamente, era rápida no banco de dados, levando apenas alguns milissegundos. Mesmo assim, o processo como um todo era lento. Foi aí que suspeitamos do local de execução (região).

Causa nº 1: idas e voltas pelo Pacífico

Ao observar o cabeçalho de resposta x-vercel-id, vimos que a função estava sendo executada na região leste dos Estados Unidos (iad1). Enquanto isso, o banco de dados (Supabase) estava em Tóquio. Ou seja, a cada consulta, havia uma ida e volta entre Japão e Estados Unidos.

O cabeçalho aparece assim (exemplo ilustrativo):

x-vercel-id: hnd1::iad1   ← o ponto de entrada é Tóquio (hnd1), mas a execução ocorre nos EUA (iad1)

Com várias consultas, cada uma delas atravessava o Pacífico ida e volta, acumulando latência.

Causa nº 2: consultas aguardadas em série

Havia também outro problema: a tela inicial buscava várias agregações em série (uma de cada vez, em sequência). Isso fazia com que o atraso de cada ida e volta se acumulasse proporcionalmente ao número de consultas.

Medidas adotadas

Fixar a região em Tóquio

Adicionamos a especificação de região no vercel.json para que a função fosse executada em Tóquio (hnd1).

{ "regions": ["hnd1"] }

Com isso, o x-vercel-id passou a mostrar hnd1::hnd1, com a função e o banco de dados ambos em Tóquio. O atraso das idas e voltas foi eliminado.

Paralelização das consultas

Paralelizamos com Promise.all as buscas de agregação que antes eram aguardadas em série, e também consolidamos buscas duplicadas em uma única chamada.

Resultado

Em medições internas, o tempo de exibição da tela inicial caiu de alguns segundos para cerca de 0,2 segundos. O ponto principal é que o próprio processamento foi acelerado, sem depender de cache. Os dados exibidos continuam sempre atualizados.

Aprendizados

• Quando "as consultas são rápidas, mas a tela é lenta", não suspeite apenas da velocidade do banco de dados — verifique também a distância física entre a função e o banco de dados (região).
• O x-vercel-id é uma pista simples e poderosa para verificar em qual região a execução ocorreu.
• Em ambientes onde o custo de ida e volta é alto, aguardar chamadas em série pode ser fatal. O efeito da paralelização é significativo.

Conclusão

A verdadeira causa da lentidão percebida era a ida e volta entre os Estados Unidos e Tóquio. Com duas medidas — fixar a região e paralelizar as consultas — conseguimos melhorar significativamente a velocidade percebida, sem usar cache algum. Se você sentir que o SSR ou o dashboard está lento, comece verificando a relação entre a região de execução e a localização do banco de dados.