# Optimasi Performa Next.js SSR dengan Edge Caching Cloudflare

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

---

Pernahkah kamu mendapati dashboard aplikasi web yang dibangun dengan Next.js SSR terasa lambat merayap saat trafik melonjak, padahal server Node.js di belakang sudah megap-megap dengan utilisasi CPU 90%? Masalah klasik ini sering kali membuat tim *engineering* panik dan langsung memutuskan untuk *scale-up* instance AWS EC2 atau menambah RAM, padahal solusinya jauh lebih dekat ke pengguna: memanfaatkan jaringan *edge* Cloudflare untuk menahan beban sebelum menyentuh origin server.

Sebagai arsitek yang bertahun-tahun merawat infrastruktur skala jutaan *request per second*, saya melihat pola berulang di mana bottleneck bukan pada kode aplikasi itu sendiri, melainkan pada ketidaktahuan cara mensinkronkan Header Cache-Control Next.js dengan Cloudflare Page Rules atau Cache Rules. Mari kita bongkar tuntas strategi lapangannya.

## 1. Intisari Kilat: Fondasi dalam Sekali Lirik

> [!IMPORTANT]
> Edge caching bukan sekadar mengaktifkan tombol "Cache Everything" di dashboard Cloudflare. Jika salah konfigurasi, token otentikasi user bisa bocor ke publik atau *stale data* akan terus menerus disajikan.

Strategi caching yang solid untuk Next.js SSR melibatkan tiga lapis pertahanan:
1. **Browser Cache**: Menyimpan aset statis (`/_next/static/*`) selama 1 tahun penuh dengan immutable header.
2. **Cloudflare Edge Cache**: Menyimpan hasil render SSR halaman publik (seperti landing page atau blog) di POP (Point of Presence) terdekat dengan user.
3. **Incremental Static Regeneration (ISR)**: Menggabungkan keaktifan data SSR dengan kecepatan file statis.

Dari fondasi ini, mari kita tentukan kapan kita harus menggunakan pendekatan *Edge Caching* murni versus mekanisme alternatif lainnya.

## 2. Kompas Keputusan: Kapan Memilih Solusi Ini vs Alternatif Lain

Memilih strategi caching ibarat memilih resep obat; salah dosis, aplikasi bisa tumbang atau data berubah menjadi kacau. Gunakan pohon keputusan (decision tree) praktis berikut di lapangan:

- **Jika halaman memuat data yang sangat personal (dashboard, cart, profile)**:
  - *Pilih*: SSR murni tanpa Cloudflare Edge Cache (`Cache-Control: private, no-store`). Gunakan Redis di backend untuk *query caching* database MySQL/MariaDB.
  - *Hindari*: Mengaktifkan *Cache Everything* secara membabi buta karena akan membocorkan data privat antar pengguna.

- **Jika halaman bersifat publik dan jarang berubah (Landing Page, Blog, Docs)**:
  - *Pilih*: Cloudflare Cache Rules dengan S-Max-Age (`s-maxage=31536000, stale-while-revalidate=60`). Beban origin server akan turun hingga 99%.
  - *Hindari*: Pure SSR tanpa caching yang membuat CPU Node.js atau PHP-FPM bekerja keras merender ulang halaman yang sama jutaan kali.

- **Jika halaman butuh update berkala tanpa rebuild total seluruh situs**:
  - *Pilih*: Next.js ISR (Incremental Static Regeneration) yang dikombinasikan dengan Cloudflare Cache Tag purging via Webhook.
  - *Hindari*: SSG (Static Site Generation) murni jika jumlah halaman mencapai ratusan ribu, karena proses *build time* akan memakan waktu berjam-jam.

Setelah menentukan arah arsitektur yang tepat, mari kita bedah parameter teknis yang wajib dipasang pada konfigurasi server dan Cloudflare.

## 3. Contekan Konfigurasi & Parameter Paling Sering Dicari

Berikut adalah contekan parameter wajib yang sering dicari para engineer saat melakukan *tuning* performa Next.js di balik Cloudflare:

