Website Lambat? Jangan Langsung Menambah Server, Cari Bottleneck-nya Dulu

Ketika website mulai lambat, reaksi yang paling umum adalah menaikkan paket hosting, menambah CPU, atau memindahkan situs ke server yang lebih mahal. Langkah itu kadang membantu, tetapi sering kali hanya menutupi masalah. Jika penyebabnya adalah query MySQL yang buruk, cache yang tidak bekerja, atau JavaScript yang memblokir browser, server baru tidak otomatis menyelesaikannya.

Cara yang lebih masuk akal adalah mencari bottleneck, yaitu bagian paling lambat dalam rangkaian proses membuka halaman. Anggap saja website seperti restoran: pelanggan melewati kasir, dapur, pelayan, dan meja makan. Menambah meja tidak akan membantu jika dapurnya yang terlalu lama menyiapkan pesanan.

Mulai dari pertanyaan sederhana: lambatnya di mana?

Sebelum mengubah konfigurasi, tentukan dulu jenis kelambatannya. Apakah halaman lama mulai menampilkan respons pertama, atau HTML sudah muncul tetapi gambar dan tombolnya terlambat siap?

• Lambat sebelum ada isi halaman: kemungkinan terkait DNS, koneksi ke server, PHP, aplikasi, atau database. Ini sering terlihat sebagai Time to First Byte (TTFB), yaitu waktu hingga browser menerima byte pertama dari server.
• HTML cepat, tetapi halaman belum terlihat utuh: periksa ukuran gambar, font, CSS, dan JavaScript.
• Halaman terlihat selesai, tetapi klik terasa tertunda: JavaScript yang terlalu berat dapat memblokir pekerjaan utama browser.
• Hanya lambat pada pengguna tertentu: periksa lokasi server, CDN, perangkat, jaringan, dan perbedaan antara pengguna yang sudah login dengan pengunjung biasa.

