Website Lemot? Ini Urutan Perbaikan Kecepatan yang Benar — candidateseo
Beranda/ Fase 3 · Teknis/ Website Lemot? Urutan Perbaikan Kecepatan
● Fase 3 · Teknis

Website Lemot? Ini Urutan Perbaikan Kecepatan yang Benar

★ 4.7 1,2rb dibaca 9 mnt baca AH Ditinjau oleh Ari H., praktisi WordPress & SEO aktif
Website Lemot, Ini Urutan Perbaikan Kecepatan yang Benar
 
Daftar Isi Artikel

Website yang lambat bukan cuma bikin pengunjung kesal — Google juga secara eksplisit menjadikan kecepatan situs sebagai salah satu faktor peringkat. Masalahnya, kebanyakan pemula langsung mengoprek semua hal sekaligus tanpa tahu mana yang paling berdampak, lalu kelelahan sebelum melihat hasilnya.

Artikel ini menyusun perbaikan kecepatan dalam urutan yang benar — dari yang paling murah dan paling cepat dampaknya, sampai yang paling mahal dan sebaiknya jadi opsi terakhir.

Kecepatan website juga langsung memengaruhi berapa banyak pengunjung yang bertahan membaca. Riset dari berbagai penyedia analitik menunjukkan pola yang konsisten: makin lama halaman dimuat, makin besar kemungkinan pengunjung menutup tab sebelum sempat membaca kontennya sama sekali — artinya, kecepatan bukan cuma soal peringkat Google, tapi juga soal seberapa banyak usaha menulismu benar-benar sampai ke pembaca.

Yang akan kamu selesaikan setelah membaca ini

  • Tahu skor kecepatan website saat ini
  • Gambar sudah dikompresi dan dioptimasi
  • Plugin yang tidak perlu sudah dibersihkan
  • Caching sudah aktif
  • Tahu kapan waktunya harus ganti hosting

01Kenapa Urutan Perbaikan Itu Penting

Godaan terbesar saat website terasa lambat adalah langsung ganti hosting mahal, padahal penyebab sebenarnya sering kali cuma satu gambar berukuran 8MB yang lupa dikompres. Membenahi hal mahal sebelum hal murah bukan cuma boros, tapi juga bisa membuatmu salah menyimpulkan "sudah ganti hosting tapi tetap lambat" — padahal masalah aslinya belum tersentuh sama sekali.

Urutan di artikel ini disusun berdasarkan rasio dampak dibanding usaha: mulai dari yang paling murah dan cepat dikerjakan, baru naik ke yang lebih rumit kalau memang masih diperlukan.

Prinsip ini sebenarnya berlaku umum di banyak bidang perbaikan teknis: selesaikan dulu hal-hal yang biayanya nol tapi dampaknya besar, baru pertimbangkan investasi lebih besar kalau memang benar-benar dibutuhkan. Melompat langsung ke solusi mahal tanpa mengecek hal dasar dulu adalah kesalahan yang paling sering membuat anggaran perbaikan website membengkak tanpa hasil yang sepadan.

02Langkah 1 — Cek Skor Kecepatan Dulu

Sebelum memperbaiki apa pun, kamu perlu angka pembanding. Buka PageSpeed Insights (pagespeed.web.dev) dari Google, masukkan alamat websitemu, lalu catat skornya untuk versi mobile dan desktop.

pagespeed.web.dev

Perhatikan juga bagian "Opportunities" di laporan itu — Google biasanya sudah menunjukkan urutan prioritas perbaikan berdasarkan seberapa besar dampaknya terhadap skor. Simpan screenshot skor awal ini sebagai pembanding "sebelum", supaya nanti kamu bisa mengukur langsung dampak dari tiap langkah yang dilakukan.

Selain PageSpeed Insights, tools seperti GTmetrix memberi detail tambahan berupa "waterfall chart" — visualisasi urutan setiap file yang dimuat beserta waktunya. Untuk pemula, detail ini belum wajib dipahami mendalam; cukup gunakan sebagai referensi kedua kalau ingin memastikan hasil dari PageSpeed Insights.

03Langkah 2 — Optimasi Gambar

