Ketika sebuah website lambat, banyak orang langsung mengecilkan gambar atau menghapus beberapa plugin. Langkah itu memang kadang membantu, tetapi tidak selalu menyentuh sumber masalah. Jika browser membutuhkan waktu lama sebelum menerima byte pertama dari server, halaman akan terasa lambat bahkan sebelum gambar dan JavaScript mulai dimuat.
Waktu tunggu sebelum byte pertama itu disebut Time to First Byte atau TTFB. Sederhananya, TTFB adalah jeda antara permintaan dikirim browser dan respons awal diterima. Anggap saja seperti menelepon restoran: TTFB bukan waktu sampai makanan tiba di meja, melainkan berapa lama sampai seseorang mengangkat telepon dan mulai menjawab.
TTFB bukan satu-satunya ukuran kualitas website. Namun, ia menjadi fondasi bagi metrik setelahnya seperti First Contentful Paint dan Largest Contentful Paint. Jika respons awal terlambat, perbaikan di sisi gambar atau tampilan depan sering terasa kurang maksimal.
TTFB tinggi belum tentu berarti server harus diganti
Nilai TTFB yang tinggi bisa berasal dari beberapa lapisan. Permintaan mungkin menempuh jarak jaringan yang jauh, DNS lambat, koneksi ke server tertunda, proses PHP menunggu database, atau halaman dinamis tidak pernah mengambil manfaat dari cache.
Karena itu, menambah spesifikasi server tanpa mengetahui bottleneck dapat menjadi pemborosan. Server yang lebih besar tidak otomatis menyelesaikan query MySQL yang buruk, kode PHP yang memanggil layanan eksternal, atau konfigurasi cache yang tidak pernah terkena.
Dalam praktiknya, angka TTFB juga dipengaruhi lokasi pengunjung dan kondisi jaringan. Gunakan pengujian dari beberapa lokasi, lalu bandingkan dengan data pengguna nyata. Jangan mengambil kesimpulan hanya dari satu kali pengujian di laptop sendiri.
Pisahkan dulu: masalah jaringan atau masalah origin?
Istilah origin merujuk pada server utama yang menghasilkan respons website. CDN atau reverse proxy dapat menyajikan cache dari lokasi yang lebih dekat, tetapi ketika cache tidak tersedia, permintaan biasanya diteruskan ke origin.
Langkah awal yang berguna adalah membandingkan beberapa jenis URL:
- Halaman statis sederhana, misalnya file HTML kecil.
- Halaman dinamis yang diproses PHP.
- Halaman yang seharusnya sudah masuk cache.
- Endpoint admin atau API yang memang tidak boleh di-cache.
Jika file HTML sederhana cepat tetapi halaman PHP lambat, perhatian sebaiknya diarahkan ke aplikasi, PHP-FPM, atau database. Jika semuanya lambat, periksa jaringan, DNS, TLS, kapasitas server, dan lokasi data center lebih dulu.
Untuk pemeriksaan dasar, Anda bisa menggunakan DevTools browser, PageSpeed Insights, atau perintah seperti curl. Contoh berikut hanya untuk melihat waktu koneksi dan respons awal:
curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://contoh.com/Angka dari curl membantu diagnosis, tetapi bukan pengganti data pengguna nyata. Pengujian dari server yang lokasinya dekat dengan origin bisa menghasilkan angka yang berbeda dari pengalaman pengunjung di negara lain.
Periksa jalur PHP-FPM dan antrean proses
Pada website berbasis PHP, permintaan dinamis biasanya diteruskan ke PHP-FPM. Jika semua worker sedang sibuk, permintaan baru akan menunggu dalam antrean. Dari sisi pengunjung, gejalanya mirip seperti server yang lambat, padahal masalahnya adalah kapasitas proses yang tidak seimbang dengan pola trafik.
Periksa beberapa hal berikut:
- Apakah jumlah worker PHP-FPM terlalu sedikit?
- Apakah worker terlalu banyak sehingga RAM habis dan server mulai melakukan swap?
- Apakah ada lonjakan proses pada jam tertentu?
- Apakah log menunjukkan proses yang berjalan sangat lama?
- Apakah batas waktu PHP terlalu tinggi sehingga proses macet menumpuk?
Jangan sekadar menaikkan jumlah worker. Setiap worker membutuhkan memori. Konfigurasi yang terlalu agresif dapat membuat server kehabisan RAM dan justru memperlambat seluruh website.
Pastikan OPcache benar-benar aktif
OPcache menyimpan bytecode PHP yang sudah dikompilasi di memori. Dengan begitu, PHP tidak perlu membaca dan mengompilasi ulang file pada setiap permintaan. Dokumentasi PHP menjelaskan bahwa OPcache dirancang untuk mengurangi pekerjaan tersebut dan tersedia sebagai bagian dari instalasi PHP modern.
Masalah umum bukan hanya OPcache belum aktif, tetapi kapasitasnya terlalu kecil, terlalu banyak file tidak tertampung, atau perubahan kode tidak diterapkan sesuai strategi deployment. Periksa statusnya melalui alat monitoring atau fungsi diagnostik yang aman, bukan dengan menampilkan informasi konfigurasi ke publik.
Hindari menyalin konfigurasi dari server lain tanpa menguji kebutuhan aplikasi. Pengaturan seperti opcache.validate_timestamps dapat memengaruhi kapan perubahan file terdeteksi. Jika pemeriksaan timestamp dimatikan, proses deployment harus memiliki langkah untuk melakukan reset atau restart cache agar kode baru benar-benar digunakan.
Telusuri query database dan layanan eksternal
Halaman yang terlihat sederhana bisa menjalankan banyak pekerjaan di belakang layar: mengambil daftar produk, menghitung stok, memuat rekomendasi, memeriksa sesi, lalu memanggil API pembayaran atau layanan pengiriman.
Catat durasi setiap bagian, bukan hanya waktu total halaman. Aktifkan slow query log di lingkungan yang sesuai, periksa query yang melakukan pemindaian terlalu banyak baris, dan pastikan kolom yang sering dipakai untuk pencarian memiliki indeks yang tepat. Namun, indeks berlebihan juga menambah biaya saat data ditulis. Perubahan database sebaiknya diuji dengan pola trafik yang mendekati kondisi nyata.
Layanan eksternal juga perlu diberi batas waktu. API yang tidak merespons seharusnya tidak membuat pengunjung menunggu tanpa batas. Gunakan timeout, fallback, dan bila memungkinkan pindahkan pekerjaan yang tidak penting ke antrean latar belakang.
Gunakan cache untuk halaman yang memang layak disimpan
Cache halaman dapat menghindarkan server dari pekerjaan yang sama berulang kali. Untuk artikel, halaman kategori, atau landing page yang tidak berubah setiap detik, cache penuh di CDN atau reverse proxy sering lebih berdampak daripada sekadar menambah CPU.
Namun, jangan meng-cache halaman yang berisi data pribadi, keranjang belanja, atau respons yang bergantung pada sesi tanpa aturan yang jelas. Kesalahan cache bisa lebih serius daripada halaman lambat karena data satu pengguna berpotensi tampil kepada pengguna lain.
Mulailah dari halaman publik yang aman. Tetapkan durasi cache, aturan invalidasi setelah konten berubah, dan pengecualian untuk cookie atau parameter tertentu. Setelah itu, pantau rasio cache hit dan cache miss untuk memastikan fitur tersebut benar-benar bekerja.
Apa artinya bagi kita?
Target Core Web Vitals tetap penting, termasuk LCP, INP, dan CLS. Namun, TTFB sebaiknya dipakai sebagai petunjuk diagnosis, bukan satu-satunya nilai yang dikejar. Dokumentasi web.dev menyebut TTFB sebagai metrik dasar yang mendahului pengalaman pemuatan berikutnya, sementara penilaian Core Web Vitals melihat pengalaman pengguna secara lebih luas.
Urutan perbaikan yang masuk akal adalah:
- Ukur dari beberapa lokasi dan bandingkan halaman statis dengan halaman dinamis.
- Pastikan DNS, koneksi, TLS, dan lokasi server tidak menjadi hambatan.
- Periksa antrean PHP-FPM serta penggunaan CPU dan RAM.
- Pastikan OPcache aktif dan sesuai dengan strategi deployment.
- Profil query database dan panggilan API eksternal.
- Terapkan cache pada halaman publik yang aman, lalu ukur cache hit rate.
- Uji ulang dengan data pengguna nyata, bukan hanya satu hasil dari alat pengujian.
Website cepat bukan hasil dari satu tombol “optimalkan”. Ia biasanya datang dari kebiasaan mengukur, mengisolasi lapisan yang bermasalah, lalu mengubah satu hal pada satu waktu. Dengan pendekatan itu, Anda bisa memperbaiki penyebab sebenarnya tanpa membayar kapasitas server yang belum tentu dibutuhkan.
Sumber & bacaan lebih lanjut
- Optimize Time to First Byte
- Web Vitals
- PHP OPcache Manual
- PHP OPcache Runtime Configuration
- NGINX FastCGI Module Documentation
– Rio Yotto @rioyotto