Website sering terasa normal saat diuji sendiri, lalu mulai lambat ketika pengunjung datang bersamaan. Pada kondisi seperti ini, menambah RAM atau menaikkan paket hosting memang bisa membantu, tetapi belum tentu menyelesaikan masalah. Bottleneck bisa berada di gambar yang terlalu besar, JavaScript yang berat, antrean PHP-FPM, atau query MySQL yang membaca terlalu banyak baris.
Pendekatan yang lebih aman adalah memeriksa jalur request dari depan ke belakang. Anggap saja website seperti restoran: pelanggan melihat waktu menunggu di meja, tetapi penyebabnya bisa berasal dari menu yang lama disiapkan, dapur yang penuh, atau kasir yang hanya memiliki satu petugas.
Mulai dari gejala yang terlihat pengguna
Langkah pertama bukan membuka konfigurasi server, melainkan memastikan bagian mana yang terasa lambat. Apakah halaman lama menampilkan konten utama? Apakah tombol baru merespons setelah beberapa detik? Atau halaman sudah terbuka, tetapi tampilannya bergeser dan belum stabil?
Core Web Vitals membantu membedakan tiga pengalaman tersebut. Largest Contentful Paint atau LCP mengukur kapan konten utama terlihat. Interaction to Next Paint atau INP menggambarkan seberapa cepat halaman merespons interaksi. Sementara Cumulative Layout Shift atau CLS mengukur perpindahan elemen yang tidak diharapkan. Target “baik” yang umum digunakan adalah LCP maksimal 2,5 detik, INP maksimal 200 milidetik, dan CLS maksimal 0,1 pada persentil ke-75 kunjungan.
Angka tersebut bukan vonis tunggal. Pengujian dari laptop dengan koneksi cepat bisa terlihat baik, sementara pengguna ponsel dengan jaringan seluler mengalami kondisi berbeda. Karena itu, bandingkan hasil pengujian laboratorium dengan data pengguna nyata bila tersedia.
Baca waterfall sebelum mengubah konfigurasi
Panel Network di browser menunjukkan urutan permintaan yang terjadi saat halaman dibuka. Perhatikan tiga hal berikut:
- Document request: jika permintaan dokumen utama sudah lama sebelum byte pertama diterima, masalah kemungkinan berada di server, aplikasi, atau database.
- File statis: CSS, JavaScript, font, dan gambar yang besar dapat memperlambat halaman setelah server sebenarnya sudah merespons.
- Request berantai: satu file JavaScript yang menunggu file lain atau terlalu banyak koneksi pihak ketiga bisa menunda tampilan dan interaksi.
Gunakan mode jaringan yang lebih lambat dan perangkat CPU yang dibatasi saat menguji. Tujuannya bukan membuat hasil terlihat buruk, melainkan mendekati kondisi pengguna sebenarnya. Simpan hasil sebelum dan sesudah perubahan agar kita tidak mengandalkan perasaan semata.
Jika document request lambat, periksa jalur server
Waktu respons dokumen utama sering disebut sebagai TTFB, yaitu waktu sampai browser menerima byte pertama. Namun, TTFB tinggi hanya gejala, bukan diagnosis. Pada aplikasi PHP, beberapa penyebab yang umum adalah proses PHP-FPM yang habis, skrip yang menunggu layanan eksternal, atau query database yang lama.
PHP-FPM menggunakan worker untuk menangani request. Jika semua worker sedang sibuk, request baru harus menunggu. Periksa jumlah proses aktif, request yang sedang diproses, serta log slow request bila tersedia. PHP-FPM menyediakan fitur slowlog untuk membantu melihat skrip yang berjalan terlalu lama, dan status pool dapat dipakai untuk memantau kondisi worker.
Jangan langsung menaikkan jumlah worker setinggi mungkin. Setiap worker memakai memori. Jika RAM habis dan sistem mulai melakukan swap, performa dapat memburuk secara keseluruhan. Lebih baik catat penggunaan memori per proses, tentukan batas yang masuk akal, lalu uji saat beban meningkat.
Bedakan antrean PHP dengan aplikasi yang memang lambat
Jika waktu tunggu terjadi sebelum PHP mulai bekerja, pool mungkin kehabisan worker. Jika worker tersedia tetapi request tetap lama, telusuri kode aplikasi dan layanan yang dipanggil. Misalnya, halaman produk dapat terlihat sederhana, tetapi masih melakukan permintaan ke API stok, sistem rekomendasi, atau layanan pengiriman sebelum mengirim HTML.
Untuk proses yang tidak perlu ditunggu pengguna, pertimbangkan antrean pekerjaan. Mengirim email, membuat thumbnail, atau menghitung laporan biasanya tidak harus selesai sebelum halaman utama tampil.
Telusuri MySQL dengan EXPLAIN, bukan tebakan
Database sering dituduh sebagai sumber kelambatan, tetapi query yang sama bisa cepat pada tabel kecil dan menjadi berat ketika data bertambah. Mulailah dari query yang benar-benar lambat, lalu jalankan EXPLAIN untuk melihat rencana eksekusinya.
EXPLAIN SELECT id, title
FROM articles
WHERE category_id = 7
ORDER BY published_at DESC
LIMIT 20;Periksa apakah kolom yang dipakai untuk penyaringan, pengurutan, atau penggabungan tabel memiliki indeks yang sesuai. MySQL sendiri merekomendasikan penggunaan indeks dan EXPLAIN untuk memahami bagaimana query dijalankan. Namun, menambahkan indeks secara membabi buta juga memiliki biaya: ruang penyimpanan bertambah dan operasi tulis bisa menjadi lebih berat.
Perhatikan pula query yang mengambil terlalu banyak kolom atau baris. Untuk halaman daftar, hindari SELECT * jika hanya beberapa kolom yang ditampilkan. Batasi hasil, gunakan pagination yang sesuai, dan pastikan query tidak melakukan pemindaian penuh pada tabel besar tanpa alasan.
Cache membantu, tetapi bukan penghapus masalah
Cache dapat mengurangi pekerjaan berulang. Halaman yang sama tidak perlu dirender dari awal untuk setiap pengunjung jika isinya tidak berubah setiap detik. Cache objek juga bisa mengurangi query berulang ke database.
Namun, cache yang terlalu agresif dapat menyajikan data kedaluwarsa, membuat perubahan tidak segera terlihat, atau menyimpan halaman yang seharusnya bersifat personal. Tentukan lebih dulu apa yang aman disimpan: halaman publik, hasil query yang stabil, atau aset statis dengan nama file berversi. Jangan menganggap semua respons boleh dicache hanya karena cache membuat skor pengujian membaik.
Yang bisa dilakukan sekarang
- Uji halaman yang lambat dengan browser DevTools dan simpan waterfall-nya.
- Catat apakah keterlambatan terjadi pada document request, aset statis, atau interaksi setelah halaman terbuka.
- Periksa status dan slowlog PHP-FPM sebelum mengubah jumlah worker.
- Ambil query paling lambat dari log aplikasi atau database, lalu analisis dengan
EXPLAIN. - Ukur penggunaan CPU, RAM, disk I/O, dan koneksi database ketika trafik meningkat.
- Uji satu perubahan pada satu waktu, kemudian bandingkan hasilnya dengan kondisi awal.
Intinya, website lambat bukan satu jenis masalah. Jika kita langsung mengganti server tanpa mengetahui titik macetnya, biaya bisa naik sementara keluhan tetap ada. Diagnosis berurutan—dari pengalaman pengguna, waterfall, PHP-FPM, sampai MySQL—membuat tuning lebih terukur dan lebih kecil risikonya.
Sumber & bacaan lebih lanjut
- Web Vitals – web.dev
- How the Core Web Vitals metrics thresholds were defined – web.dev
- PHP: FastCGI Process Manager (FPM) – PHP Manual
- MySQL 8.4 Reference Manual – Optimization
- MySQL 8.4 Reference Manual – Optimizing SELECT Statements
– Rio Yotto @rioyotto