Gambar biasanya jadi penyumbang terbesar ukuran halaman. Untungnya, ini juga perbaikan termurah dan paling cepat dampaknya.

  • Kompres gambar sebelum upload menggunakan tools gratis seperti TinyPNG atau Squoosh.
  • Gunakan format WebP yang ukurannya jauh lebih kecil dibanding JPG/PNG dengan kualitas visual setara.
  • Jangan upload gambar berukuran asli kamera (bisa 5–10MB) — resize dulu ke ukuran tampil sebenarnya di website.
  • Aktifkan lazy loading supaya gambar di bawah layar baru dimuat saat pengunjung scroll ke sana.
i

Banyak plugin optimasi gambar gratis untuk WordPress bisa mengompresi otomatis setiap kali kamu upload, jadi tidak perlu dikerjakan manual satu per satu.

Sebagai gambaran dampaknya: foto langsung dari kamera HP modern bisa berukuran 4–8MB. Setelah dikompresi dan diubah ke WebP dengan ukuran tampil yang sesuai, ukurannya bisa turun ke kisaran 100–300KB tanpa penurunan kualitas visual yang terlihat mata telanjang. Kalau satu artikel memuat lima gambar seukuran itu, selisihnya bisa mencapai puluhan megabyte — dan itu semua harus diunduh perangkat pengunjung setiap kali halaman dibuka.

04Langkah 3 — Audit dan Kurangi Plugin

Setiap plugin menambah beban yang harus dimuat website, meski plugin itu tidak sedang benar-benar dipakai. Semakin banyak plugin tidak terpakai yang menumpuk, semakin berat website harus bekerja di setiap kunjungan.

Nonaktifkan lalu hapus plugin yang sudah tidak dipakai sama sekali
Cek apakah ada dua plugin dengan fungsi yang sama (mis. dua plugin SEO sekaligus)
Perhatikan plugin yang memuat script di semua halaman padahal hanya dipakai di satu halaman

Contoh yang sering terjadi: plugin formulir kontak yang memuat script-nya di semua halaman website, padahal formulir itu hanya ada di halaman "Kontak". Idealnya, script semacam ini hanya dimuat di halaman yang memang membutuhkannya — beberapa plugin modern sudah cukup pintar melakukan ini secara otomatis, tapi tidak semua, sehingga tetap perlu dicek manual sesekali.

05Langkah 4 — Aktifkan Caching

Tanpa caching, server harus membangun ulang halaman dari nol setiap kali ada pengunjung baru. Dengan caching, versi halaman yang sudah jadi disimpan dan langsung disajikan ke pengunjung berikutnya — hasilnya, waktu muat bisa turun drastis tanpa mengubah desain atau konten sama sekali.

Plugin caching populer untuk WordPress biasanya cukup diaktifkan dengan pengaturan default untuk mendapat peningkatan kecepatan yang terasa. Pengaturan lanjutan seperti minifikasi CSS/JS bisa dijajal setelah caching dasar berjalan stabil.

Analoginya seperti restoran yang memasak ulang dari nol setiap kali ada pesanan menu yang sama, dibanding menyiapkan bahan dasar terlebih dulu sehingga pesanan berikutnya bisa disajikan lebih cepat. Caching pada dasarnya melakukan hal yang sama untuk halaman website — hasil "masakan" yang sama tidak perlu dibuat ulang dari awal untuk setiap pengunjung.

06Langkah 5 — Evaluasi Hosting (Kalau Langkah 1–4 Belum Cukup)

Hosting sengaja diletakkan paling akhir karena biasanya bukan penyebab utama pada website yang masih baru — dan mengganti hosting butuh biaya lebih besar dibanding empat langkah sebelumnya. Baru pertimbangkan langkah ini kalau skor kecepatan masih rendah meski gambar sudah dioptimasi, plugin sudah dibersihkan, dan caching sudah aktif.

Kalau memang sampai di titik ini, upgrade tidak selalu berarti pindah penyedia hosting sepenuhnya. Banyak penyedia menawarkan upgrade paket di dalam layanan yang sama, yang jauh lebih sederhana secara teknis dibanding migrasi penuh ke penyedia lain — pertimbangkan opsi ini dulu sebelum memutuskan pindah total.