Core Web Vitals membantu memecah pengalaman ini menjadi tiga ukuran: LCP untuk kecepatan elemen utama tampil, INP untuk respons terhadap interaksi, dan CLS untuk kestabilan tata letak. Data dari pengguna nyata juga penting karena hasil uji laboratorium tidak selalu sama dengan pengalaman pembaca di lapangan. ([web.dev](https://web.dev/articles/vitals-measurement-getting-started?hl=en&utm_source=openai))

Bedakan masalah server dan masalah browser

Gunakan dua jenis pengujian. Pertama, buka halaman dengan alat seperti PageSpeed Insights, Lighthouse, atau panel Network di browser. Kedua, ukur respons URL secara langsung menggunakan alat pemantauan atau perintah seperti curl.

curl -o /dev/null -s -w "DNS:%{time_namelookup} Connect:%{time_connect} TTFB:%{time_starttransfer} Total:%{time_total}\n" https://contoh.com/

Angka TTFB yang tinggi mengarah ke jalur server atau jaringan. Sebaliknya, TTFB yang cukup baik tetapi waktu total halaman tetap panjang biasanya menunjukkan pekerjaan di sisi browser, seperti gambar besar, terlalu banyak file JavaScript, atau skrip pihak ketiga.

Jangan hanya menguji dari laptop dan koneksi kantor. Pengunjung bisa memakai ponsel kelas menengah, jaringan seluler yang tidak stabil, dan lokasi yang jauh dari server. Uji dengan beberapa perangkat dan lokasi agar diagnosis tidak bias.

Periksa cache sebelum menyentuh kode aplikasi

Cache menyimpan hasil yang bisa dipakai ulang sehingga server tidak perlu memproses permintaan yang sama berulang kali. Cache dapat berada di browser, reverse proxy, plugin aplikasi, atau CDN. Jika halaman publik selalu dibuat ulang dari PHP dan database, server akan bekerja terlalu keras untuk konten yang sebenarnya tidak banyak berubah.

Periksa header respons dengan:

curl -I https://contoh.com/artikel/

Perhatikan Cache-Control, ETag, Age, atau header khusus CDN. Untuk aset statis seperti CSS, JavaScript, dan gambar yang memakai nama file berversi, masa cache panjang biasanya masuk akal. HTML yang sering berubah memerlukan strategi berbeda, misalnya validasi ulang dengan no-cache. Konten yang bersifat pribadi tidak boleh disimpan di shared cache karena berisiko terlihat oleh pengguna lain. ([developer.mozilla.org](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Cache-Control?utm_source=openai))

Kesalahan yang sering terjadi adalah mengaktifkan semua lapisan cache tanpa memahami urutannya. Hasilnya bisa berupa halaman lama, cache yang tidak pernah terkena, atau pengguna yang sudah login menerima respons yang salah. Catat mana yang dicache, berapa lama, dan kapan cache harus dibersihkan.

Jika TTFB tinggi, lihat PHP-FPM dan aplikasi

Pada website berbasis PHP, PHP-FPM mengelola proses yang menjalankan skrip PHP. Jika semua worker sedang sibuk, permintaan baru harus menunggu. Namun, menaikkan jumlah worker secara asal juga bisa membuat RAM habis dan server mulai melakukan swap.

Periksa metrik seperti:

• Jumlah worker aktif, idle, dan yang mencapai batas maksimal.
• Waktu tunggu antrean proses.
• Penggunaan RAM setiap worker.
• Endpoint atau halaman yang paling sering memakan waktu.
• Slow log PHP-FPM untuk menemukan skrip dengan eksekusi panjang.

PHP-FPM memang menyediakan pengaturan proses, status, dan slow log untuk membantu menemukan skrip yang lambat. Itu lebih berguna daripada sekadar menebak nilai pm.max_children. Naikkan kapasitas hanya setelah mengetahui konsumsi memori per proses dan pola trafik website. ([php.net](https://www.php.net/manual/en/install.fpm.php?utm_source=openai))

Di level aplikasi, cari operasi yang terjadi pada setiap request: pemanggilan API eksternal, perulangan data besar, pembuatan gambar, atau pemuatan terlalu banyak plugin. Proses berat yang tidak harus selesai sebelum respons dikirim sebaiknya dipindahkan ke antrean pekerjaan atau dijalankan setelah respons, dengan tetap memperhatikan keandalan dan keamanan.

Gunakan MySQL untuk menemukan query yang benar-benar lambat

Database sering dituduh sebagai penyebab utama, padahal tidak semua query perlu dioptimalkan. Mulailah dari slow query log untuk menemukan query yang berulang dan melewati ambang waktu tertentu. Setelah itu, gunakan EXPLAIN untuk melihat bagaimana MySQL memilih tabel, indeks, dan urutan join.

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

Perhatikan apakah query membaca terlalu banyak baris, melakukan full table scan pada tabel besar, atau mengurutkan data tanpa bantuan indeks yang sesuai. Indeks dapat mempercepat pembacaan, tetapi terlalu banyak indeks juga memperbesar penggunaan storage dan membuat operasi insert, update, serta delete lebih mahal. Dokumentasi MySQL menyarankan penggunaan EXPLAIN untuk memeriksa rencana eksekusi dan menyeimbangkan manfaat indeks dengan biayanya. ([dev.mysql.com](https://dev.mysql.com/doc/refman/8.4/en/execution-plan-information.html?utm_source=openai))

Yang bisa dilakukan sekarang

1. Pilih satu halaman yang lambat dan catat URL, waktu pengujian, perangkat, serta lokasi.
2. Ukur TTFB dan waktu total sebelum melakukan perubahan.
3. Bandingkan halaman yang sudah terkena cache dengan halaman yang selalu dinamis.
4. Periksa waterfall di browser untuk menemukan file yang menahan tampilan.
5. Aktifkan atau tinjau slow log PHP-FPM dan MySQL dalam periode terbatas.
6. Uji query penting dengan EXPLAIN sebelum menambah indeks.
7. Ubah satu hal setiap kali, lalu ukur ulang dengan kondisi yang serupa.

Performa yang baik bukan hasil dari satu tombol “optimalkan”. Ia biasanya datang dari kebiasaan mengukur, mengisolasi masalah, lalu memperbaiki bagian yang paling berdampak.

Apa artinya bagi pemilik website?

Website cepat bukan berarti semua angka harus sempurna. Target yang lebih berguna adalah pengalaman yang konsisten: halaman utama tampil tanpa menunggu lama, interaksi terasa responsif, dan server tetap stabil saat trafik naik.

Karena itu, jangan menjadikan upgrade server sebagai langkah pertama. Pastikan dulu apakah masalahnya berada di jaringan, cache, browser, PHP-FPM, atau MySQL. Setelah sumbernya jelas, Anda bisa memilih solusi yang lebih kecil, lebih murah, dan biasanya lebih tahan lama.

Sumber & bacaan lebih lanjut

• Getting started with measuring Web Vitals
• How the Core Web Vitals metrics thresholds were defined
• Cache-Control header - HTTP | MDN
• HTTP caching - HTTP | MDN
• PHP: FastCGI Process Manager (FPM) - Manual
• MySQL 8.4 Reference Manual: Understanding the Query Execution Plan
• MySQL 8.4 Reference Manual: EXPLAIN Statement
• MySQL 8.4 Reference Manual: Optimization and Indexes

– Rio Yotto @rioyotto