TTFB: Metrik Kecepatan yang Sering Dilewati Pemilik Website Bisnis

TL;DR: TTFB (Time To First Byte) adalah waktu dari saat pengunjung meminta halaman sampai byte pertama tiba dari server. Angka ini menentukan seberapa cepat halaman mulai tampil. Target wajar di bawah 800 ms. Penyebab TTFB lambat biasanya server jauh, query database berat, atau tidak ada cache. Memperbaikinya sering memberi efek lebih besar daripada mengecilkan gambar.

Dalam beberapa proyek website bisnis yang saya tangani, pola yang sama muncul berulang: pemilik sudah mengompres semua gambar, tetapi halaman tetap terasa lambat di detik-detik awal. Setelah diperiksa, masalahnya bukan di aset, melainkan di waktu tunggu pertama dari server. Pengunjung sudah menunggu lebih dari satu detik sebelum byte pertama datang, dan tidak ada optimasi gambar yang bisa menutupi jeda itu.

TTFB adalah metrik yang jarang dilirik karena tidak terlihat secara visual. Tidak ada elemen yang "berkedip" saat TTFB buruk. Yang terasa hanya kesan situs lemot, yang sering salah didiagnosis sebagai masalah desain atau hosting murahan secara umum.

Apa yang Sebenarnya Diukur TTFB

TTFB menghitung waktu dari permintaan halaman dikirim hingga byte pertama respons diterima browser. Di dalamnya termasuk waktu DNS, koneksi, proses di server, dan pengiriman awal. Metrik ini menjadi fondasi bagi Core Web Vitals, karena jika byte pertama saja sudah lambat, semua metrik visual setelahnya ikut mundur.

Penjelasan teknis yang baik soal komponen TTFB ada di dokumentasi web.dev tentang TTFB, yang membaginya menjadi beberapa fase yang bisa diukur terpisah.

Penyebab Umum TTFB Lambat

Urutan ini penting. Memindahkan server lebih dekat ke pengguna lewat TTFB yang lebih kecil sering memberi perbaikan paling cepat tanpa menyentuh kode aplikasi.

Contoh dari Lapangan

Saat membangun halaman untuk Nalesha, toko parfum yang trafiknya didominasi pengunjung mobile, byte pertama awalnya tiba sekitar 1,2 detik karena halaman dibangun ulang setiap permintaan. Setelah halaman produk diubah ke pembuatan statis dengan revalidasi berkala, byte pertama turun ke kisaran ratusan milidetik. Persepsi kecepatan langsung berubah, padahal ukuran gambar tidak diubah sama sekali.

Pelajaran yang saya bawa dari proyek itu: optimasi paling berdampak sering berada di lapisan yang tidak terlihat, bukan di hal yang paling kasat mata seperti gambar besar.

Pertanyaan Umum

Berapa TTFB yang dianggap baik?

Sebagai patokan umum, di bawah 800 ms tergolong baik dan di bawah 200 ms sangat baik. Angka di atas 1,8 detik biasanya perlu segera diperiksa.

Apakah memperbaiki TTFB lebih penting daripada mengompres gambar?

Keduanya penting, tetapi jika TTFB sudah di atas satu detik, memperbaikinya umumnya memberi dampak lebih besar pada persepsi kecepatan dibanding mengompres gambar lebih lanjut.

Apakah CDN selalu menurunkan TTFB?

Tidak selalu untuk konten dinamis, tetapi sangat membantu untuk konten statis dan pengunjung yang tersebar secara geografis, karena server respons berada lebih dekat dengan pengguna.

Mulai dari Lapisan yang Tak Terlihat

Sebelum menambah animasi atau mengganti tema, periksa dulu berapa lama server Anda mengirim byte pertama. Sering kali perbaikan terbesar justru ada di sana, di bagian yang tidak terlihat tetapi paling terasa.