# Optimasi Performa Next.js SSR di Edge dengan Cloudflare Workers

> Diterbitkan oleh Literally Web ID pada 21 Oct 2026
> Sumber: https://literally.web.id/articles/optimasi-performa-nextjs-ssr-di-edge-dengan-cloudflare-workers

---

Pernahkah kamu berada di situasi jam dua pagi, ketika metric dashboard APM mendadak menyala merah menyala, dan bos mengirim pesan singkat: 'TTFB kita tembus 1.2 detik di Asia, klien ngamuk'? Itulah realita harian di ruang server modern. Saat kita membangun aplikasi web besar menggunakan Next.js SSR, tantangan terbesarnya bukan lagi seberapa keren animasi Tailwind atau seberapa bersih struktur komponen React kita. Tantangannya adalah geografi. Server Node.js kita mungkin nyaman mendekam di AWS us-east-1, tapi pengguna kita di Jakarta, Tokyo, atau Frankfurt harus menunggu paket data melintasi setengah bola dunia hanya untuk merender sebuah halaman profil. Di sinilah pertarungan arsitektur dimulai: apakah kita pasrah menyerahkan nasib pada *origin server* tradisional dengan Nginx dan PHP-FPM atau Node.js cluster di belakangnya, atau kita dorong seluruh logika SSR dan caching langsung ke *Edge Network* menggunakan Cloudflare Workers?

Mari kita bedah secara teliti pertarungan langsung antara pendekatan tradisional **Next.js SSR Origin (AWS/GCP)** melawan **Next.js Edge SSR di Cloudflare Workers**. Sebelum kita menyelami detail jeroannya, mari lihat matriks perbandingan performa kasarnya di lapangan:

| Parameter Evaluasi | Next.js SSR Origin (AWS/Node.js) | Next.js SSR di Cloudflare Workers | Catatan Lapangan |
| :--- | :---: | :---: | :--- |
| **Kecepatan TTFB (Global)** | 6/10 | 10/10 | Edge memangkas latensi jaringan secara radikal. |
| **Latency Konsistensi** | 5/10 | 9/10 | Bergantung pada lokasi user vs lokasi region server origin. |
| **Konsumsi RAM / Memori** | 4/10 | 9/10 | Model V8 isolates Cloudflare jauh lebih ringan ketimbang container Node.js penuh. |
| **Kemudahan Setup** | 8/10 | 5/10 | Konfigurasi runtime V8 Workers menuntut penyesuaian dependensi Node.js native. |
| **Ekosistem & Kompatibilitas** | 9/10 | 6/10 | Beberapa pustaka NPM yang bergantung pada Node.js API lama gagal berjalan di Workers. |

## 1. Pertarungan Filosofi: Dua Cara Pandang Berbeda dalam Memecahkan Masalah

Diskusi di ruang arsitek sering kali berujung pada perdebatan filosofis yang sengit. Di satu sisi, kubu **Next.js SSR Origin** berpendapat bahwa web server tradisional adalah rumah yang aman dan nyaman. Di sana, Node.js berjalan di atas Linux penuh, terkoneksi langsung ke database MySQL atau PostgreSQL via TCP, memanfaatkan Redis untuk caching lokal, dan menggunakan Nginx sebagai reverse proxy sekaligus pembatas SSL/TLS. Semuanya terasa familiar. Kamu bisa menggunakan pustaka NPM apa saja tanpa rasa cemas, melakukan *file system access*, dan memanggil modul *child_process* sesuka hati.

Namun, filosofi tersebut runtuh seketika saat traffic melonjak global. Mengandalkan satu atau dua region server origin berarti mengabaikan hukum fisika: kecepatan cahaya membatasi seberapa cepat paket TCP menyeberang dari Singapura ke London. Di sinilah kubu **Cloudflare Workers** masuk dengan membawa mazhab *Edge Computing*. Filosofinya radikal: 'Jangan bawa pengguna ke server, tapi bawa server ke dekat pengguna.' Melalui arsitektur V8 Isolates yang didistribusikan ke lebih dari 300 kota di seluruh dunia, kode SSR Next.js kamu dieksekusi beberapa kilometer saja dari browser pengguna. Tidak ada lagi mesin virtual yang harus dinyalakan, tidak ada lagi overhead sistem operasi Linux yang berat. Yang ada hanya fungsi JavaScript murni yang merespons instan.

