Cerita Menetapkan Fungsi Vercel ke Region Tokyo untuk Meningkatkan Kecepatan — Mengatasi Bolak-balik Lintas Pasifik

Ringkasan artikel ini

• Penyebab dashboard lambat adalah "fungsi Vercel di Amerika Serikat, sementara database di Tokyo" sehingga setiap kali harus bolak-balik melintasi Pasifik
• Header respons x-vercel-id dapat digunakan untuk memeriksa di region mana eksekusi dijalankan
• Dengan menetapkan region Tokyo melalui regions di vercel.json dan memparalelkan query, pengukuran internal menunjukkan waktu turun dari beberapa detik menjadi sekitar 0,2 detik

"Perpindahan layar di dashboard membutuhkan waktu beberapa detik" — ini adalah catatan penyelidikan atas kelambatan yang terasa ini, sampai penyebabnya ditemukan dan diperbaiki. Bukan berdasarkan dugaan, melainkan dipisahkan berdasarkan pengukuran nyata.

Gejala dan Pemisahan Masalah

Perpindahan layar memakan waktu sekitar 3 detik. Pertama, kami memisahkan apakah yang lambat itu "respons awal server (TTFB)" atau "pengambilan isi data", dan ternyata respons awal cepat, sementara pengambilan data di dalam halaman yang lambat.

Setiap query itu sendiri sebenarnya sangat cepat, hanya beberapa milidetik di level database. Namun secara keseluruhan tetap lambat. Yang kemudian kami curigai adalah lokasi eksekusi (region).

Penyebab 1: Bolak-balik Melintasi Pasifik

Saat memeriksa header respons x-vercel-id, ternyata fungsi dijalankan di region Amerika Serikat bagian timur (iad1). Sementara itu, database (Supabase) berada di Tokyo. Artinya, setiap kali ada query, terjadi perjalanan bolak-balik antara Jepang dan Amerika Serikat.

Header-nya terlihat seperti ini (ilustrasi).

x-vercel-id: hnd1::iad1   ← Titik masuk di Tokyo (hnd1), tetapi eksekusi di Amerika Serikat (iad1)

Jika ada beberapa query, setiap kali terjadi perjalanan bolak-balik melintasi Pasifik, dan latensi pun menumpuk.

Penyebab 2: Query Dijalankan Secara Berurutan (Serial)

Ada satu hal lagi: halaman beranda mengambil beberapa data agregat secara serial (satu per satu berurutan). Akibatnya, delay bolak-balik tadi menumpuk persis sebanyak jumlah query yang dijalankan.

Langkah Perbaikan

Menetapkan Region ke Tokyo

Kami menambahkan penetapan region di vercel.json agar fungsi dijalankan di Tokyo (hnd1).

{ "regions": ["hnd1"] }

Dengan ini, x-vercel-id menjadi hnd1::hnd1, sehingga fungsi dan database sama-sama berada di Tokyo. Delay akibat perjalanan bolak-balik pun hilang.

Memparalelkan Query

Pengambilan data agregat yang sebelumnya menunggu secara serial diparalelkan menggunakan Promise.all, sekaligus menggabungkan pengambilan data yang sebelumnya duplikat menjadi satu.

Hasil

Berdasarkan pengukuran internal, waktu tampil halaman beranda berhasil dipersingkat dari beberapa detik menjadi sekitar 0,2 detik. Poin pentingnya adalah mempercepat proses itu sendiri tanpa mengandalkan cache. Data yang ditampilkan pun tetap selalu yang paling baru.

Pelajaran

• Ketika "query-nya cepat tapi tampilan layarnya lambat", jangan hanya curigai kecepatan database, tapi curigai juga jarak fisik antara fungsi dan database (region).
• x-vercel-id adalah petunjuk yang sederhana namun sangat berguna untuk memeriksa region eksekusi.
• Di lingkungan dengan biaya bolak-balik yang tinggi, proses menunggu secara serial bisa berakibat fatal. Paralelisasi memberikan dampak yang besar.

Kesimpulan

Penyebab sebenarnya dari kelambatan yang terasa adalah perjalanan bolak-balik antara Amerika Serikat dan Tokyo. Dengan dua langkah perbaikan yaitu penetapan region dan paralelisasi, kecepatan yang terasa berhasil ditingkatkan secara signifikan tanpa menggunakan cache sama sekali. Jika Anda merasa SSR atau dashboard Anda lambat, coba periksa dulu hubungan antara region eksekusi dan lokasi database Anda.