Website Lambat Tidak Selalu Salah Cache: Cara Menemukan Bottleneck dari Browser sampai Database

Website yang lambat sering terasa seperti satu masalah, padahal penyebabnya bisa berada di beberapa lapisan sekaligus. Halaman dapat menunggu server terlalu lama, mengunduh gambar besar, menjalankan terlalu banyak JavaScript, atau tersendat saat mengambil data dari database.

Itulah sebabnya optimasi yang hanya berfokus pada skor Lighthouse sering tidak cukup. Pengunjung nyata memakai perangkat, jaringan, dan lokasi yang berbeda. Data lapangan dan pengujian lokal bisa menunjukkan hasil yang tidak sama, terutama ketika halaman dipengaruhi cache, personalisasi, atau interaksi pengguna.

Artikel ini membahas cara menelusuri masalah performa secara berurutan, sehingga kita tidak menebak-nebak atau mengganti server sebelum tahu sumber masalahnya.

Mulai dari gejala, bukan dari solusi

Sebelum mengubah konfigurasi, tentukan dulu apa yang sebenarnya lambat.

• Halaman lama mulai terlihat: biasanya berkaitan dengan waktu respons server, koneksi, atau proses backend.
• Konten utama terlambat muncul: periksa gambar hero, font, CSS, dan elemen yang menjadi Largest Contentful Paint (LCP).
• Tombol terasa tidak responsif: periksa JavaScript dan tugas panjang yang memblokir main thread.
• Halaman bergeser saat dimuat: periksa ukuran gambar, iklan, embed, atau komponen dinamis yang tidak memiliki ruang sejak awal.
• Hanya halaman tertentu yang lambat: curigai query, template, atau plugin yang spesifik pada halaman tersebut.

Core Web Vitals membantu mengelompokkan gejala itu. Target yang umum dipakai adalah LCP maksimal 2,5 detik, Interaction to Next Paint (INP) maksimal 200 milidetik, dan Cumulative Layout Shift (CLS) maksimal 0,1 pada persentil ke-75. Angka ini sebaiknya dibaca sebagai indikator pengalaman pengguna, bukan sebagai nilai ujian yang berdiri sendiri. Dokumentasi Web Vitals menjelaskan cara metrik tersebut digunakan.

Bedakan waktu server dan waktu browser

Langkah pertama yang praktis adalah melihat waterfall di Chrome DevTools atau WebPageTest. Waterfall menunjukkan urutan permintaan: DNS, koneksi, respons awal HTML, CSS, JavaScript, gambar, dan permintaan lain.

Jika dokumen HTML baru menerima byte pertama setelah waktu yang panjang, masalahnya kemungkinan berada di backend atau jaringan. Metrik ini dikenal sebagai Time to First Byte (TTFB), yaitu waktu sampai browser menerima byte pertama dari server.

Sebaliknya, jika HTML cepat tetapi halaman baru terasa siap setelah banyak aset selesai dimuat, fokuskan pemeriksaan pada ukuran gambar, font, CSS, JavaScript, dan layanan pihak ketiga. Satu halaman dapat memiliki TTFB yang baik tetapi tetap lambat karena browser harus mengerjakan terlalu banyak hal.

Periksa PHP-FPM sebelum menambah server

Pada aplikasi PHP, PHP-FPM bertugas mengelola proses yang melayani permintaan. Salah satu pengaturan penting adalah pm.max_children, yaitu batas jumlah permintaan yang dapat dilayani secara bersamaan. Nilai yang terlalu kecil dapat membuat permintaan mengantre. Nilai yang terlalu besar justru dapat menghabiskan RAM dan membuat server melakukan swap.

Dokumentasi resmi PHP menjelaskan bahwa mode static, dynamic, dan ondemand memiliki cara berbeda dalam membuat proses worker. Karena itu, jangan menyalin konfigurasi dari server lain tanpa menghitung kapasitas mesin sendiri. Referensi konfigurasi PHP-FPM dapat menjadi titik awal.

Yang perlu diamati bukan hanya angka konfigurasi, tetapi juga gejalanya:

• Apakah jumlah worker sering menyentuh batas maksimum?
• Apakah waktu tunggu meningkat saat trafik naik?
• Apakah penggunaan RAM mendekati penuh?
• Apakah proses PHP banyak menghabiskan waktu di query atau API eksternal?

Jika worker penuh karena query database lambat, menaikkan pm.max_children hanya menambah antrean pekerjaan. Perbaiki penyebabnya terlebih dahulu.

Gunakan database sebagai tersangka yang bisa dibuktikan

Query yang cepat pada tabel kecil belum tentu tetap cepat ketika data sudah bertambah. Untuk memeriksa rencana eksekusi, gunakan EXPLAIN. Pada MySQL 8.0.18 dan versi setelahnya, EXPLAIN ANALYZE dapat menjalankan query dan menampilkan waktu aktual, jumlah baris, serta jumlah iterasi pada tiap bagian rencana eksekusi.