Transisi dari kenyamanan monolitik server tradisional menuju dinamika terdistribusi edge ini menuntut perubahan cara pikir yang drastis, terutama saat tangan kita mulai menyentuh baris kode konfigurasi pertama.

## 2. Ronde 1: Ergonomi Menulis Kode & Pengalaman Konfigurasi Sehari-hari

Menulis aplikasi untuk server origin tradisional ibarat menulis skrip lokal yang kemudian di-deploy ke VPS Ubuntu menggunakan PM2 atau Docker Compose. Kamu mengatur Nginx sebagai *reverse proxy* yang meneruskan trafik ke port lokal tempat aplikasi Next.js berjalan.

Contoh konfigurasi Nginx yang biasa kita pasang di depan aplikasi SSR tradisional terlihat sangat familier:

```nginx
server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_cache_bypass $http_upgrade;
        
        # Standard timeout untuk SSR yang lambat
        proxy_read_timeout 60s;
    }
}
```

Konfigurasi di atas terbukti tangguh selama bertahun-tahun. Kamu tinggal menjalankan `npm run build && npm run start`, dan aplikasi siap melayani permintaan. 

Sebaliknya, ketika kita beralih ke Cloudflare Workers, aturan mainnya berubah total. Kamu tidak lagi berurusan dengan proses daemon atau file konfigurasi Nginx. Kamu menggunakan Wrangler CLI, alat baris perintah andalan Cloudflare, dan mendefinisikan *routing* serta *bindings* langsung di dalam file `wrangler.toml`.

```toml
name = "nextjs-edge-ssr"
main = ".open-next/worker.js"
compatibility_date = "2024-03-01"

[vars]
ENVIRONMENT = "production"

[[kv_namespaces]]
binding = "NEXT_CACHE_KV"
id = "your_cloudflare_kv_namespace_id"
```

> [!WARNING]
> Jangan coba-coba menggunakan modul Node.js bawaan seperti `fs`, `path`, atau pustaka database yang bergantung pada TCP socket mentah (seperti driver MySQL lama) di dalam Cloudflare Workers. Lingkungan V8 Isolates berbasis Edge tidak mendukung *Node.js core modules* secara penuh kecuali jika kamu mengaktifkan kompatibilitas khusus atau beralih ke HTTP-based driver (misalnya Neon, PlanetScale, atau Turso untuk SQL berbasis HTTP).

Perbedaan ergonomi ini langsung diuji ketika beban kerja yang sesungguhnya menghantam sistem di arena produksi.

## 3. Ronde 2: Uji Ketahanan di Bawah Gempuran Beban Ekstrem

Untuk melihat siapa yang bertahan, mari kita simulasikan pengujian beban menggunakan skrip `k6` dengan 5.000 *virtual users* (VUs) secara simultan, menembak endpoint halaman produk dinamis yang memerlukan pengambilan data (*fetch*) ke database eksternal.

Pada setup **Next.js SSR Origin (AWS EC2 t4g.medium di us-east-1)**, grafik metrik menunjukkan kurva yang mudah diprediksi. Begitu RPS (Request Per Second) melewati angka 1.200, utilisasi CPU Node.js melonjak hingga 95% karena proses serialisasi HTML React dan *hydration script*. Latensi rata-rata yang awalnya manis di angka 180ms meroket tajam melewati 900ms, dan beberapa koneksi mulai mencatat *Gateway Timeout (504)* akibat antrean worker proses.

Sebaliknya, saat pengujian yang sama diarahkan ke **Cloudflare Workers** yang menerapkan Edge Caching dan SSR Strategy, pemandangannya bagaikan arena balap F1. Karena sebagian besar permintaan yang dapat di-cache langsung disajikan dari memori cache global Cloudflare, dan proses SSR untuk halaman dinamis didistribusikan ke ratusan node secara paralel di seluruh dunia, CPU origin server kita nyaris tidak bergeming. Cloudflare menangani lonjakan jutaan *hits* tanpa keringat berlebih, menjaga latensi global rata-rata tetap di bawah 45ms.

Namun, kecepatan dan ketahanan luar biasa ini tentu saja memiliki implikasi langsung terhadap efisiensi biaya infrastruktur.

## 4. Ronde 3: Konsumsi Sumber Daya Server & Efisiensi Biaya Nyata

Mari kita bicara tentang bahasa yang paling dipahami oleh CFO perusahaan: lembar tagihan bulanan. 

