Kenapa Static Site Punya TTFB Tercepat: Anatomi CF Pages

Time to First Byte (TTFB) lambat seringkali menjadi pembunuh senyap konversi website lo. Untuk performa dan SEO yang maksimal, kombinasi static site generator (SSG) dan infrastruktur edge seperti Cloudflare Pages adalah solusi paling efisien.

Mengapa TTFB Penting untuk SEO & AEO?

TTFB mengukur seberapa cepat server merespons request pertama dari browser. TTFB memang bukan salah satu metrik Core Web Vitals (yang masuk hitungan adalah LCP, INP, dan CLS), tapi dia fondasi semuanya: browser gak bisa mulai render apa pun sebelum byte pertama datang, jadi TTFB yang lambat hampir pasti bikin LCP ikut jelek. Dalam konteks AI Search Engine Optimization (AEO), bot seperti GPTBot atau ClaudeBot memiliki crawl budget dan batas waktu eksekusi. Server yang lelet merespons akan sering di-skip, membuat konten lo gagal masuk ke dataset mereka.

Berapa TTFB yang Dianggap Sehat?

Patokan dari web.dev: TTFB di bawah 0,8 detik masuk kategori baik, 0,8 sampai 1,8 detik perlu perbaikan, dan di atas 1,8 detik buruk. Angka ini diukur di persentil ke-75 pengunjung nyata, bukan dari laptop lo yang koneksinya kencang. Website statis di edge biasanya ada di kisaran puluhan sampai 200 milidetik, jauh di bawah batas aman.

Anatomi Server-Side Rendering (SSR) vs Static Sites

Pada arsitektur tradisional atau Server-Side Rendering (seperti WordPress atau Next.js SSR), setiap request memicu:

• Eksekusi runtime language (PHP/Node.js).
• Query ke database (MySQL/PostgreSQL).
• Kompilasi template HTML.

Ini memakan waktu ratusan milidetik. Sebaliknya, Static Site Generator (SSG) seperti Astro, Hugo, atau Eleventy menggeser beban kompilasi ke fase build time. Hasilnya adalah deretan file HTML, CSS, dan JS murni yang siap disajikan instan.

Edge Caching: Senjata Rahasia Cloudflare Pages

File HTML statis memang cepat, tapi jika servernya di Amerika dan pengunjung di Indonesia, latency fisik tetap menjadi masalah. Di sinilah peran Edge Computing seperti Cloudflare Pages.

• Distribusi Global: File website didistribusikan ke ratusan data center di seluruh dunia.
• Routing Terdekat: Pengunjung di Jakarta akan mengambil file HTML dari server Cloudflare di Jakarta, memangkas latency lintas benua.
• Zero Cold Start: Tidak seperti serverless functions yang perlu "bangun" saat ada request, file statis di edge network selalu siap 24/7.

Skenario Praktis: Static HTML + Cloudflare Pages

Gua pakai pendekatan ini di wasian.my.id, bahkan tanpa framework sama sekali. Halaman utama, shop, dan direktori adalah file HTML, CSS, dan JS statis yang langsung disajikan dari edge. Untuk halaman artikel blog, gua pakai Cloudflare Pages Functions yang ringan: function membaca metadata dari file JSON dan potongan konten HTML, lalu merakit halaman lengkap di edge dengan header cache. Hasilnya tetap cepat karena gak ada database dan gak ada server origin yang harus dihubungi. Kalau lo butuh build step, static site generator seperti Astro, Hugo, atau Eleventy memberi hasil akhir yang sama: HTML siap saji.

// Contoh output SSG (HTML mentah)
<html>
  <head>
    <title>TTFB Tercepat</title>
  </head>
  <body>
    <h1>Konten Instan</h1>
  </body>
</html>

Jika lo mengelola direktori kompleks, pertimbangkan menggunakan format JSON sebagai sumber data statis, persis seperti yang gua terapkan pada struktur direktori remote work dengan 90+ platform.

Cara Ukur TTFB Website Lo

Jangan cuma percaya klaim, ukur sendiri. Tiga cara yang praktis:

• curl dari terminal: curl -o /dev/null -s -w "%{time_starttransfer}\n" https://domain-lo.com menampilkan waktu sampai byte pertama dalam detik.
• Chrome DevTools: buka tab Network, klik request dokumen, lalu lihat bagian Timing. Angka "Waiting for server response" itu TTFB lo.
• PageSpeed Insights: bagian data lapangan menampilkan TTFB dari pengunjung nyata (data Chrome UX Report), jadi lebih jujur daripada tes lokal.

Ukur dari beberapa lokasi. TTFB yang bagus dari Jakarta bisa jadi buruk dari Eropa kalau website lo cuma ada di satu server.

Kapan Static Site Gak Cukup

Static bukan jawaban untuk semua hal. Kalau konten lo berubah per pengguna (dashboard, keranjang belanja, data real-time), lo tetap butuh logika di server. Jalan tengahnya: bagian yang sama untuk semua orang tetap statis, sedangkan bagian dinamis dipindah ke edge function atau API terpisah yang dipanggil setelah halaman tampil. Dengan begitu TTFB halaman utama tetap rendah, dan bagian yang lambat gak menahan render.

Kesimpulan: Kapan Harus Pindah?

Jika website lo lebih banyak dibaca daripada ditulis (blog, company profile, direktori), migrasi ke static site adalah langkah logis. Lo memangkas biaya server, menghilangkan risiko database injection, dan mendapatkan performa maksimal di mata mesin pencari.