Website Lambat Tidak Selalu karena Server: Cara Membaca Jejak Loading dari Browser sampai Database

Ketika website terasa lambat, solusi yang sering muncul adalah menambah CPU, memindahkan hosting, atau memasang plugin cache baru. Kadang langkah itu membantu. Namun, tidak jarang masalahnya justru ada di gambar hero yang terlalu besar, query database yang menunggu terlalu lama, atau JavaScript pihak ketiga yang baru berjalan setelah halaman terlihat.

Website tidak menjadi cepat hanya karena satu komponen diganti. Browser harus meminta HTML, menerima respons server, mengambil CSS dan JavaScript, memuat gambar, menghitung tata letak, lalu menggambar halaman ke layar. Rangkaian ini dikenal sebagai critical rendering path—jalur yang dilalui browser untuk mengubah kode menjadi tampilan yang bisa dilihat pengguna. MDN menjelaskan bahwa proses tersebut melibatkan DOM, CSSOM, render tree, layout, dan painting.

Mulai dari pertanyaan paling sederhana: lambatnya terjadi di mana?

Anggap proses membuka halaman seperti memesan makanan. Ada waktu untuk restoran menerima pesanan, menyiapkan makanan, mengantarkannya, lalu pelanggan membuka kemasan. Jika makanan terlambat dibuat, masalahnya berbeda dengan jalan yang macet atau kemasan yang sulit dibuka.

Pada website, pembagiannya kurang lebih seperti ini:

• Sebelum server menjawab: waktu DNS, koneksi, TLS, dan pengalihan URL.
• Saat server bekerja: proses aplikasi, PHP, pemanggilan API, dan query database.
• Saat browser memuat halaman: CSS, JavaScript, font, gambar, serta resource pihak ketiga.
• Saat halaman digunakan: event JavaScript, animasi, formulir, dan perubahan tata letak.

Karena sumber masalahnya berbeda, pengukuran harus dilakukan sebelum optimasi. Gunakan PageSpeed Insights atau Chrome DevTools untuk melihat waterfall—urutan waktu setiap request—bukan hanya skor ringkas. Skor berguna sebagai sinyal, tetapi waterfall sering memberi petunjuk yang lebih konkret.

1. Periksa TTFB sebelum menyalahkan gambar

TTFB atau Time to First Byte adalah waktu sejak browser meminta halaman sampai byte pertama respons diterima. Angka ini mencakup beberapa bagian seperti koneksi, pengalihan, dan waktu server menyiapkan respons. Chrome menjelaskan bahwa TTFB bukan sekadar waktu eksekusi aplikasi di server; DNS dan redirect juga dapat ikut menyumbang keterlambatan.

Jika TTFB halaman utama sudah tinggi, mengecilkan gambar belum tentu menyelesaikan masalah pertama yang dirasakan pengguna. Cari penyebab dari sisi server, misalnya:

• halaman dinamis melakukan terlalu banyak query database;
• proses PHP menunggu API eksternal;
• object cache tidak bekerja atau sering kosong;
• PHP-FPM kehabisan worker sehingga request mengantre;
• halaman yang seharusnya bisa di-cache selalu dibuat ulang.

Dalam praktik, bandingkan tiga kondisi: halaman yang belum login, halaman yang sudah di-cache, dan halaman dinamis setelah login. Jika halaman publik cepat saat cache hangat tetapi lambat ketika cache kosong, masalah utama mungkin ada di proses pembuatan halaman, bukan kapasitas jaringan.

2. Bedakan halaman sudah muncul dengan halaman sudah siap dipakai

Halaman yang menampilkan judul belum tentu siap digunakan. Browser mungkin masih mengunduh JavaScript besar, menunggu font, atau menjalankan skrip yang memblokir interaksi.

Salah satu metrik penting adalah Largest Contentful Paint (LCP), yaitu waktu sampai elemen konten terbesar yang terlihat di area layar selesai dirender. Untuk pengalaman yang baik, target yang umum digunakan adalah LCP maksimal 2,5 detik pada persentil ke-75 kunjungan. Elemen LCP bisa berupa gambar utama, video, atau blok teks besar—bukan selalu gambar.

Jika LCP buruk, periksa elemen yang ditandai oleh alat pengujian. Beberapa langkah yang biasanya relevan:

