Penyebab TTFB Lambat dan Cara Mempercepat Respons Server

Time to First Byte (TTFB) adalah jeda antara browser meminta sebuah halaman dan saat byte pertama jawabannya tiba. Selama jeda itu layar pengunjung kosong. Tidak ada gambar, tidak ada teks, hanya ikon memuat yang berputar.

Angka ini menahan segalanya. Semua metrik lain, termasuk kapan konten utama tampil, baru bisa dimulai setelah byte pertama datang. Kalau TTFB sudah lambat, mengompres gambar atau memangkas JavaScript tidak akan menolong banyak. Salah mendiagnosis juga mahal: banyak orang langsung membeli server lebih besar, padahal masalahnya ada di halaman yang tidak pernah di-cache.

Apa saja yang dihitung dalam TTFB?

Menurut dokumentasi web.dev dari Google, TTFB adalah jumlah beberapa fase: waktu redirect, waktu memulai service worker (bila ada), pencarian DNS, pembuatan koneksi termasuk negosiasi TLS, lalu waktu permintaan sampai byte pertama respons diterima.

Artinya, TTFB bukan murni "kecepatan server". Domain dengan rantai redirect panjang, DNS yang lambat menjawab, atau pengunjung yang berada jauh dari server akan menambah angka ini walau aplikasinya sendiri cepat.

Sebagai patokan, web.dev menyebut TTFB 0,8 detik atau kurang tergolong baik, dan lebih dari 1,8 detik tergolong buruk. Di antaranya berarti perlu perbaikan. Patokan ini untuk navigasi halaman, bukan untuk setiap file kecil.

Penyebab TTFB lambat dan dampaknya

Berikut penyebab yang umum dijumpai pada website bisnis, dari sisi aplikasi sampai jaringan.

Halaman dibuat ulang di setiap kunjungan

CMS seperti WordPress menyusun halaman lewat PHP dan database setiap kali ada permintaan. Tanpa cache halaman, server mengerjakan ulang hal yang sama ratusan kali, padahal isinya tidak berubah. Pada website yang sebenarnya sederhana, inilah tersangka pertama yang perlu dicek.

Plugin atau kode aplikasi yang berat

Setiap plugin bisa menambahkan query, panggilan ke API luar, atau proses yang berjalan di setiap halaman. Satu plugin yang memanggil layanan eksternal secara sinkron bisa menahan seluruh respons sampai layanan itu menjawab.

Query database lambat

Tabel yang membengkak (misalnya log, revisi, atau data sesi), indeks yang tidak ada, dan query yang tidak efisien membuat server menunggu database. Gejalanya khas: halaman statis cepat, halaman dengan pencarian atau filter produk lambat.

Server kekurangan sumber daya atau berbagi terlalu ramai

Pada shared hosting, banyak website berbagi CPU dan memori yang sama. Saat tetangga ramai, permintaanmu ikut antre. Di VPS, gejala serupa muncul bila RAM habis dan sistem mulai memakai swap, atau jumlah worker PHP terlalu sedikit untuk trafik yang ada.

Jarak dan jaringan

Pengunjung di Indonesia yang mengakses server di benua lain menanggung waktu tempuh paket yang lebih panjang, ditambah beberapa kali bolak-balik untuk DNS, TCP, dan TLS. Penambahan ini terjadi sebelum aplikasi bekerja sama sekali.

Bagaimana cara mengukur TTFB dengan benar?

Ukur dari beberapa tempat dan beberapa kali, karena satu angka bisa menipu.

Cara paling cepat adalah DevTools di browser. Buka tab Network, muat ulang halaman, klik dokumen HTML pertama, lalu lihat bagian Timing. Angka "Waiting for server response" menunjukkan berapa lama server berpikir.

Dari terminal, curl bisa memisahkan tiap fase:

curl -o /dev/null -s -w "dns:%{time_namelookup} koneksi:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}\n" https://domainmu.com/

Kalau ttfb jauh lebih besar dari tls, waktu terbuang di aplikasi atau server. Kalau dns dan koneksi sendiri sudah besar, masalahnya di jaringan atau jarak.

Bandingkan juga halaman yang sudah di-cache dengan yang belum, misalnya dengan menambahkan parameter acak di URL. Selisih besar di antara keduanya menunjukkan cache bekerja, dan halaman tanpa cache perlu dibenahi.

Urutan perbaikan, dari yang paling berdampak

Kerjakan berurutan dan ukur ulang setiap selesai satu langkah. Dengan begitu kamu tahu langkah mana yang benar-benar menolong.

1. Aktifkan cache halaman. Untuk website yang isinya jarang berubah, ini sering memangkas TTFB paling banyak, karena server cukup mengirim HTML yang sudah jadi.
2. Audit plugin dan kode. Nonaktifkan plugin satu per satu di salinan staging dan ukur. Plugin yang memanggil API luar di setiap halaman layak diganti atau diatur agar berjalan di latar belakang.
3. Rapikan database. Hapus revisi dan data sementara yang menumpuk, tambahkan indeks pada kolom yang sering dicari, dan pertimbangkan cache objek seperti Redis untuk hasil query yang berulang.
4. Perbarui runtime. Versi PHP atau runtime lain yang lebih baru umumnya lebih efisien. Pastikan juga OPcache aktif untuk PHP.
5. Sesuaikan server. Atur jumlah worker sesuai RAM, pantau apakah swap terpakai, dan pilih web server yang cocok. Perbandingannya ada di Nginx vs Apache vs LiteSpeed.
6. Dekatkan ke pengunjung. Pilih lokasi server yang dekat dengan mayoritas pengunjung, dan pakai CDN yang bisa menyimpan cache halaman di lokasi tepi.
7. Pangkas redirect. Pastikan link internal dan iklan langsung menuju URL akhir (misalnya versi https dengan atau tanpa www, pilih salah satu).

Kapan cukup dioptimasi, kapan perlu pindah server?

Optimasi aplikasi masih menjadi pilihan utama bila TTFB tinggi bahkan saat trafik sepi. Itu tanda pekerjaan per permintaan terlalu berat, dan server sebesar apa pun hanya akan menutupi gejala sementara. Cache, audit plugin, dan perbaikan query biasanya cukup untuk website profil dan blog.

Pindah atau menambah kapasitas server masuk akal bila TTFB normal saat sepi tetapi melonjak setiap jam ramai, bila RAM terus penuh walau aplikasi sudah dirapikan, atau bila kamu berada di shared hosting dan tidak bisa mengatur cache maupun worker sendiri. Pada kondisi itu, VPS dengan sumber daya khusus memberi ruang untuk mengatur semuanya. Panduan memilih ukurannya ada di memilih spesifikasi VPS.

Lokasi juga bisa menjadi alasan pindah. Bila hampir semua pelanggan ada di Indonesia, server di luar negeri menambah waktu tempuh yang tidak bisa dihapus oleh optimasi apa pun selain CDN.

Mengapa semua ini penting untuk bisnis dibahas di kecepatan website dan penjualan.