Cara Membuat Website Lebih Cepat: Daftar Periksa Praktis

Untuk membuat website lebih cepat, ukur dulu dengan PageSpeed Insights, lalu perbaiki penyebab terbesar yang ditunjukkannya — biasanya gambar berukuran terlalu besar, JavaScript yang berlebihan, font berat, atau skrip pihak ketiga. Targetkan kategori "baik" dari Core Web Vitals Google: konten utama terlihat dalam 2,5 detik, respons terhadap ketukan dalam 200 milidetik, dan hampir tidak ada tata letak yang melompat. Kebanyakan situs mencapainya dengan beberapa perubahan, bukan dengan menulis ulang.

Ukur sebelum mengubah apa pun

Menebak hanya membuang waktu. Dua alat gratis mencakup hampir semua kebutuhan:

PageSpeed Insights (pagespeed.web.dev) — tempelkan URL aktif. Alat ini menampilkan data lapangan dari pengguna Chrome sungguhan (jika situs Anda cukup banyak pengunjung) dan data lab dari pemuatan simulasi, plus daftar masalah spesifik.
Lighthouse di Chrome DevTools — tes lab yang sama, dijalankan di halaman mana pun yang bisa Anda buka, termasuk pratinjau. Uji dalam mode seluler; ponsel dengan jaringan lebih lambat adalah tempat masalah terlihat.

Angka yang penting adalah Core Web Vitals Google. Per September 2026, dokumentasi Google di web.dev memberikan ambang "baik" berikut, diukur pada persentil ke-75 dari pemuatan halaman:

Metrik	Yang diukur	Baik
Largest Contentful Paint (LCP)	Seberapa cepat konten utama (gambar hero, judul) muncul	2,5 d atau kurang
Interaction to Next Paint (INP)	Seberapa cepat halaman bereaksi terhadap klik, ketukan, dan pengetikan	200 md atau kurang
Cumulative Layout Shift (CLS)	Seberapa banyak tata letak melompat saat memuat	0,1 atau kurang

INP menggantikan metrik First Input Delay yang lama pada 2024. Jika alat masih melaporkan FID, berarti sudah usang.

Catat angka awal Anda. Setelah setiap perbaikan, uji lagi agar Anda tahu apa yang membantu.

Waktu terbuang di mana: pilihan dan konsekuensinya

Setiap penyebab umum punya perbaikan, dan setiap perbaikan punya biaya. Mulailah dari yang di atas — paling murah dan paling sering.

Penyebab	Perbaikan umum	Konsekuensi
Gambar besar	Ubah ukuran sesuai tampilan, kompres, pakai WebP atau AVIF	Sedikit penurunan kualitas jika terlalu dikompres
Gambar dimuat dengan urutan yang salah	Lazy-load gambar di bawah lipatan; beri prioritas tinggi pada gambar hero	Tidak ada, asalkan hero tidak di-lazy-load
JavaScript terlalu banyak	Pisahkan kode per halaman, hapus pustaka yang tidak dipakai	Perlu sedikit refaktor
Rendering hanya di sisi klien	Prarender atau server-render halaman publik	Perlu pengaturan build atau server yang lebih
Font web	Kurangi jumlah keluarga dan ketebalan, preload yang utama, `font-display: swap`	Variasi tipografi lebih sedikit
Skrip pihak ketiga	Hapus yang tidak dipakai, muat sisanya setelah halaman	Kehilangan widget atau pelacak
Respons server lambat	Caching, CDN, hosting statis untuk halaman konten	Perlu memikirkan invalidasi cache

Gambar

Gambar adalah masalah paling umum dan paling mudah diperbaiki. Foto 4.000 piksel yang ditampilkan pada lebar 800 piksel memaksa setiap pengunjung mengunduh lima kali lebih banyak dari yang mereka lihat.

Sajikan gambar pada ukuran tampilannya, dengan ukuran srcset yang responsif untuk ponsel dan desktop.
Gunakan format modern (WebP atau AVIF) dan kompresi yang masuk akal.
Atur width dan height pada setiap gambar agar browser menyiapkan ruangnya. Ini saja sudah memperbaiki sebagian besar pergeseran tata letak.
Lazy-load gambar di bawah lipatan dengan loading="lazy".
Jangan pernah me-lazy-load gambar utama di bagian atas halaman. Panduan LCP Google sangat tegas soal ini: lazy-loading gambar LCP selalu menunda pemuatannya. Berikan fetchpriority="high" sebagai gantinya.

