Wie wir Vercel-Funktionen auf die Tokio-Region festgelegt und die gefühlte Geschwindigkeit verbessert haben — das Ende der Pazifik-Roundtrips

Zusammenfassung dieses Artikels

• Die Ursache für das langsame Dashboard: Die Vercel-Funktion lief in den USA, die Datenbank in Tokio — bei jeder Anfrage wurde der Pazifik überquert.
• Über den Response-Header x-vercel-id lässt sich nachvollziehen, in welcher Region eine Funktion ausgeführt wurde.
• Mit regions in vercel.json fest auf Tokio gesetzt und die Abfragen parallelisiert, sank die interne Messung von mehreren Sekunden auf rund 0,2 Sekunden.

„Der Seitenwechsel im Dashboard dauert mehrere Sekunden" — dieses gefühlte Ruckeln haben wir untersucht, die Ursache identifiziert und behoben. Nicht durch Vermutungen, sondern durch tatsächliche Messungen.

Symptom und Eingrenzung

Der Seitenwechsel dauerte rund 3 Sekunden. Wir haben zunächst geprüft, ob der langsame Teil der „erste Serverstart" (TTFB) oder der „Datenabruf" war. Der Start war schnell — der Datenabruf innerhalb der Seite war der Flaschenhals.

Jede einzelne Abfrage war in der Datenbank selbst mit wenigen Millisekunden sehr schnell. Trotzdem war die Gesamtzeit lang. Der Verdacht fiel auf den Ausführungsort (die Region).

Ursache 1: Ein Roundtrip über den Pazifik

Ein Blick auf den Response-Header x-vercel-id zeigte: Die Funktion lief in der US-Ost-Region (iad1). Die Datenbank (Supabase) lag dagegen in Tokio. Bei jeder Abfrage entstand also ein Hin- und Rückweg zwischen Japan und den USA.

So sieht der Header aus (Beispiel):

x-vercel-id: hnd1::iad1   ← Eingang in Tokio (hnd1), Ausführung aber in den USA (iad1)

Bei mehreren Abfragen summiert sich diese Pazifiküberquerung jedes Mal und die Latenz addiert sich.

Ursache 2: Abfragen wurden nacheinander abgewartet

Ein zweiter Punkt: Die Startseite holte mehrere Aggregationen seriell (eine nach der anderen) ab. Die Verzögerung durch den Roundtrip summierte sich dadurch mit jeder weiteren Abfrage.

Maßnahmen

Region fest auf Tokio setzen

Wir haben in vercel.json eine Regionsangabe ergänzt, damit die Funktion in Tokio (hnd1) ausgeführt wird.

{ "regions": ["hnd1"] }

Damit zeigt x-vercel-id nun hnd1::hnd1 — sowohl Funktion als auch Datenbank liegen in Tokio. Die Verzögerung durch den Roundtrip war damit behoben.

Abfragen parallelisieren

Die zuvor seriell abgewarteten Aggregationsabrufe haben wir mit Promise.all parallelisiert und zusätzlich doppelte Abrufe zu einem zusammengefasst.

Ergebnis

Bei internen Messungen sank die Ladezeit der Startseite von mehreren Sekunden auf rund 0,2 Sekunden. Der entscheidende Punkt: Wir haben den Vorgang selbst beschleunigt, ohne uns auf Caching zu verlassen. Die angezeigten Daten bleiben dadurch stets aktuell.

Erkenntnisse

• Wenn „die Abfrage schnell ist, aber die Seite langsam" — dann nicht nur die Datenbankgeschwindigkeit, sondern auch die physische Distanz zwischen Funktion und Datenbank (Region) in Betracht ziehen.
• x-vercel-id ist ein einfacher und aussagekräftiger Hinweis, um die Ausführungsregion zu überprüfen.
• In Umgebungen mit hohen Roundtrip-Kosten wird serielles Warten schnell zum Problem. Die Wirkung von Parallelisierung ist entsprechend groß.

Fazit

Die Ursache der gefühlten Langsamkeit war der Roundtrip zwischen den USA und Tokio. Mit zwei Maßnahmen — fester Region und Parallelisierung — konnten wir die gefühlte Geschwindigkeit deutlich verbessern, ganz ohne Caching. Wenn sich SSR oder ein Dashboard langsam anfühlen, lohnt es sich, zuerst die Ausführungsregion und die Lage der Datenbank zu überprüfen.