TTFB Tinggi atau Halaman Terlalu Berat? Cara Menemukan Bottleneck Website dengan Tepat

Ketika sebuah website terasa lambat, reaksi yang paling umum adalah mengecilkan gambar, memasang plugin cache, atau menambah kapasitas hosting. Langkah-langkah itu bisa membantu, tetapi belum tentu menyentuh penyebab utama. Website yang lambat karena server terlambat mengirim HTML membutuhkan penanganan yang berbeda dari halaman yang sudah menerima HTML dengan cepat, tetapi masih sibuk memuat JavaScript dan gambar.

Itulah mengapa langkah pertama bukan langsung mengubah konfigurasi, melainkan mencari bottleneck—bagian yang paling menghambat proses. Dalam praktiknya, kita bisa memulai dari dua petunjuk penting: Time to First Byte atau TTFB, yaitu waktu sampai browser menerima byte pertama dari server, dan Largest Contentful Paint atau LCP, yaitu waktu sampai konten utama yang terlihat di layar selesai ditampilkan.

Google menjadikan LCP sebagai salah satu Core Web Vitals, dengan sasaran pengalaman yang baik pada nilai sekitar 2,5 detik atau lebih cepat untuk mayoritas kunjungan. Namun, angka itu sebaiknya dipakai sebagai petunjuk diagnosis, bukan satu-satunya tujuan optimasi. Panduan web.dev tentang LCP juga menekankan pentingnya melihat TTFB dan tahapan pemuatan resource untuk memahami sumber masalah.

Mulai dari pertanyaan sederhana: lambatnya terjadi di mana?

Bayangkan website seperti restoran. TTFB menggambarkan waktu pelayan membawa menu setelah kita duduk. LCP lebih mirip waktu sampai hidangan utama benar-benar tersaji. Jika menu saja lama datang, masalahnya mungkin ada di dapur, antrean pesanan, atau sistem kasir. Jika menu cepat tetapi hidangan utama lama, perhatian perlu dialihkan ke proses memasak dan penyajiannya.

Pada website, pola sederhananya seperti ini:

• TTFB tinggi: server, PHP, database, jaringan, atau cache halaman perlu diperiksa.
• TTFB rendah tetapi LCP tinggi: biasanya ada gambar utama, font, CSS, JavaScript, atau proses rendering yang terlambat.
• Keduanya tinggi: mungkin ada masalah gabungan, misalnya halaman dibuat lambat oleh query database lalu masih memuat terlalu banyak aset.

Gunakan PageSpeed Insights, Lighthouse, atau tab Network di DevTools. Jangan hanya melihat skor akhir. Periksa kapan dokumen HTML mulai diterima, resource mana yang menjadi kandidat LCP, dan apakah resource penting baru ditemukan setelah JavaScript berjalan.

Jika TTFB tinggi, periksa server sebelum menyalahkan gambar

TTFB yang tinggi sering muncul karena server perlu menjalankan terlalu banyak pekerjaan sebelum mengirim respons. Pada website PHP, penyebabnya bisa berupa plugin atau modul yang berat, proses autentikasi yang berulang, koneksi ke layanan eksternal, atau query MySQL yang membaca terlalu banyak baris.

Periksa log dan waktu eksekusi aplikasi lebih dahulu. Jika menggunakan PHP-FPM, manfaatkan pengaturan seperti slowlog untuk menemukan skrip yang berjalan unusually lama. PHP-FPM memang menyediakan pengelolaan proses, logging, serta slowlog untuk membantu mengidentifikasi eksekusi PHP yang lambat. Detail pengaturannya tersedia di manual PHP-FPM dan dokumentasi konfigurasinya.

Jangan langsung menaikkan jumlah worker PHP-FPM. Worker yang terlalu banyak dapat membuat RAM cepat habis dan justru memicu swap atau antrean baru. Sebaliknya, catat penggunaan memori, jumlah request bersamaan, waktu respons, serta berapa banyak proses yang menunggu. Penyesuaian harus mengikuti kapasitas mesin, bukan menyalin angka dari tutorial yang dibuat untuk server berbeda.

Database sering menjadi sumber antrean yang tidak terlihat

Halaman yang tampak sederhana bisa menjalankan banyak query di belakang layar. Masalahnya semakin terasa pada halaman pencarian, katalog, dashboard, atau website dengan data yang terus bertambah. Query yang dulu cepat ketika tabel berisi ribuan baris dapat melambat ketika jumlah data sudah jauh lebih besar.

Gunakan EXPLAIN untuk melihat bagaimana MySQL berencana menjalankan query. Perintah ini dapat menunjukkan tabel yang dibaca, indeks yang dipertimbangkan, indeks yang dipilih, serta perkiraan jumlah baris yang perlu diperiksa. MySQL juga menyediakan EXPLAIN ANALYZE untuk membandingkan perkiraan optimizer dengan waktu eksekusi aktual. Rujukan resminya ada di MySQL Reference Manual.