| Parameter / Header | Nilai Optimal | Kapan Dinyalakan | Kapan Dimatikan |
| :--- | :--- | :--- | :--- |
| `Cache-Control` (SSR) | `public, s-maxage=60, stale-while-revalidate=30` | Halaman publik yang butuh kesegaran data berkala | Halaman privat / transaksional |
| Cloudflare Cache Everything | ON (via Cache Rules / Page Rules) | Untuk bypass batasan ekstensi file default Cloudflare | Endpoint API dinamis atau webhook penerima pembayaran |
| `CDN-Cache-Control` | Mengontrol durasi khusus di Edge | Ketika durasi cache Edge ingin dibedakan dari Browser | Saat durasi cache harus seragam di semua tier |
| `stale-while-revalidate` | 60 - 86400 detik | Mencegah *cache stampede* saat data kedaluwarsa | Data finansial real-time yang tidak boleh meleset sedetik pun |

Implementasi pada kode Next.js (pada `getServerSideProps` atau App Router `fetch`):

```javascript
// Contoh pada Next.js App Router untuk mendaftarkan Edge Cache
export default async function Page() {
  const res = await fetch('https://api.domain.com/posts', {
    next: { revalidate: 60 }, // Set revalidate tiap 60 detik
  });
  const data = await res.json();

  return (
    <main>
      <h1>Daftar Artikel</h1>
      {/* Render data */}
    </main>
  );
}
```

Agar eksekusi harian semakin cepat di terminal, simpan beberapa perintah ajaib berikut.

## 4. Koleksi Mantra One-Line Siap Salin untuk Keseharian

> [!TIP]
> Gunakan cURL untuk memvalidasi apakah header cache Cloudflare sudah aktif (`CF-Cache-Status: HIT`) tanpa harus membuka browser.

Berikut adalah kumpulan one-liner terminal yang wajib ada di riwayat bash/zsh seorang infrastructure engineer:

```bash
# 1. Cek status cache Cloudflare pada URL tertentu
curl -I https://namadomain.com/blog/artikel-terbaru

# 2. Purge cache Cloudflare secara spesifik menggunakan API
curl -X POST "https://api.cloudflare.com/client/v4/zones/YOUR_ZONE_ID/purge_cache" \
     -H "Authorization: Bearer YOUR_API_TOKEN" \
     -H "Content-Type: application/json" \
     '{"files":["https://namadomain.com/blog/artikel-terbaru"]}'

# 3. Monitor log akses Nginx/Caddy untuk melihat lonjakan request origin
tail -f /var/log/nginx/access.log | grep -E "GET /blog" 

# 4. Tes performa latensi dan TTFB global menggunakanwrk
wrk -t12 -c400 -d30s https://namadomain.com/
```

Namun, sehebat apapun mantra di atas, satu kesalahan konfigurasi kecil dapat berujung pada bencana operasional di produksi.

## 5. Jalur Bahaya: Dosa Besar yang Wajib Dihindari di Produksi

> [!WARNING]
> Jangan pernah mencampur cookie otentikasi (seperti JWT atau session cookie) dengan halaman yang di-cache secara agresif di Cloudflare tanpa mengatur *Cache-Key* berdasarkan *Cookie*.

Berikut adalah deretan dosa besar yang sering dilakukan dan harus dihindari:
1. **Mengabaikan `Vary` Header**: Menyebabkan Cloudflare menyajikan cache halaman user A kepada user B yang kebetulan merequest URL yang sama.
2. **Lupa Menghapus Cache saat Deploy**: Membuat pengguna melihat versi aplikasi Next.js lama yang tidak sinkron dengan *chunk JavaScript* terbaru, berujung pada error *hydration failed*.
3. **Caching Halaman POST Request**: Cloudflare secara default hanya mencache request `GET` dan `HEAD`. Memaksa caching pada `POST` tanpa penyesuaian *Cache-Key* akan merusak alur pengiriman form data.

Dengan memahami pola edge caching ini, kamu tidak hanya menyelamatkan CPU server dari kepunahan dini, tapi juga memberikan pengalaman akses secepat kilat bagi jutaan pengunjung web.