Cloudflare Pages Cold Start dari Jakarta: 8 Bulan Data

Saya host 4 site di Cloudflare Pages selama 8 bulan terakhir. Site mix: 2 SSG Astro statis (tidak ada function call), 2 SSR Astro dengan beberapa Cloudflare Worker function. Saya monitor cold start latency dari user real, bukan synthetic test.

Setup monitoring

Custom RUM (Real User Monitoring) sederhana via Performance API:

window.addEventListener('load', () => {
  const t = performance.getEntriesByType('navigation')[0];
  const data = {
    ttfb: t.responseStart - t.requestStart,
    dom: t.domContentLoadedEventStart - t.fetchStart,
    full: t.loadEventEnd - t.fetchStart,
    city: window.__city, // dari Cloudflare-IPCity header
  };
  fetch('/api/rum', {
    method: 'POST',
    body: JSON.stringify(data),
    keepalive: true,
  });
});

Data ke Postgres, query setiap bulan untuk analytics.

Hasil 8 bulan

TTFB median dari kota Indonesia (4 site rata-rata):

Kota	TTFB SSG	TTFB SSR + Worker
Jakarta	42ms	78ms
Bandung	47ms	89ms
Surabaya	54ms	96ms
Medan	67ms	142ms
Makassar	73ms	156ms

SSG halamannya cached di Cloudflare edge di JKT (Jakarta data center). Konsisten 40-50ms.

SSR + Worker invocation: latency bertambah ~30-60ms untuk function cold start. Worker yang sudah warm: ~5-10ms. Worker cold (after 5+ min idle): ~80-150ms.

Cold start frequency

Untuk site dengan traffic 500-1000 req/day: cold start hit ~15% requests. Cukup tinggi.

Untuk site dengan 5000+ req/day: cold start hit ~3%. Acceptable.

Cold start murni karena V8 isolate spin-up. Tidak ada container startup seperti AWS Lambda.

Apa yang slow di Cloudflare Pages?

1. Image dari R2 bucket: tanpa CF Image Resizing, image dari R2 punya TTFB 200-400ms karena tidak di edge cache by default. Solution: enable Resizing, atau cache aggressively dengan Cache-Control: max-age=31536000, immutable.

2. Worker dengan banyak await fetch(): setiap external fetch dari Worker tambah 50-100ms (depending on target server). Stack 3+ awaits = nyaris 500ms total.

3. Database query dari Worker: Cloudflare D1 bagus, tapi setiap query bertambah ~30ms dari Worker yang ada di JKT karena D1 instance hosting di US/EU. Untuk SMB Indonesia, lebih bagus pakai Postgres di Hetzner Singapore dengan latency 5ms dari JKT.

Verdict

CF Pages excellent untuk SSG. Best CDN performance untuk Indonesia setelah Vercel (yang juga punya JKT POP sejak Q1 2026).

Untuk SSR/Worker heavy:

• ✅ Worker idempotent dengan minimal external calls: fine.
• ⚠️ Worker dengan banyak DB queries: pakai cache aggressively.
• ❌ Worker yang butuh < 50ms p99 dari Medan/Makassar: SSR/Worker bukan match — pertimbangkan SSG dengan client-side fetch ke API regional.

Saya akan terus monitor. CF roadmap untuk 2026 ada Indonesia D1 region yang katanya akan reduce latency dari Worker → DB. Saya skeptis sampai lihat angka real.