EXPLAIN ANALYZE
SELECT id, title
FROM articles
WHERE status = 'published'
ORDER BY published_at DESC
LIMIT 20;

Perhatikan apakah database membaca jauh lebih banyak baris daripada yang dikembalikan, melakukan penyortiran besar, atau tidak memakai indeks yang sesuai. Dokumentasi MySQL menjelaskan perbedaan antara estimasi pada EXPLAIN dan informasi aktual dari EXPLAIN ANALYZE. Lihat referensi EXPLAIN MySQL.

Perbaikan yang masuk akal bisa berupa indeks gabungan, pengurangan kolom yang diambil, pagination yang lebih efisien, atau pemecahan query yang terlalu besar. Namun, indeks tambahan juga memiliki biaya: penulisan data dapat menjadi lebih berat dan ukuran penyimpanan bertambah.

Optimalkan elemen yang paling terlihat

Jika masalah utama ada pada LCP, cari tahu elemen apa yang menjadi LCP. Elemen itu bisa berupa gambar, blok teks, poster video, atau gambar latar. Gambar hero sering menjadi tersangka karena ukurannya besar dan baru diminta setelah CSS atau JavaScript selesai berjalan.

Beberapa langkah yang biasanya aman dicoba:

1. Gunakan dimensi gambar yang mendekati ukuran tampilnya, bukan foto asli berukuran sangat besar.
2. Pilih format modern jika alur kerja situs mendukungnya.
3. Jangan melakukan lazy-load pada gambar utama yang langsung terlihat di layar.
4. Pastikan font tidak menahan tampilan teks utama terlalu lama.
5. Kurangi redirect dan permintaan ke domain pihak ketiga yang tidak penting.

Untuk CLS, tetapkan ukuran gambar dan ruang komponen sebelum konten dimuat. Tujuannya sederhana: browser tahu tempat yang harus disediakan sejak awal, sehingga teks atau tombol tidak tiba-tiba terdorong ke bawah.

JavaScript yang terlalu sibuk juga membuat website terasa lambat

Website bisa selesai mengunduh tetapi tetap tidak nyaman dipakai karena browser sibuk menjalankan JavaScript. Menu, pencarian, filter, dan tombol checkout akan terasa terlambat jika main thread diblokir oleh tugas panjang.

Mulailah dengan menghapus script yang tidak lagi dipakai, menunda script non-kritis, dan memuat layanan analitik secara asinkron. Hindari memasang banyak widget hanya karena tersedia. Setiap widget membawa JavaScript, koneksi, dan kemungkinan pekerjaan tambahan di browser.

INP mengukur respons halaman terhadap interaksi pengguna. Karena itu, pengujian tidak boleh hanya memuat halaman lalu berhenti. Coba buka menu, ketik pada kolom pencarian, gunakan filter, dan klik tombol utama. Pengukuran lapangan lebih mampu menangkap masalah yang baru muncul setelah pengguna berinteraksi.

Urutan perbaikan yang bisa dilakukan sekarang

1. Catat halaman, perangkat, lokasi, dan kondisi ketika kelambatan terjadi.
2. Bandingkan data lapangan dengan pengujian lokal menggunakan PageSpeed Insights atau DevTools.
3. Periksa TTFB dan waterfall untuk memisahkan masalah server dari masalah browser.
4. Jika TTFB tinggi, periksa PHP-FPM, query database, cache halaman, dan API eksternal.
5. Jika TTFB baik tetapi LCP buruk, periksa gambar utama, CSS, font, dan urutan pemuatan aset.
6. Jika interaksi lambat, rekam aktivitas di DevTools dan cari tugas JavaScript yang panjang.
7. Uji satu perubahan pada satu waktu, lalu bandingkan hasil sebelum dan sesudahnya.

Performa yang baik bukan hasil dari satu tombol “optimalkan”. Ia biasanya lahir dari diagnosis yang tepat, perubahan kecil yang terukur, dan pemantauan setelah rilis.

Apa artinya bagi kita?

Jangan langsung menyimpulkan bahwa website membutuhkan CDN baru, server yang lebih mahal, atau plugin cache tambahan. Bisa jadi masalahnya hanya gambar hero yang terlalu besar, query tanpa indeks, worker PHP yang selalu penuh, atau JavaScript pihak ketiga yang tidak lagi diperlukan.

Mulailah dari jalur yang dilalui satu permintaan: browser meminta halaman, server menjalankan aplikasi, aplikasi mengambil data, lalu browser merender dan merespons interaksi. Dengan urutan itu, optimasi menjadi pekerjaan investigasi yang masuk akal—bukan perlombaan mengejar skor.

Sumber & bacaan lebih lanjut

• Web Vitals - web.dev
• Getting started with measuring Web Vitals - web.dev
• PHP: Configuration - Manual
• MySQL 8.0 Reference Manual: EXPLAIN Statement

– Rio Yotto @rioyotto