TandaKemungkinan Penyebab
Lambat hanya saat trafik ramaiKapasitas hosting kurang
Lambat terus meski trafik sepiKemungkinan bukan hosting
Waktu respons server (TTFB) tinggiHosting jadi kandidat kuat

07Self-Check Cepat

Skor PageSpeed sudah dicatat sebagai pembanding "sebelum"
Semua gambar besar sudah dikompresi dan pakai lazy loading
Plugin tidak terpakai sudah dihapus
Plugin caching sudah aktif

08Kesalahan Umum Pemula

  • Langsung ganti hosting sebagai langkah pertama, padahal penyebabnya sering kali jauh lebih murah untuk diperbaiki — dan pindah hosting sendiri butuh waktu serta risiko teknis tambahan.
  • Menginstal banyak plugin "speed booster" sekaligus, yang justru saling bentrok dan membuat website makin lambat atau bahkan error, karena beberapa plugin caching tidak dirancang untuk berjalan bersamaan.
  • Tidak mencatat skor awal, sehingga tidak bisa mengukur apakah perbaikan yang dilakukan benar-benar berdampak atau hanya perasaan subjektif semata.
  • Berhenti setelah satu langkah lalu kecewa karena skor belum naik banyak, padahal dampaknya baru terasa signifikan setelah beberapa langkah dikerjakan sekaligus secara kumulatif.
  • Mengoptimasi kecepatan lalu lupa mengecek ulang tampilan website — beberapa teknik seperti lazy loading atau minifikasi kadang butuh penyesuaian kecil supaya tidak merusak tampilan visual.
AH
Ditinjau oleh Ari H.

Praktisi yang menangani optimasi kecepatan untuk website klien — urutan lima langkah ini disusun berdasarkan rasio dampak dan biaya yang paling sering terbukti efektif di lapangan.

09Checklist Sebelum Lanjut

Skor kecepatan sudah membaik dibanding sebelum perbaikan
Sudah tahu kapan harus mempertimbangkan upgrade hosting

Konten sudah solid, kecepatan sudah dibenahi — kamu resmi menyelesaikan Fase 3. Langkah berikutnya masuk ke Fase 4 — Naik Level, dimulai dari memahami white hat, grey hat, dan black hat sebelum mulai membangun otoritas lewat off-page.

Sampai di titik ini, website yang tadinya cuma "hidup" sudah punya fondasi teknis, konten, dan kecepatan yang layak bersaing — bekal yang cukup solid sebelum masuk ke strategi yang lebih lanjut.

FAQPertanyaan Umum

Secara umum, skor di atas 90 dianggap sangat baik, 50–89 cukup, dan di bawah 50 perlu perbaikan. Tapi yang lebih penting dari angka mutlak adalah tren perbaikannya dari waktu ke waktu.

Ya. Tema dengan banyak fitur bawaan yang tidak dipakai bisa menambah beban yang sama seperti plugin berlebihan. Kalau lima langkah di atas sudah dilakukan tapi kecepatan masih kurang, tema juga layak dicurigai.

Skor teknis seperti PageSpeed bisa langsung berubah begitu perbaikan diterapkan. Tapi dampaknya ke peringkat pencarian butuh waktu lebih lama, biasanya beberapa minggu, karena Google perlu mengukur ulang performa situsmu secara konsisten.

Belum wajib untuk website baru dengan trafik masih kecil. CDN lebih terasa manfaatnya saat pengunjung sudah datang dari berbagai lokasi geografis yang jauh dari server hosting utama.

Kemungkinan ada faktor lain di luar lima langkah dasar, seperti tema yang terlalu berat, query database yang tidak efisien, atau serangan bot yang membebani server tanpa disadari. Di titik ini biasanya sudah layak berkonsultasi dengan penyedia hosting atau praktisi teknis untuk diagnosis lebih mendalam.

Lanjutkan ke Fase 4 — Naik Level

Fondasi teknis sudah solid. Langkah berikutnya: memahami white hat, grey hat, dan black hat sebelum mulai membangun otoritas.

Mulai Fase 4 →