EXPLAIN SELECT id, title
FROM posts
WHERE status = 'publish'
ORDER BY published_at DESC
LIMIT 20;

Dari sini, cari tanda-tanda seperti pemindaian tabel besar, pengurutan yang mahal, atau kolom filter yang belum memiliki indeks sesuai kebutuhan. Namun, indeks bukan obat untuk semua masalah. Terlalu banyak indeks juga menambah beban saat data ditulis dan memakan ruang penyimpanan. Uji perubahan pada query dan struktur indeks, lalu ukur kembali.

Cache membantu, tetapi aturan pengecualian lebih penting

Cache halaman dapat mengurangi pekerjaan PHP dan database untuk halaman yang sama. Pada website publik seperti blog atau halaman informasi, ini sering memberikan dampak besar. Nginx, misalnya, menyediakan fastcgi_cache untuk menyimpan respons dari PHP-FPM dan menggunakannya kembali pada request berikutnya.

Masalah muncul ketika cache diterapkan tanpa memahami jenis halaman. Keranjang belanja, halaman akun, formulir dengan data pribadi, dan dashboard tidak boleh diperlakukan seperti artikel publik. Request dengan cookie login, metode POST, atau parameter tertentu biasanya perlu dikecualikan dari cache.

Dokumentasi Nginx menjelaskan penggunaan fastcgi_cache_bypass, fastcgi_no_cache, fastcgi_cache_valid, dan fastcgi_cache_lock. Fitur terakhir berguna untuk mencegah banyak request bersamaan mengisi cache yang sama ketika item belum tersedia. Lihat dokumentasi modul FastCGI Nginx sebelum mengaktifkan konfigurasi serupa di produksi.

Untuk aset statis seperti CSS, JavaScript, dan gambar, gunakan aturan cache yang sesuai. Header seperti Cache-Control, ETag, dan Last-Modified membantu browser menentukan apakah resource masih bisa digunakan atau perlu divalidasi ulang. Cache yang baik bukan sekadar “simpan semuanya selama mungkin”, melainkan kombinasi antara umur cache, strategi invalidasi, dan penamaan file yang berubah ketika isinya berubah.

Jika server cepat, fokus pada resource utama

Ketika TTFB sudah baik tetapi LCP masih lambat, periksa elemen terbesar yang terlihat pertama kali. Sering kali itu adalah gambar hero, judul dengan web font, atau blok konten yang baru muncul setelah JavaScript selesai.

• Pastikan gambar utama dapat ditemukan langsung dari HTML, bukan baru disisipkan melalui JavaScript.
• Gunakan ukuran gambar yang sesuai dengan tampilan, lalu pilih format modern bila kompatibel dengan kebutuhan website.
• Jangan menerapkan lazy loading pada gambar yang langsung terlihat di layar.
• Gunakan fetchpriority="high" secara selektif untuk resource utama, bukan pada banyak gambar sekaligus.
• Tunda script pihak ketiga yang tidak diperlukan untuk tampilan awal.

Preload juga bukan tombol ajaib. Jika terlalu banyak resource diberi prioritas tinggi, browser kehilangan petunjuk mana yang benar-benar penting. Ukur perubahan melalui waterfall di DevTools dan data pengguna nyata bila tersedia.

Yang bisa dilakukan sekarang

1. Uji URL yang sama dari lokasi dan perangkat yang konsisten.
2. Catat TTFB, LCP, ukuran halaman, jumlah request, dan resource terbesar.
3. Bandingkan halaman yang memakai cache dengan request pertama tanpa cache.
4. Jika TTFB tinggi, periksa PHP-FPM, query database, dan layanan eksternal.
5. Jika TTFB rendah tetapi LCP tinggi, periksa gambar utama, font, CSS, dan JavaScript.
6. Ubah satu hal dalam satu waktu, lalu ukur ulang sebelum menerapkan perubahan berikutnya.

Intinya: optimasi performa akan lebih efektif jika dimulai dari lokasi masalah, bukan dari daftar trik yang sedang populer. Website cepat bukan hasil dari satu plugin atau satu konfigurasi, melainkan hasil dari pengukuran yang konsisten, cache yang memiliki aturan jelas, query yang masuk akal, dan resource penting yang dikirim pada waktu yang tepat.

Sumber & bacaan lebih lanjut

• Optimize Largest Contentful Paint
• PHP: FastCGI Process Manager (FPM)
• PHP-FPM Configuration
• MySQL 8.4 EXPLAIN Statement
• Nginx FastCGI Module
• HTTP Caching

– Rio Yotto @rioyotto