Dengan arsitektur **Next.js SSR Origin**, kamu harus menyalakan instance server 24/7. Bahkan ketika jam 3 pagi di mana trafik web turun drastis hingga titik nadir, kamu tetap membayar biaya penuh untuk instance AWS EC2 atau Google Cloud Compute Engine tersebut. Jika mengantisipasi *traffic spike*, kamu terpaksa memasang Auto Scaling Group yang sering kali lambat bereaksi (*cold start* container baru) atau malah kelebihan kapasitas yang berujung pada pemborosan anggaran.

Di sisi lain, model *serverless* **Cloudflare Workers** menerapkan sistem *pay-as-you-go* yang sesungguhnya. Kamu hanya membayar berdasarkan jumlah eksekusi CPU milidetik dan penggunaan KV Storage. Tidak ada server yang menyala sia-sia di malam hari. Ditambah lagi, penghematan *bandwidth egress* sangat drastis karena Cloudflare menyerap jutaan permintaan statis dan cache langsung di edge, menyelamatkan tagihan *data transfer out* dari *origin server* utama kamu.

> [!TIP]
> Manfaatkan kombinasi Edge Middleware Strategy dan Cloudflare KV Storage untuk menyimpan hasil *render* SSR yang bersifat semi-statis. Dengan cara ini, kode SSR Next.js kamu tidak perlu menyentuh *origin database* sama sekali untuk 90% permintaan pembaca yang datang berulang.

Keputusan akhir tidak pernah hitam atau putih. Ada kalanya teknologi canggih justru menjadi bumerang jika diterapkan pada kasus yang salah.

## 5. Kapan Wajib Menggunakan Next.js SSR Origin (AWS/GCP)

Pilih pendekatan tradisional berbasis server origin jika aplikasi kamu memiliki karakteristik berikut:
- **Ketergantungan Berat pada Node.js Native API:** Aplikasi kamu menggunakan pustaka internal perusahaan yang masih mengandalkan modul `fs`, modul enkripsi native yang kompleks, atau operasi *streaming file* berukuran besar secara lokal.
- **Koneksi Database Langsung (TCP):** Kamu menggunakan koneksi pool database tradisional (seperti PostgreSQL via node-postgres) yang memerlukan koneksi persistent jangka panjang dan belum migrasi ke HTTP driver.
- **Tim yang Belum Familiar dengan Edge Constraints:** Jika tim engineering kamu masih beradaptasi dengan batasan V8 Isolates dan pembatasan memori eksekusi ketat di Edge, memaksa migrasi justru akan memperlambat siklus rilis produk.

## 6. Kapan Wajib Menggunakan Next.js SSR di Cloudflare Workers

Pilih pendekatan Cloudflare Workers jika bisnis dan produk kamu menuntut hal-hal berikut:
- **Audiens Global yang Tersebar Luas:** Pengguna aplikasi kamu berasal dari berbagai belahan dunia dan menuntut interaksi secepat kilat tanpa jeda latensi lintas benua.
- **Aplikasi yang Menghadapi Traffic Spike Tak Terduga:** Situs *e-commerce*, portal berita, atau *flash sale* yang sewaktu-waktu bisa diserang ratusan ribu pengunjung dalam detik yang sama.
- **Komitmen Efisiensi Biaya Operasional:** Ingin memangkas biaya infrastruktur bulanan secara masif dengan menghilangkan kebutuhan untuk menyalakan sekumpulan server origin besar-besaran secara 24/7.

## 7. Keputusan Akhir: Rekomendasi Jujur untuk Tim Engineering

Sebagai arsitek yang sudah kenyang asam garam menghadapi runtuhnya infrastruktur di tengah malam, penilaian saya jelas: **Next.js SSR di Cloudflare Workers adalah masa depan untuk performa web global, tapi bukan peluru perak universal.**

Jangan terburu-buru melakukan *rewrite* total kode lama kamu ke Edge jika aplikasi tersebut berjalan stabil dan target pasarnya hanya lokal (misalnya satu negara saja). Namun, jika kamu sedang merancang produk baru berskala besar, atau produk lama kamu mulai megap-megap menghadapi ekspansi internasional, mengadopsi OpenNext untuk mendeploy SSR Next.js ke Cloudflare Workers adalah investasi arsitektur terbaik yang akan menyelamatkan kewarasan tim DevOps sekaligus memuaskan para pengguna setiamu.