Website loading 6 detik? Conversion turun 40%. Kamu bukan Netflix — user nggak akan nunggu. Ini 7 penyebab paling umum dan cara debug pakai Chrome DevTools — gratis, tanpa New Relic atau Datadog.
Ceritanya begini: Saya buka website klien. Loading bar jalan pelan. Satu detik. Dua detik. Lima detik. Tujuh detik. Saya tutup tab.
Bukan Netflix. Bukan Amazon. Website UMKM sederhana yang jual kerupuk. Tapi loading-nya lebih lambat dari loading psychological horror game.
Masalahnya: pemiliknya sudah bayar mahal untuk “optimasi SEO” — tapi tidak ada yang ngomong soal kecepatan. Padahal setiap 1 detik keterlambatan, konversi turun 7% (Amazon, 2017). Kalau website muat 6 detik, itu 40% pelanggan hilang sebelum lihat produk.
Berita baik: kamu tidak perlu Datadog, New Relic, atau tools berbayar. Cukup Chrome DevTools — sudah ada gratis di browser kamu. Ini 7 penyebab paling umum lengkap dengan cara debug-nya.
Tools yang Kamu Butuhkan
- Chrome DevTools — F12 atau klik kanan → Inspect
- Network tab — lihat semua file yang di-download, ukuran, dan waktunya
- Lighthouse tab — audit otomatis, kasih skor + rekomendasi
- Coverage tab — lihat CSS/JS mana yang tidak terpakai
Tiga tab di satu browser. Tidak perlu install apa-apa lagi.
Penyebab 1: Gambar Super Besar
Ini penyebab nomor satu. Paling sering, paling gampang kamu perbaiki sendiri.
Website klien kerupuk tadi punya gambar produk 5MB — untuk foto kerupuk ukuran 800x600px. 5MB untuk gambar yang muat di layar HP? Itu sama seperti antar pizza pakai truk 20 roda.
Cara debug:
- Buka tab Network di DevTools (F12)
- Refresh halaman
- Klik kolom Size — urutkan dari size terbesar
- Cari file gambar ukuran >500KB
- Klik gambar itu → lihat dimensinya. Kalau lebih besar dari yang muncul di layar, itu pemborosan.
Fix:
- Kompres pakai Squoosh (squoosh.app) — gratis, offline, dari Google
- Ukuran maksimal: 200KB untuk gambar besar di hero section, 50-80KB untuk gambar biasa
- Format: WebP kalau bisa. Fallback JPG — bundar
- Tool CLI:
npx sharp-cli --input gambar.jpg --output gambar.webp --quality 80
Dampak: Gambar 5MB → 80KB = loading turun dari 3 detik jadi 0.3 detik. Untuk gambar itu sendiri.
Penyebab 2: Terlalu Banyak HTTP Request
Setiap file CSS, JS, font, gambar = satu request HTTP. Koneksi HP di Indonesia rata-rata butuh 100-300ms per request (latency tinggi). Kalau website kamu butuh 150 file, itu 15-45 detik cuma untuk negosiasi koneksi — belum hitung downloadnya.
Cara debug:
- Network tab → lihat angka di kiri bawah: “X requests, Y KB transferred”
- Target: kurang dari 50 request untuk halaman sederhana, kurang dari 100 untuk halaman kompleks
- Lihat yang blocking: waterfall chart — file batang warna biru panjang artinya lama
Fix:
- Gabung CSS jadi 1 file (kalau masih pakai cara lama)
- Gabung JS jadi 1-2 file
- Hapus plugin yang nambah banyak CSS/JS tanpa guna
- Gunakan resource hints:
<link rel="preload">untuk file penting,<link rel="preconnect">untuk domain eksternal
Kasus nyata: Website WordPress dengan 30 plugin bisa request 120+ file. Setelah audit, 15 plugin tidak berguna — hapus, request turun 60, loading turun 3 detik.
Penyebab 3: Render-Blocking Resources
Beberapa file CSS dan JS punya kekuatan super: mereka bisa memblokir seluruh halaman. Browser tidak mau menggambar apa pun sampai file ini selesai download dan proses.
Cara debug:
- Tab Lighthouse → Generate report
- Lihat “Eliminate render-blocking resources” — itu daftarnya
- Atau manual: Network tab → lihat file CSS/JS yang muncul di awal waterfall sebelum halaman mulai render
Fix:
- CSS kritis (critical CSS) — inline langsung di
<head> - CSS sisanya:
<link rel="preload">atau<link media="print" onload="this.media='all'"> - JS yang tidak perlu untuk render awal: tambah
deferatauasync - Tools: Critical (npm package) atau plugin WordPress seperti WP Rocket, Flying Pages
Ini fix yang paling berdampak untuk First Contentful Paint (FCP). Biasanya FCP langsung naik 0.5-1 detik.
Penyebab 4: Font yang Bikin Nunggu
Google Font keren, tapi default loading-nya bikin teks tidak kelihatan selama 2-3 detik. Fenomena ini punya nama FOIT (Flash of Invisible Text) — pengguna lihat halaman putih kosong padahal konten sudah sampai.
Cara debug:
- Network tab → filter “font”
- Refresh → lihat berapa lama font selesai download
- Perhatikan: apakah teks muncul sebelum font selesai atau setelahnya?
Fix:
- Tambah
font-display: swapdi @font-face CSS — teks pakai font sistem dulu, baru ganti setelah font custom selesai download - Self-host Google Font — hindari request eksternal yang kena latency tambahan
- Gunakan
<link rel="preconnect" href="https://fonts.googleapis.com"> - Batasi jumlah font: maksimal 2 varian (regular + bold cukup)
Self-hosting font bisa potong 200-400ms dari loading time, terutama untuk pengguna di Indonesia dengan latency tinggi.
Penyebab 5: Caching Tidak Ada atau Rusak
Bayangkan kamu download aplikasi yang sama setiap kali mau pakai. Itu yang kamu alami kalau caching tidak atur dengan benar.
Cara debug:
- Network tab → lihat kolom Size
- File dari server: ukurannya terlihat (misal: 500KB)
- File dari cache: tulisannya (disk cache) atau (memory cache)
- Refresh halaman sekali lagi. Kalau file masih download dari server (bukan cache), caching rusak.
Fix:
- Set header
Cache-Control: max-age=31536000untuk file statis (CSS, JS, gambar) - Gunakan fingerprinting: nama file berubah setiap versi (
style.a1b2c3.css) - Kalau pakai Nginx:
add_header Cache-Control - Kalau pakai Apache: mod_expires atau htaccess
- WordPress: instal caching plugin (W3 Total Cache, WP Super Cache, atau Flying Press)
Dengan caching benar, repeat visit bisa 2-4 detik lebih cepat karena browser simpan file statis dan tidak perlu download ulang.
Penyebab 6: Hosting Murah, Kinerja Murahan
Hosting 20rb/bulan mungkin cocok untuk website HTML statis. Tapi untuk WordPress dengan PHP, MySQL, dan 30 plugin? Itu seperti minta mobil pick-up mengangkut 20 ton pasir.
Cara debug:
- Network tab → lihat TTFB (Time to First Byte) — kolom “Waiting (TTFB)”
- TTFB normal: 200-500ms. TTFB di atas 1 detik = masalah server
- Coba tes dari GTmetrix atau webpagetest.org pilih lokasi server yang dekat dengan audiens kamu
Fix:
- Upgrade hosting — cari yang pake SSD + PHP 8.x + object cache (Redis)
- Pakai CDN (Cloudflare gratis sudah cukup untuk mayoritas website Indonesia)
- Kalau pakai VPS: pastikan PHP-FPM, OPcache, dan MySQL query cache aktif
- Alternative: pindah ke static site generator (Hugo, 11ty) — hosting jadi murah lagi karena tinggal kirim file HTML
Realitas: Banyak website UKM Indonesia hosting di shared server yang satu mesin bagi untuk 100+ website. Kalau tetangga server kena DDOS atau spike traffic, website kamu ikut lemot. Pindah ke VPS murah (Rp60-100rb/bulan) dengan Cloudflare sudah memberi peningkatan drastis.
Penyebab 7: JavaScript Berantakan
Ini penyebab paling susah di-debug karena butuh pemahaman kode. Tapi dampaknya besar: JS yang lambat bisa freeze halaman selama 1-3 detik.
Cara debug:
- Tab Performance di DevTools → Record → interaksi dengan halaman → Stop
- Lihat bagian Main — task yang panjang (garis kuning/merah) artinya JS block proses rendering
- Tab Coverage → reload → lihat CSS/JS mana yang tidak terpakai (garis merah)
- Target: JS yang tidak terpakai di bawah 30%
Fix:
- Code splitting — pisahkan JS untuk halaman tertentu saja
- Tree shaking — hapus kode yang tidak berguna dari bundle
- Gunakan
Intersection Observeruntuk lazy loading komponen di bawah lipatan - Hindari
document.write— itu blocking dan lambat - Audit library: jQuery masih kamu pakai? Kalau cuma untuk selector, ganti vanilla JS
Framework modern (React, Vue, Svelte) sebenarnya punya tooling bawaan untuk ini. Masalahnya: banyak developer skip optimasi ini karena “nanti aja” — dan “nanti” tidak pernah datang.
Prioritas Fix — Urutan dari yang Paling Berdampak
Kamu tidak harus fix semua sekaligus. Ini urutan dari yang paling berdampak:
| Prioritas | Fix | Estimasi Dampak | Waktu |
|---|---|---|---|
| 1 | Kompres gambar + WebP | 1-4 detik | 30 menit |
| 2 | Render-blocking resources | 0.5-2 detik | 1-2 jam |
| 3 | Cache headers + fingerprinting | 1-3 detik (repeat visit) | 1 jam |
| 4 | Curigai plugin tidak perlu | 0.5-2 detik | 2 jam |
| 5 | Font self-host + font-display:swap | 0.2-0.5 detik | 30 menit |
| 6 | Hosting + CDN | 0.5-3 detik (TTFB) | 1-2 hari (migrasi) |
| 7 | JS optimization | 0.3-1 detik | 3-8 jam |
Kerjakan nomor 1-4 di akhir pekan. Website kamu sudah jauh lebih cepat dalam 4 jam kerja. Sisanya menyusul nanti.
Kesimpulan — Pola Pikir Baru tentang Performa
Tiga hal yang saya harap kamu bawa pulang dari artikel ini:
- Performa bukan fitur — performa adalah UX. Website lambat = pengalaman buruk, berapa pun bagusnya desain kamu.
- Tools mahal tidak perlu. Chrome DevTools, Squoosh, GTmetrix — semua gratis. Yang kurang bukan tools-nya, tapi kebiasaan ngecek.
- Mulai dari yang paling berdampak. 20% usaha (kompres gambar + render-blocking) memberi 80% hasil. Jangan buang waktu untuk optimasi mikro yang cuma menghemat 50ms.
Buka Chrome DevTools sekarang. Cek website kamu. Network tab, refresh, lihat file mana yang paling besar. Mulai dari situ.
Website yang cepat bukan soal ego developer. Ini soal rasa hormat pada waktu pengguna.