JavaScript

Banyak situs yang dibangun AI adalah aplikasi satu halaman (SPA): browser mengunduh bundel JavaScript lalu menggambar halaman. Semakin besar bundelnya, semakin lama layar kosong. Perbaikan, diurutkan dari usaha paling kecil:

Hapus yang tidak Anda pakai. Minta daftar dependensi dan potong pustaka yang ditambahkan sekali lalu terlupakan — pustaka tanggal untuk satu tanggal, paket ikon lengkap untuk lima ikon.
Pisahkan per rute. Muat kode dasbor admin hanya saat seseorang membukanya, bukan di halaman beranda.
Prarender halaman publik. Halaman pemasaran yang dikirim sebagai HTML sungguhan akan muncul sebelum JavaScript apa pun berjalan. Ini juga membantu mesin pencari; lihat SEO untuk website yang dibangun AI.

INP yang lambat biasanya berarti satu tugas panjang memblokir halaman — misalnya memfilter daftar besar pada setiap ketukan tombol, atau merender ulang seluruh tabel ketika satu sel berubah. Panel Performance di Chrome DevTools menunjukkan yang mana.

Font

Setiap keluarga font dan ketebalan adalah file lain. Dua keluarga dan tiga atau empat ketebalan biasanya sudah cukup. Preload font yang dipakai di atas lipatan, gunakan font-display: swap agar teks langsung tampil, dan host font sendiri jika layanan font eksternal lambat bagi pengunjung Anda.

Skrip pihak ketiga

Widget chat, analitik, heatmap, piksel iklan, video tertanam, dan umpan media sosial semuanya memuat kode dari server lain. Masing-masing terlihat kecil; bersama-sama, sering kali menjadi bagian paling lambat dari halaman. Simpan yang benar-benar Anda pantau. Muat sisanya setelah halaman siap berinteraksi, dan ganti embed berat (pemutar YouTube, peta) dengan pratinjau ringan yang memuat konten sebenarnya saat diklik.

Respons server

Time to first byte (TTFB) — berapa lama server membutuhkan waktu untuk mulai menjawab — berada di bawah setiap metrik lainnya. Halaman statis yang disajikan dari CDN (jaringan server yang dekat dengan pengunjung Anda; lihat apa itu CDN) cepat hampir di mana saja. Halaman yang dibangun server pada setiap permintaan bergantung pada server itu dan databasenya. Caching pekerjaan yang berulang dan menambahkan indeks database untuk kueri lambat adalah perbaikan yang umum.

Prompt yang berhasil

Jadilah spesifik: sebutkan halaman, metrik, dan batasannya. Tempelkan temuan PageSpeed Insights jika Anda memilikinya.

PageSpeed Insights melaporkan LCP 4,8 d di seluler untuk halaman beranda, dan elemen LCP-nya adalah gambar hero. Ubah ukuran dan konversi gambar hero ke WebP, sajikan ukuran responsif, atur width dan height, beri fetchpriority="high", dan pastikan tidak di-lazy-load. Lazy-load setiap gambar di bawah lipatan. Jangan ubah desain.

Audit dependensi aplikasi ini. Daftar setiap paket, apa yang memakainya, dan kira-kira seberapa besar tambahannya pada bundel. Hapus yang tidak dipakai dan pisahkan rute /admin dan /settings menjadi bagian terpisah yang hanya dimuat saat dikunjungi.

Kotak pencarian di /products terasa lambat. Tunda filter (debounce), hindari merender ulang seluruh daftar pada setiap ketukan, dan paginasi atau virtualisasi daftar jika berisi lebih dari 200 item.

Langkah demi langkah

Uji halaman aktif di PageSpeed Insights pada seluler. Catat LCP, INP, dan CLS, serta tiga masalah teratas yang tercantum.
Perbaiki gambar lebih dulu: ukuran, format, dimensi, lazy loading di bawah lipatan, prioritas untuk hero.
Potong skrip pihak ketiga yang tidak Anda pakai, dan tunda sisanya.
Pangkas font sesuai kebutuhan desain.
Kecilkan JavaScript: hapus paket yang tidak dipakai, pisahkan per rute.
Prarender halaman publik jika masih dirender di sisi klien dan LCP masih lambat.
Periksa server: caching, indeks database, hosting statis untuk konten yang jarang berubah.
Terbitkan ulang dan uji lagi. Data lapangan di PageSpeed Insights diperbarui selama beberapa minggu berikutnya saat kunjungan nyata masuk, jadi nilai hasil awal berdasarkan data lab.

