Edge Functions untuk Website Bisnis Indonesia: Cara Pangkas Latency 100-300 ms Tanpa Server Tambahan di 2026

TL;DR: Edge Functions adalah eksekusi kode JavaScript ringan di lokasi geografis paling dekat pengguna, biasanya lewat platform seperti Vercel, Cloudflare Workers, atau Netlify Edge. Untuk pengguna Indonesia yang sebelumnya hit server Singapura, edge bisa pangkas latency 100-300 ms. Dampak pada LCP dan konversi nyata, tetapi tidak setiap kasus cocok dengan model edge.

Beberapa kali saya diminta audit website bisnis yang sudah pakai stack modern (Next.js, React, Vercel) tapi pengguna mobile masih merasa lambat. Investigasi pakai DevTools menunjukkan TTFB 600-900 ms karena origin server di Iowa atau Frankfurt, sementara pengguna di Jakarta. Migrasi ke Edge Functions sering jadi kunci. Tetapi ada kondisi di mana edge justru menambah kompleksitas tanpa manfaat.

Artikel ini membahas kapan Edge Functions worth it, bagaimana implementasinya untuk website bisnis berbasis Next.js, dan trade-off yang perlu Anda timbang sebelum migrasi.

Apa yang Membuat Edge Functions Beda dari Serverless Tradisional

Serverless lambda klasik (AWS Lambda, Google Cloud Functions) berjalan di region tertentu. Setiap request dari Indonesia masih harus ke region terdekat (biasanya Singapura ap-southeast-1). Round-trip ini memakan 30-80 ms hanya untuk network latency, ditambah cold start 200-1500 ms saat lambda belum hangat.

Edge Functions dijalankan oleh runtime yang lebih ringan (V8 isolates) dan terdistribusi ke ratusan lokasi global, termasuk Jakarta dan Singapura. Cold start nyaris tidak ada (di bawah 50 ms) karena tidak boot full Node container. Trade-off: API edge lebih terbatas, tidak punya akses native Node modules, dan eksekusinya dibatasi waktu pendek (50-200 ms tergantung platform).

Kapan Edge Worth It dan Kapan Tidak

Rule of thumb saya: kalau tugasnya bisa selesai dalam 50 ms dengan I/O minim ke origin, edge cocok. Kalau butuh akses database transaksional atau library berat, lebih baik tetap di serverless region. Untuk Next.js, ini diatur lewat export const runtime = 'edge' per route, jadi bisa dicampur dalam satu aplikasi.

Studi Kasus: Migrasi Auth Middleware ke Edge

Saat membangun ulang dashboard internal Atmo (LMS) di awal 2026, saya pindahkan middleware auth dari Vercel Serverless ke Edge. Sebelumnya setiap request authenticated user butuh 220-380 ms TTFB karena middleware harus boot lambda di Singapura. Setelah pindah edge, TTFB turun jadi 60-110 ms untuk pengguna Jakarta. Dampak pada LCP terasa di rute-rute non-cached: rata-rata turun dari 2,8 detik ke 2,1 detik.

Yang penting digarisbawahi, migrasi ini bukan berarti seluruh aplikasi pindah edge. Hanya middleware auth dan beberapa rewrite logic. Endpoint yang query database tetap di serverless biasa karena DB Postgres-nya di Singapura. Saya juga harus refactor sedikit karena library JWT yang dipakai sebelumnya bergantung pada Node Buffer, sementara edge runtime pakai Web Crypto API. Migrasi total memakan 4-6 jam termasuk testing.

Implementasi Praktis di Next.js 15

Untuk website bisnis berbasis Next.js, langkah konkret memulai dengan edge:

Pertama, identifikasi rute yang cocok. Mulai dari middleware (otomatis edge sejak Next.js 12), redirect rules, dan API route ringan. Hindari memindahkan rute yang berinteraksi dengan ORM seperti Prisma atau Drizzle kecuali pakai database edge-friendly seperti Neon, Turso, atau PlanetScale dengan HTTP API.

Kedua, ukur sebelum dan sesudah. Pakai Vercel Speed Insights atau Web Vitals API langsung. Fokus pada TTFB dan LCP, bukan hanya skor Lighthouse. Ketiga, monitor cold-path performance. Edge umumnya konsisten, tetapi log error rate karena debugging edge runtime lebih terbatas dibanding Node biasa.

Dokumentasi resmi Vercel Edge Runtime ada di Vercel Edge Functions. Cloudflare Workers, alternatif populer, didokumentasikan di Cloudflare Developers.

Pertanyaan Umum

Apakah Edge Functions lebih murah dari Serverless?

Umumnya ya, untuk traffic tinggi. Vercel dan Cloudflare biasanya menagih per CPU-time bukan per duration, dan limit gratisnya cukup besar. Tetapi untuk eksekusi pendek dengan traffic rendah, perbedaannya kecil.

Apakah edge cocok untuk e-commerce?

Cocok untuk middleware (auth, geo, A/B), tidak cocok untuk endpoint cart/checkout yang berat database. Pisahkan dengan jelas mana yang edge dan mana yang serverless.

Bagaimana dengan database?

Edge butuh database edge-friendly. Postgres tradisional bisa dipakai lewat Supabase atau Neon yang punya pooler kompatibel edge. Untuk transaksi berat, tetap arahkan ke serverless region terdekat.

Apakah edge cuma untuk JavaScript?

Mayoritas runtime edge hanya support JavaScript/TypeScript via V8 isolates. Beberapa platform mulai eksperimental dengan Wasm untuk Rust dan Go, tapi belum produksi-ready untuk kasus mainstream per 2026.

Penutup: Edge Bukan Silver Bullet

Edge Functions menyelesaikan masalah latency dan cold start untuk kasus spesifik, bukan semua. Pendekatan terbaik adalah hybrid: middleware dan API ringan di edge, logic berat di serverless region terdekat pengguna. Untuk audiens Indonesia, kombinasi edge global plus origin Singapura sudah memberi pengalaman yang sangat baik tanpa overengineering. Mulailah dengan satu route pilot, ukur sebelum-sesudah, baru perluas ke route lain.