Cómo fijamos las funciones de Vercel en la región de Tokio para mejorar la velocidad percibida — eliminando el viaje de ida y vuelta por el Pacífico

Resumen de este artículo

• La lentitud del panel se debía a que "las funciones de Vercel estaban en EE. UU. mientras que la base de datos estaba en Tokio", lo que generaba un viaje de ida y vuelta por el Pacífico en cada solicitud
• El encabezado de respuesta x-vercel-id permite comprobar en qué región se ejecutó la función
• Con regions en vercel.json para fijar la región en Tokio y la paralelización de consultas, nuestras mediciones internas pasaron de varios segundos a cerca de 0.2 segundos

"La navegación entre pantallas del panel tarda varios segundos": este es el registro de cómo investigamos esta lentitud percibida, identificamos la causa y la solucionamos. No nos basamos en suposiciones, sino en mediciones reales.

Síntomas y diagnóstico

La transición de pantalla tardaba unos 3 segundos. Primero diferenciamos si el problema estaba en el "arranque del servidor (TTFB)" o en "la obtención del contenido", y descubrimos que el arranque era rápido, pero la obtención de datos dentro de la página era lenta.

Cada consulta individual era rápida en la base de datos, del orden de milisegundos. Aun así, el conjunto era lento. Ahí sospechamos del lugar de ejecución (la región).

Causa 1: el viaje de ida y vuelta por el Pacífico

Al revisar el encabezado de respuesta x-vercel-id, vimos que la función se ejecutaba en la región este de EE. UU. (iad1). Por otro lado, la base de datos (Supabase) estaba en Tokio. Es decir, cada consulta implicaba un viaje de ida y vuelta entre Japón y EE. UU.

El encabezado se veía así (a modo de ejemplo).

x-vercel-id: hnd1::iad1   ← el punto de entrada es Tokio (hnd1), pero la ejecución ocurre en EE. UU. (iad1)

Si había varias consultas, cada una añadía un viaje de ida y vuelta por el Pacífico, acumulando latencia.

Causa 2: las consultas se esperaban en serie

Además, la pantalla de inicio obtenía varios agregados en serie (uno tras otro). El retraso de cada viaje de ida y vuelta se acumulaba exactamente tantas veces como consultas había.

Medidas aplicadas

Fijar la región en Tokio

Añadimos la especificación de región en vercel.json para que las funciones se ejecutaran en Tokio (hnd1).

{ "regions": ["hnd1"] }

Con esto, x-vercel-id pasó a mostrar hnd1::hnd1, quedando tanto las funciones como la base de datos en Tokio. El retraso del viaje de ida y vuelta desapareció.

Paralelizar las consultas

Paralelizamos con Promise.all la obtención de agregados que antes se esperaba en serie, y de paso consolidamos en una sola las obtenciones duplicadas.

Resultado

Según nuestras mediciones internas, el tiempo de visualización de la pantalla de inicio se redujo de varios segundos a alrededor de 0.2 segundos. Lo importante es que aceleramos el propio procesamiento sin depender de caché. Los datos mostrados siguen siendo siempre los más recientes.

Aprendizajes

• Cuando "las consultas son rápidas pero la pantalla es lenta", hay que sospechar no solo de la velocidad de la base de datos, sino también de la distancia física entre la función y la base de datos (la región).
• x-vercel-id es una pista sencilla y muy útil para verificar en qué región se ejecutó una función.
• En entornos donde el costo del viaje de ida y vuelta es alto, esperar en serie resulta fatal. El efecto de la paralelización es considerable.

Conclusión

La verdadera causa de la lentitud percibida era el viaje de ida y vuelta entre EE. UU. y Tokio. Con dos medidas —fijar la región y paralelizar— logramos una mejora notable en la velocidad percibida sin recurrir a caché. Si sientes que el SSR o el panel van lentos, empieza por comprobar la relación entre la región de ejecución y la ubicación de la base de datos.