1. Gunakan ukuran gambar yang sesuai dengan tampilan, bukan mengirim gambar 4000 piksel untuk area selebar 800 piksel.
2. Pilih format modern bila kompatibel dengan alur kerja website, lalu kompres gambar tanpa mengorbankan keterbacaan.
3. Jangan menerapkan lazy loading pada gambar utama yang langsung terlihat di layar.
4. Kurangi CSS dan JavaScript yang harus diunduh sebelum konten utama tampil.
5. Pastikan font penting tidak menunda teks utama terlalu lama.

Perlu diingat, preload bukan tombol “percepat semua”. Memuat terlalu banyak resource secara bersamaan bisa membuat bandwidth berebut. Panduan web.dev juga menekankan bahwa preload perlu dipakai untuk resource yang benar-benar kritis.

3. Cari JavaScript yang membuat browser sibuk

Setelah HTML dan CSS diterima, browser masih harus mengurai dan menjalankan JavaScript. Skrip yang besar atau banyak dapat menghambat proses parsing, layout, dan respons terhadap klik.

Perhatikan apakah keterlambatan hanya muncul setelah pengguna menekan tombol. Jika ya, server mungkin tidak bermasalah. Penyebabnya bisa berupa handler klik yang menjalankan terlalu banyak pekerjaan, tabel yang merender ribuan baris sekaligus, atau library analitik yang mengikat banyak event.

Pisahkan JavaScript berdasarkan kebutuhan. Fitur yang diperlukan saat halaman pertama dibuka boleh dimuat lebih awal. Fitur yang hanya digunakan di halaman tertentu sebaiknya dimuat saat dibutuhkan. Untuk daftar panjang, gunakan pagination atau virtualisasi agar browser tidak menggambar semua item sekaligus.

4. Jangan abaikan layout yang bergeser

Website bisa terasa “lambat” walaupun kontennya sudah tampil, terutama jika pengguna terus kehilangan posisi baca karena elemen bergerak. Ini diukur melalui Cumulative Layout Shift (CLS), metrik yang menggambarkan ketidakstabilan tata letak.

Penyebab umum CLS adalah gambar tanpa dimensi, iklan atau iframe tanpa ruang yang disiapkan, serta font yang mengubah ukuran teks setelah selesai dimuat. Solusinya sederhana tetapi harus konsisten: tetapkan atribut width dan height pada gambar, sediakan ruang untuk embed, dan uji strategi font di perangkat nyata.

Web.dev merekomendasikan CLS 0,1 atau lebih rendah untuk pengalaman yang baik pada setidaknya 75 persen kunjungan.

5. Langkah diagnosis yang bisa dilakukan sekarang

1. Uji halaman yang sama tiga kali. Catat apakah hasil berubah jauh antara cache dingin dan cache hangat.
2. Lihat waterfall. Cari request yang paling lama, rantai redirect, dan file yang menunggu request lain.
3. Bandingkan TTFB dengan waktu render. TTFB tinggi mengarah ke server atau jaringan; TTFB rendah tetapi LCP tinggi mengarah ke asset dan proses browser.
4. Periksa log aplikasi dan database. Cari query berulang, endpoint eksternal yang lambat, serta request yang menunggu terlalu lama.
5. Uji tanpa skrip pihak ketiga. Matikan sementara chat widget, iklan, tag analitik, atau tool A/B testing untuk melihat dampaknya.
6. Ubah satu hal setiap kali. Jika cache, kompresi gambar, dan konfigurasi JavaScript diubah bersamaan, Anda akan sulit mengetahui perubahan mana yang benar-benar berhasil.

Apa artinya bagi kita?

Optimasi website bukan perlombaan mengejar satu skor. Tujuannya adalah mengurangi waktu tunggu yang paling dirasakan pengguna: halaman mulai menjawab, konten utama terlihat, tombol cepat merespons, dan tata letak tidak berantakan.

Jika TTFB tinggi, mulai dari aplikasi, database, cache, dan antrean server. Jika TTFB sehat tetapi LCP buruk, periksa gambar, CSS, font, dan resource kritis. Jika halaman sudah terlihat tetapi klik terasa tertunda, audit JavaScript. Dengan membagi masalah berdasarkan tahapnya, keputusan tuning menjadi lebih murah, terukur, dan tidak bergantung pada tebakan.

Sumber & bacaan lebih lanjut

• Critical rendering path — MDN Web Docs
• Reduce server response times — Chrome for Developers
• Largest Contentful Paint (LCP) — web.dev
• Optimize Largest Contentful Paint — web.dev
• Preload critical assets to improve loading speed — web.dev
• Optimize Cumulative Layout Shift — web.dev

– Rio Yotto @rioyotto