Come abbiamo migliorato la velocità percepita fissando le funzioni Vercel sulla regione di Tokyo — eliminare l'andata e ritorno sul Pacifico

Riepilogo dell'articolo

• La lentezza della dashboard era causata dal fatto che "le funzioni Vercel erano negli Stati Uniti mentre il database era a Tokyo", generando un andata e ritorno sul Pacifico a ogni richiesta
• L'header di risposta x-vercel-id permette di verificare in quale regione è stata eseguita la funzione
• Fissando la regione su Tokyo tramite regions in vercel.json e parallelizzando le query, nei nostri test interni il tempo è passato da alcuni secondi a circa 0,2 secondi

"Il passaggio tra le schermate della dashboard richiede alcuni secondi" — ecco il resoconto di come abbiamo indagato su questa lentezza percepita, identificato la causa e risolto il problema. Non per ipotesi, ma isolando la causa con misurazioni reali.

Sintomi e isolamento del problema

Il passaggio tra le schermate richiedeva circa 3 secondi. Per prima cosa abbiamo verificato se il collo di bottiglia fosse "l'avvio del server (TTFB)" o "il recupero dei contenuti": l'avvio era veloce, mentre il recupero dei dati all'interno della pagina era lento.

Ogni singola query, sul database, era velocissima: pochi millisecondi. Eppure il processo complessivo era lento. A quel punto abbiamo sospettato del luogo di esecuzione (la regione).

Causa n. 1: un continuo andirivieni sul Pacifico

Osservando l'header di risposta x-vercel-id, abbiamo notato che la funzione veniva eseguita nella regione degli Stati Uniti orientali (iad1). Il database (Supabase), invece, si trova a Tokyo. In pratica, a ogni query si verificava un andata e ritorno tra Giappone e Stati Uniti.

Ecco un esempio di come appare l'header.

x-vercel-id: hnd1::iad1   ← il punto di ingresso è Tokyo (hnd1), ma l'esecuzione avviene negli Stati Uniti (iad1)

Con più query in sequenza, ogni volta si attraversava il Pacifico, e la latenza si accumulava.

Causa n. 2: le query venivano attese in serie

C'era anche un secondo problema: la schermata Home recuperava diverse aggregazioni in serie (una dopo l'altra). Il ritardo dell'andata e ritorno si sommava esattamente per il numero di richieste effettuate.

Le soluzioni adottate

Fissare la regione su Tokyo

Abbiamo aggiunto la specifica della regione in vercel.json, in modo che le funzioni venissero eseguite a Tokyo (hnd1).

{ "regions": ["hnd1"] }

Così x-vercel-id è diventato hnd1::hnd1, con funzioni e database entrambi a Tokyo. Il ritardo dell'andata e ritorno è scomparso.

Parallelizzare le query

Abbiamo parallelizzato con Promise.all le richieste di aggregazione che venivano attese in serie, unificando anche alcune chiamate duplicate in un'unica richiesta.

Risultati

Nei nostri test interni, il tempo di caricamento della schermata Home è passato da alcuni secondi a circa 0,2 secondi. Il punto chiave è che abbiamo reso più veloce il processo stesso, senza affidarci alla cache: i dati mostrati restano sempre aggiornati.

Lezioni imparate

• Quando "le query sono veloci ma la schermata è lenta", non bisogna sospettare solo della velocità del database, ma anche della distanza fisica tra funzione e database (la regione).
• x-vercel-id è un indizio semplice ma potente per verificare in quale regione viene eseguita la funzione.
• In un ambiente dove il costo dell'andata e ritorno è alto, l'attesa in serie diventa un problema critico. L'effetto della parallelizzazione è notevole.

Conclusione

La vera causa della lentezza percepita era l'andirivieni tra Stati Uniti e Tokyo. Con due interventi — fissare la regione e parallelizzare le query — siamo riusciti a migliorare notevolmente la velocità percepita senza ricorrere alla cache. Se anche voi notate lentezza nel rendering server-side o nella dashboard, vi consigliamo di controllare per primi la regione di esecuzione e la posizione del database.