Comment fixer les fonctions Vercel sur la région de Tokyo a amélioré la vitesse ressentie — la fin des allers-retours transpacifiques

Résumé de cet article

• La lenteur du tableau de bord venait du fait que « les fonctions Vercel étaient aux États-Unis, la base de données à Tokyo », entraînant un aller-retour transpacifique à chaque requête
• L'en-tête de réponse x-vercel-id permet de vérifier dans quelle région le code a été exécuté
• En fixant Tokyo via regions dans vercel.json et en parallélisant les requêtes, nos mesures internes sont passées de plusieurs secondes à environ 0,2 seconde

« La navigation dans le tableau de bord prend plusieurs secondes » — voici le récit de l'enquête menée pour identifier puis corriger cette lenteur ressentie. Nous avons isolé le problème par des mesures réelles, et non par des suppositions.

Symptôme et isolement du problème

La navigation prenait environ 3 secondes. Nous avons d'abord cherché à savoir si le problème venait du « démarrage du serveur » (TTFB) ou de la « récupération du contenu ». Le démarrage était rapide : c'est la récupération des données dans la page qui était lente.

Chaque requête, prise individuellement, était rapide au niveau de la base de données, de l'ordre de quelques millisecondes. Pourtant, l'ensemble restait lent. C'est là que nous avons soupçonné le lieu d'exécution (la région).

Cause n°1 : un aller-retour transpacifique à chaque fois

En observant l'en-tête de réponse x-vercel-id, nous avons constaté que la fonction s'exécutait dans la région Est des États-Unis (iad1). Or, la base de données (Supabase) se trouve à Tokyo. Autrement dit, chaque requête générait un aller-retour entre le Japon et les États-Unis.

Voici à quoi ressemble l'en-tête (à titre d'exemple) :

x-vercel-id: hnd1::iad1   ← le point d'entrée est à Tokyo (hnd1), mais l'exécution a lieu aux États-Unis (iad1)

Avec plusieurs requêtes, chacune génère un aller-retour transpacifique, et la latence s'accumule.

Cause n°2 : des requêtes attendues en série

Autre problème : l'écran d'accueil récupérait plusieurs agrégations en série (l'une après l'autre). Le délai de l'aller-retour se cumulait donc autant de fois qu'il y avait de requêtes.

Les mesures prises

Fixer la région sur Tokyo

Nous avons ajouté une spécification de région dans vercel.json afin que les fonctions s'exécutent à Tokyo (hnd1).

{ "regions": ["hnd1"] }

Résultat : x-vercel-id affiche désormais hnd1::hnd1, la fonction et la base de données se trouvant toutes deux à Tokyo. Le délai de l'aller-retour a disparu.

Paralléliser les requêtes

Nous avons parallélisé avec Promise.all la récupération des agrégations qui attendait auparavant en série, et fusionné en une seule les récupérations qui étaient dupliquées.

Résultat

Selon nos mesures internes, le temps d'affichage de l'écran d'accueil est passé de plusieurs secondes à environ 0,2 seconde. Le point important : nous avons accéléré le traitement lui-même, sans recourir au cache. Les données affichées restent donc toujours à jour.

Ce que nous en avons retenu

• Quand « les requêtes sont rapides mais l'écran est lent », il ne faut pas soupçonner uniquement la vitesse de la base de données, mais aussi la distance physique (la région) entre la fonction et la base de données.
• x-vercel-id est un indice simple et puissant pour vérifier la région d'exécution.
• Dans un environnement où le coût des allers-retours est élevé, l'attente en série devient critique. La parallélisation apporte un gain considérable.

En résumé

La véritable cause de cette lenteur ressentie était l'aller-retour entre les États-Unis et Tokyo. Deux mesures — fixer la région et paralléliser les requêtes — ont permis d'améliorer nettement la vitesse ressentie, sans recourir au cache. Si votre SSR ou votre tableau de bord vous semble lent, commencez par vérifier la relation entre la région d'exécution et l'emplacement de votre base de données.