Kesalahan yang umum

Hanya menguji di laptop cepat. Pengunjung Anda memakai ponsel kelas menengah dan data seluler yang tidak stabil. Uji dalam mode seluler.
Mengejar angka 100 yang sempurna. Skor lab hanyalah panduan. Setelah Core Web Vitals berada di rentang baik, konten dan kegunaan lebih penting daripada beberapa poin terakhir.
Me-lazy-load semuanya, termasuk gambar hero. Itu membuat LCP lebih buruk.
Menambahkan plugin atau pustaka percepatan di atas. Menghapus beban hampir selalu lebih baik daripada menambah kode untuk mengelolanya.
Mengoptimalkan pratinjau, bukan situs aktif. Pratinjau pengembangan menjalankan build yang belum dioptimalkan. Ukur URL yang sudah dipublikasikan.
Memperbaiki kecepatan sekali saja. Setiap widget, gambar, dan fitur baru menambah beban. Uji ulang setelah perubahan besar.

Daftar periksa kecepatan

LCP ≤ 2,5 d, INP ≤ 200 md, CLS ≤ 0,1 di seluler
Gambar diubah ukurannya, dikompres, format modern, dengan width dan height
Gambar hero tidak di-lazy-load; gambar di bawah lipatan di-lazy-load
Tidak ada pustaka JavaScript yang tidak dipakai; rute berat dipisahkan
Dua keluarga font atau kurang, font utama di-preload
Hanya skrip pihak ketiga yang benar-benar dipakai, dimuat belakangan
Halaman publik diprarender atau statis jika memungkinkan
Diuji ulang di URL aktif setelah dipublikasikan

Kecepatan dan tata letak seluler saling terkait; lihat cara membuat website responsif di seluler. Untuk pemeriksaan pra-peluncuran yang lengkap, cara membawa prototipe AI ke produksi membahas sisanya.

Kecepatan di Mythex

Di Mythex Anda membuat perubahan ini dengan meminta lewat chat, atau di editor kode pada Pro. Periksa URL yang sudah dipublikasikan, bukan Preview, karena Preview menjalankan server pengembangan. Front end statis di-deploy sebagai situs statis saat Anda mempublikasikan (situs statis), yang cocok untuk halaman konten. Aplikasi dengan server akan tidur (scale to zero) saat tidak aktif dan bangun pada kunjungan berikutnya, jadi permintaan pertama setelah jeda yang lama lebih lambat, dan database yang terpasang tidur setelah 5 menit tidak aktif (batas hosting). Jika halaman publik lambat hanya pada kunjungan pertama, itulah penyebab yang mungkin. Menjaga halaman pemasaran tetap statis membantu. Setelah perubahan, publikasikan ulang dan muat ulang paksa.

Pertanyaan

Berapa waktu muat halaman yang baik?

Core Web Vitals dari Google memberi target paling jelas: konten utama harus muncul dalam 2,5 detik (LCP), halaman harus merespons input dalam 200 milidetik (INP), dan pergeseran tata letak harus tetap 0,1 atau kurang (CLS), diukur pada persentil ke-75 dari kunjungan nyata.

Apakah kecepatan situs memengaruhi SEO?

Ya, sedikit. Google memakai sinyal pengalaman halaman termasuk Core Web Vitals, tetapi konten yang relevan jauh lebih penting. Kecepatan berdampak lebih besar bagi pengunjung, yang meninggalkan halaman lambat sebelum sempat membaca apa pun.

Mengapa skor PageSpeed Insights saya berbeda setiap kali?

Skor lab berasal dari satu pemuatan simulasi, sehingga waktu jaringan dan server bervariasi antar-pengujian. Jalankan beberapa kali dan lihat tren-nya, serta beri bobot lebih pada bagian data lapangan, yang berasal dari pengguna Chrome sungguhan.

Apa yang paling memperlambat kebanyakan website?

Biasanya gambar berukuran terlalu besar, JavaScript yang terlalu banyak, font web, dan skrip pihak ketiga seperti widget chat, piksel iklan, dan embed. Respons server yang lambat atau backend yang butuh waktu untuk menyala juga menambah semuanya.