Banyak pemilik website langsung membuka Lighthouse ketika halaman terasa lambat, lalu fokus mengecilkan gambar, menghapus plugin, atau menunda pemuatan JavaScript. Langkah-langkah itu memang bisa membantu, tetapi tidak selalu menyentuh sumber masalah utama.
Jika server membutuhkan waktu terlalu lama untuk menyiapkan respons pertama, browser bahkan belum mendapat kesempatan untuk menampilkan gambar atau menjalankan JavaScript. Dalam kondisi seperti ini, optimasi di sisi frontend ibarat merapikan ruang tamu ketika pintu rumah masih terkunci.
Karena itu, pemeriksaan performa sebaiknya dimulai dari jalur paling awal: berapa lama permintaan pengguna diproses sebelum HTML pertama dikirim?
Kenali bagian website yang paling sering menjadi bottleneck
Ketika pengguna membuka halaman, permintaan biasanya melewati beberapa tahap: koneksi ke server, proses web server, PHP atau aplikasi backend, query ke database, pengambilan data dari cache, lalu pengiriman respons ke browser.
Masalah di salah satu tahap tersebut dapat membuat metrik seperti Largest Contentful Paint atau LCP memburuk. LCP mengukur kapan elemen konten terbesar yang terlihat di layar selesai ditampilkan. Target yang umum digunakan adalah 2,5 detik atau lebih cepat untuk setidaknya 75 persen kunjungan. Namun, angka LCP tidak hanya dipengaruhi gambar besar. Waktu tunggu dari server atau Time to First Byte juga ikut berperan.
Itulah sebabnya skor PageSpeed yang rendah tidak otomatis berarti semua masalah ada di CSS dan JavaScript. Data laboratorium membantu menemukan pola, tetapi data pengguna nyata dapat menunjukkan kondisi yang berbeda karena perangkat, jaringan, lokasi, dan pola interaksi setiap pengunjung tidak sama.
Langkah pertama: bedakan masalah server dan masalah browser
Gunakan pemeriksaan sederhana sebelum melakukan perubahan besar.
- Periksa TTFB. Jika waktu menuju byte pertama sudah tinggi, fokus awal sebaiknya pada server, backend, database, atau cache HTML.
- Periksa ukuran dan waktu muat aset. Jika TTFB rendah tetapi halaman tetap lambat, gambar, font, CSS, atau JavaScript kemungkinan lebih dominan.
- Bandingkan halaman statis dan dinamis. Buat satu file HTML sederhana di server. Jika file tersebut cepat tetapi halaman CMS lambat, masalah kemungkinan berada di aplikasi atau database.
- Uji halaman dalam kondisi cache dan tanpa cache. Perbedaan yang terlalu besar menunjukkan cache belum bekerja optimal atau proses backend terlalu berat.
Pengujian ini tidak menggantikan observabilitas yang lengkap, tetapi cukup untuk mencegah kita menebak-nebak. Perubahan performa yang baik biasanya dimulai dari pengukuran, bukan dari daftar tips acak.
Cache bukan sekadar tombol “aktifkan”
Cache menyimpan hasil proses yang bisa digunakan kembali sehingga server tidak perlu mengulang pekerjaan yang sama. Untuk halaman publik, cache HTML dapat mengurangi proses PHP dan query database pada setiap kunjungan. Untuk aset statis seperti CSS, JavaScript, dan gambar, browser maupun CDN dapat menyimpannya lebih lama.
Namun, cache yang terlalu agresif juga berisiko menampilkan konten lama. Sebaliknya, aturan yang terlalu ketat membuat setiap permintaan kembali ke server sehingga manfaat cache hampir hilang.
Gunakan pola yang berbeda sesuai jenis konten:
- Aset dengan nama file berversi, seperti
app.abc123.js, biasanya aman diberi masa cache panjang. - Halaman publik yang jarang berubah dapat menggunakan cache CDN atau reverse proxy dengan TTL yang terukur.
- Halaman akun, keranjang belanja, dan dashboard sebaiknya tidak dibagikan melalui cache publik karena berisi data personal.
- Respons yang menggunakan cookie atau memuat data pengguna perlu diperiksa dengan hati-hati sebelum dilewatkan ke CDN.
Header Cache-Control membantu menjelaskan apakah respons boleh disimpan, berapa lama dapat digunakan, dan kapan harus divalidasi ulang. Jangan hanya mengandalkan pengaturan bawaan provider CDN; cek juga header yang benar-benar dikirim oleh server.
PHP-FPM: jangan hanya menambah jumlah worker
Pada website berbasis PHP, PHP-FPM bertugas mengelola proses yang menjalankan kode PHP. Salah satu kesalahan umum adalah langsung menaikkan nilai pm.max_children ketika website mulai lambat.
Menambah worker memang dapat membantu jika antrean permintaan terlalu panjang. Tetapi setiap worker membutuhkan memori. Jika jumlahnya terlalu tinggi, server bisa kehabisan RAM dan mulai menggunakan swap. Hasil akhirnya justru lebih lambat, bahkan dapat menyebabkan proses dihentikan sistem.
Periksa beberapa hal berikut:
- Apakah worker PHP-FPM sering mencapai batas maksimum?
- Apakah terdapat proses yang berjalan terlalu lama?
- Berapa penggunaan memori rata-rata setiap worker?
- Apakah log menunjukkan timeout, error koneksi database, atau permintaan yang menumpuk?
Konfigurasi ideal bergantung pada RAM, jenis aplikasi, ukuran kode, dan pola trafik. Jadi, jangan menyalin konfigurasi dari server lain tanpa mengukur konsumsi memori dan antreannya terlebih dahulu.
Database lambat sering terlihat seperti website lambat
Halaman yang membutuhkan data dari MySQL dapat tertahan meskipun web server dan jaringan bekerja normal. Query tanpa indeks, pengambilan terlalu banyak baris, pengurutan data berukuran besar, atau terlalu banyak query kecil dalam satu halaman adalah penyebab yang sering muncul.
Mulailah dari query yang paling sering dipanggil atau paling lama selesai. Gunakan EXPLAIN untuk melihat bagaimana MySQL merencanakan eksekusi query. Periksa apakah indeks digunakan, berapa banyak baris yang dipindai, dan apakah database membuat tabel sementara untuk pengurutan atau pengelompokan.
Jangan menambahkan indeks secara membabi buta. Indeks dapat mempercepat pembacaan, tetapi juga menambah biaya saat data ditulis atau diperbarui. Perbaikan yang lebih sehat biasanya berupa kombinasi antara query yang lebih spesifik, indeks yang sesuai, pagination, dan cache untuk data yang tidak sering berubah.
Apa yang bisa dilakukan sekarang?
Untuk audit awal, pilih satu halaman penting—misalnya beranda, halaman produk, atau artikel paling populer—lalu catat tiga hal: TTFB, ukuran halaman, dan query atau proses backend yang paling lama.
Setelah itu, lakukan perubahan satu per satu. Aktifkan cache untuk aset statis, pastikan header cache sesuai, ukur antrean PHP-FPM, dan periksa query lambat. Baru setelah sisi server cukup sehat, lanjutkan ke gambar, font, JavaScript, dan layout.
Urutan ini penting karena optimasi performa bukan perlombaan mengejar skor sempurna. Tujuannya adalah membuat pengguna menerima konten dengan cepat, halaman merespons interaksi dengan konsisten, dan server tetap stabil ketika trafik meningkat.
Intinya: sebelum mengecilkan gambar atau memasang plugin optimasi baru, pastikan server tidak sedang menahan setiap permintaan. Website yang cepat biasanya bukan hasil dari satu trik, melainkan dari jalur pemrosesan yang diukur dan diperbaiki dari ujung ke ujung.
Sumber & bacaan lebih lanjut
- Web Vitals — web.dev
- Why lab and field data can be different — web.dev
- Origin Cache Control — Cloudflare Developers
- PHP-FPM Configuration — PHP Manual
- MySQL 8.4 Optimization Reference Manual
– Rio Yotto @rioyotto