Skip to main content

Optimasi Kecepatan Website: Urutan Perbaikan dari yang Paling Berdampak

Panduan mempercepat website — cara menemukan penyebab sebenarnya, urutan perbaikan dari yang paling murah, dan hal yang sering dikerjakan tanpa hasil.

Optimasi Kecepatan Website: Urutan Perbaikan dari yang Paling Berdampak

Mulai dari Menemukan Penyebabnya

Sebagian besar usaha mempercepat website terbuang karena dimulai dari daftar tips, bukan dari mengukur di mana waktunya sebenarnya habis.

Situs yang lambat karena gambar besar butuh perlakuan yang sama sekali berbeda dari situs yang lambat karena server merespons lima detik. Menjalankan seluruh daftar tips pada keduanya akan menghabiskan waktu untuk sebagian besar hal yang tidak relevan.

Karena itu langkah pertamanya selalu sama: buka PageSpeed Insights untuk beberapa halaman yang paling banyak dikunjungi, dan lihat pemecahan waktunya, bukan skornya.

Pemecahan tersebut membantu menentukan apakah masalah utamanya berada di LCP, INP, atau di luar metrik tersebut.

Empat Tempat Waktu Bisa Habis

  • Respons server — jeda sebelum byte pertama sampai. Kalau angkanya sudah lebih dari satu detik, ini yang dikerjakan lebih dulu dan tidak ada gunanya menyentuh yang lain.
  • Pengunduhan sumber daya — gambar, huruf, CSS, dan JavaScript. Biasanya penyumbang terbesar di situs berbasis CMS.
  • Pemrosesan di peramban — menjalankan skrip dan menyusun tampilan. Penyumbang terbesar di situs berbasis kerangka kerja modern.
  • Pihak ketiga — pelacak, obrolan, peta, dan iklan. Sering jadi penyumbang besar yang tidak terlihat karena bukan bagian dari kode Anda sendiri.

Urutan Perbaikan

Disusun dari yang paling murah dan paling sering berdampak:

  1. Perbaiki gambar. Ubah ukurannya sesuai tampilnya, kompres ke format modern, cantumkan dimensinya, dan jangan tunda pemuatan gambar yang tampil pertama. Satu langkah ini menyelesaikan sebagian besar kasus di situs biasa.
  2. Aktifkan caching halaman. Untuk situs berbasis CMS, ini sering memangkas waktu respons server berkali lipat.
  3. Tinjau ulang skrip pihak ketiga. Buang yang tidak dipakai lagi, dan muat sisanya setelah halaman siap. Hampir setiap situs punya minimal satu pelacak warisan yang tidak pernah dicabut.
  4. Kurangi CSS dan JavaScript yang menghalangi render di bagian <head>.
  5. Perbaiki pemuatan huruf — muat lebih awal, pakai font-display: swap, dan kurangi jumlah variasinya.
  6. Pasang CDN kalau pengunjung tersebar di banyak wilayah.
  7. Naikkan kelas hosting kalau waktu respons server masih tinggi setelah caching aktif.
  8. Kurangi jumlah plugin yang masing-masing memuat berkasnya sendiri.

Yang Sering Dikerjakan Tanpa Hasil

  • Mengejar skor mendekati seratus. Skor Lighthouse adalah hasil uji laboratorium; yang dinilai Google adalah data kunjungan nyata.
  • Memasang beberapa plugin optimasi sekaligus, yang sering saling bertabrakan dan justru memperlambat.
  • Minifikasi tanpa menyentuh gambar. Menghemat beberapa kilobita sementara gambarnya berukuran megabita.
  • Berganti hosting sebelum memeriksa apakah masalahnya memang di waktu respons server.
  • Mengoptimasi beranda saja, padahal sebagian besar pengunjung mendarat di halaman dalam dari hasil pencarian.

Menguji dengan Benar

  • Uji halaman yang paling banyak dikunjungi, bukan hanya beranda.
  • Uji dari perangkat dan jaringan yang menyerupai pengunjung Anda, bukan dari komputer kerja dengan koneksi kantor.
  • Pakai pembatasan jaringan di alat pengembang untuk melihat keadaan yang lebih jujur.
  • Bandingkan data lapangan dengan data laboratorium. Kalau laboratorium bagus tapi lapangan buruk, masalahnya ada di perangkat atau jaringan sebagian pengunjung.
  • Ukur ulang setelah tiap perubahan, satu per satu, supaya tahu mana yang bekerja.

Kaitannya dengan SEO

Kecepatan masuk ke penilaian lewat Core Web Vitals, yang merupakan satu dari beberapa hal yang disarankan Google diperiksa dalam pengalaman halaman — bukan faktor tunggal.

Untuk ambang setiap metrik dan cara membacanya di data lapangan, lihat Core Web Vitals.

Yang perlu ditempatkan sesuai bobotnya: halaman yang isinya tidak menjawab tidak akan tertolong oleh angka kecepatan yang bagus. Sebaliknya, halaman lambat pada bidang yang persaingannya ketat kehilangan pengunjung sebelum isinya sempat dinilai — dan itu kerugian yang terjadi di luar urusan peringkat.

Pertanyaan Umum Seputar Kecepatan Website

Berapa waktu muat yang ideal?

Yang dipakai sebagai acuan bukan waktu muat total, melainkan LCP di bawah 2,5 detik pada persentil ke-75 kunjungan. Angka “muat di bawah 3 detik” yang beredar tidak merujuk pengukuran resmi mana pun.

Apakah plugin cache cukup?

Untuk situs berbasis CMS, ia menyelesaikan sebagian besar masalah respons server — tapi tidak menyentuh gambar besar maupun skrip pihak ketiga, yang biasanya penyumbang terbesar berikutnya.

Kenapa situs saya cepat di komputer tapi lambat di ponsel?

Karena prosesor ponsel lebih lemah dan jaringannya lebih tidak stabil. Beban JavaScript yang tidak terasa di komputer bisa jadi penyumbang utama di perangkat kelas menengah.

Jika masalah berulang berasal dari tumpukan plugin atau cara halaman dihasilkan, bandingkan juga framework modern dan WordPress sebelum memutuskan rebuild.