Mengurangi CSS & JavaScript yang Tidak Terpakai dan Render-blocking
Dua saran yang sangat sering muncul di hasil Lighthouse adalah "Hilangkan resource yang memblokir render" dan "Kurangi JavaScript/CSS yang tidak digunakan". Keduanya berkaitan dengan cara browser membaca halaman. Memahami prosesnya membuat perbaikan jauh lebih mudah.
Bagaimana browser menampilkan halaman
Saat membuka halaman, browser membaca HTML dari atas ke bawah. Ketika bertemu file CSS di <head>, browser menunggu file itu selesai diunduh sebelum menampilkan apa pun, karena tanpa CSS tampilan belum bisa dihitung. Ketika bertemu <script> biasa tanpa atribut khusus, browser berhenti membaca HTML, mengunduh skrip, menjalankannya, baru melanjutkan. File-file yang membuat browser menunggu seperti ini disebut render-blocking.
Semakin banyak dan semakin besar file render-blocking, semakin lama layar tetap kosong. Ini terlihat pada FCP dan LCP yang lambat.
Menunda JavaScript dengan defer dan async
Cara termudah mengatasi JavaScript yang memblokir adalah menambahkan atribut:
<script src="/js/app.js" defer></script>
<script src="https://contoh-analytics.com/tag.js" async></script>
- defer – skrip diunduh bersamaan dengan pembacaan HTML dan dijalankan setelah HTML selesai dibaca, dengan urutan tetap terjaga. Cocok untuk sebagian besar skrip website.
- async – skrip diunduh paralel dan dijalankan segera setelah selesai, tanpa urutan pasti. Cocok untuk skrip mandiri seperti analytics.
Skrip yang tidak dibutuhkan untuk tampilan awal sebaiknya memakai defer. Jika ada skrip yang bergantung pada skrip lain (misalnya plugin jQuery), pastikan keduanya memakai defer agar urutannya tetap benar.
Menangani CSS render-blocking
CSS tidak bisa sekadar ditunda, karena halaman akan tampil tanpa gaya lalu berubah tiba-tiba. Pendekatan yang umum dipakai:
- CSS kritis (critical CSS). Ambil aturan CSS yang dibutuhkan untuk tampilan layar pertama, letakkan langsung di
<style>di dalam<head>, lalu muat sisa CSS tanpa memblokir. - Pisahkan CSS per halaman. Jangan muat CSS untuk toko, forum, dan galeri di halaman artikel yang tidak membutuhkannya.
- Gunakan atribut media. CSS khusus cetak bisa dimuat dengan
media="print"sehingga tidak memblokir tampilan layar.
<link rel="stylesheet" href="/css/print.css" media="print">
Membuat CSS kritis secara manual cukup rumit. Banyak plugin cache WordPress dan alat build (misalnya paket "critical" untuk Node.js) bisa melakukannya otomatis.
Menghapus kode yang tidak terpakai
Tema dan library sering membawa kode untuk fitur yang tidak Anda pakai. Untuk melihatnya:
- Buka halaman di Chrome, tekan F12 untuk membuka DevTools.
- Buka menu (tiga titik) > More tools > Coverage.
- Muat ulang halaman. Coverage menunjukkan persentase kode setiap file yang tidak dijalankan.
Persentase tinggi tidak selalu berarti kode itu bisa dibuang, karena sebagian dipakai di halaman lain atau setelah interaksi. Namun ini petunjuk bagus untuk menemukan library besar yang sebenarnya tidak diperlukan.
Langkah praktis:
- Hapus plugin atau library yang fiturnya tidak dipakai, misalnya slider yang sudah tidak ditampilkan.
- Ganti library besar dengan alternatif ringan atau JavaScript bawaan browser. Banyak fungsi jQuery kini bisa ditulis dengan JavaScript biasa.
- Gunakan alat build modern (Vite, esbuild, webpack) yang mendukung tree shaking untuk membuang kode yang tidak diimpor.
- Muat skrip hanya di halaman yang membutuhkannya. Misalnya, skrip formulir kontak cukup di halaman kontak.
Minify dan kompresi
Minify menghapus spasi, komentar, dan memendekkan nama variabel tanpa mengubah fungsi. Hasilnya file lebih kecil. Kompresi di server (gzip atau Brotli) mengecilkan file lebih jauh saat dikirim. Keduanya saling melengkapi. Lihat Kompresi Gzip dan Brotli.
Memecah JavaScript (code splitting)
Pada aplikasi web modern, seluruh JavaScript sering dibundel menjadi satu file besar. Dengan code splitting, kode dibagi per halaman atau per fitur dan dimuat saat dibutuhkan:
document.querySelector('#buka-peta').addEventListener('click', async () => {
const { tampilkanPeta } = await import('./peta.js');
tampilkanPeta();
});
Dengan cara ini, kode peta yang berat hanya diunduh saat pengguna benar-benar membukanya.
Mengurangi tugas panjang
Selain ukuran file, waktu eksekusi juga penting. Tugas JavaScript yang berjalan lebih dari 50 milidetik disebut tugas panjang dan dihitung dalam Total Blocking Time. Untuk menguranginya, pecah pekerjaan besar menjadi bagian kecil, tunda pekerjaan yang tidak mendesak, dan hindari memproses data besar saat halaman pertama dimuat.
Preload dan preconnect seperlunya
<link rel="preconnect" href="https://cdn.contoh.com">membuka koneksi lebih awal ke domain lain yang pasti dipakai.<link rel="preload">memberi tahu browser agar segera mengunduh file penting, misalnya font utama atau gambar LCP.
Gunakan seperlunya. Terlalu banyak preload membuat browser bingung menentukan prioritas dan bisa memperlambat hal yang lebih penting.
Urutan kerja yang disarankan
- Tambahkan
deferpada skrip yang tidak dibutuhkan untuk tampilan awal. - Hapus plugin, library, dan skrip pihak ketiga yang tidak dipakai.
- Minify dan aktifkan kompresi di server.
- Pisahkan CSS/JS per halaman dan terapkan CSS kritis.
- Uji ulang di webmaster.my.id dan periksa apakah tampilan serta fungsi website tetap normal.
Perubahan ini bisa merusak fitur jika dilakukan terlalu agresif. Lakukan bertahap, uji setiap perubahan, dan simpan cadangan sebelum memulai.
Contoh sebelum dan sesudah
Sebelum perbaikan, bagian head sebuah halaman memuat tiga file CSS dan dua skrip tanpa atribut:
<link rel="stylesheet" href="/css/bootstrap.css">
<link rel="stylesheet" href="/css/slider.css">
<link rel="stylesheet" href="/css/style.css">
<script src="/js/jquery.js"></script>
<script src="/js/slider.js"></script>
Browser harus mengunduh dan memproses kelima file ini sebelum menampilkan apa pun. Setelah perbaikan:
<style>/* CSS penting untuk bagian atas halaman */</style>
<link rel="stylesheet" href="/css/app.min.css" media="print" onload="this.media='all'">
<script src="/js/app.min.js" defer></script>
CSS dan JavaScript digabung serta dikecilkan, CSS penting dimasukkan langsung, dan skrip ditunda dengan defer. Slider yang hanya dipakai di beranda tidak lagi dimuat di halaman lain.
Checklist render-blocking
- Semua skrip di
headmemakaideferatauasync, kecuali yang benar-benar harus berjalan lebih dulu. - Skrip yang saling bergantung memakai
defer, karena urutannya tetap terjaga. - CSS penting untuk tampilan atas halaman disisipkan langsung jika ukurannya kecil.
- CSS dan JavaScript diminify dan dikompres.
- Kode yang hanya dipakai di halaman tertentu tidak dimuat di semua halaman.
- Laporan Coverage di Chrome DevTools dipakai untuk melihat kode yang tidak terpakai.
- Setiap perubahan diuji di beberapa halaman dan perangkat.
Kesalahan umum
- Memakai
asyncuntuk skrip yang saling bergantung. Urutan eksekusiasynctidak terjamin, sehingga skrip bisa error. - Menunda CSS utama tanpa CSS penting. Halaman tampil tanpa gaya sejenak, lalu berubah. Ini mengganggu dan bisa menambah CLS.
- Inline CSS terlalu besar. CSS yang disisipkan tidak bisa disimpan di cache browser secara terpisah, jadi sisipkan hanya bagian yang penting.
- Preload terlalu banyak file. Preload yang berlebihan membuat file penting justru bersaing dan dimuat lebih lambat.
- Lupa menghapus cache setelah mengubah file. Gunakan nama file berversi agar pengunjung mendapatkan versi terbaru.
Pertanyaan yang sering diajukan
Apa bedanya defer dan async?
Keduanya mengunduh skrip tanpa menghentikan proses HTML. Skrip defer dijalankan setelah HTML selesai diproses dan sesuai urutan, sedangkan async dijalankan begitu selesai diunduh tanpa memperhatikan urutan.
Apakah jQuery harus dihapus?
Tidak harus. Jika tema atau plugin bergantung padanya, menghapusnya bisa merusak situs. Yang bisa dilakukan adalah memuatnya dengan defer jika memungkinkan, atau mengurangi kode yang bergantung padanya secara bertahap.
Bagaimana cara membuat CSS penting?
Ada alat otomatis seperti fitur "critical CSS" di plugin optimasi WordPress atau pustaka Critical untuk situs statis. Hasilnya tetap perlu dicek agar tampilan atas halaman tidak berantakan.
Apakah minify mengubah tampilan situs?
Tidak. Minify hanya menghapus spasi, komentar, dan karakter yang tidak diperlukan. Jika tampilan rusak setelah minify, biasanya ada kesalahan penggabungan file, bukan minify itu sendiri.
Apakah semua saran render-blocking harus dihilangkan?
Tidak selalu. Satu file CSS kecil yang penting untuk tampilan biasanya masih wajar. Fokuslah pada file besar dan skrip yang tidak dibutuhkan untuk menampilkan bagian atas halaman, lalu ukur dampaknya terhadap FCP dan LCP setelah setiap perubahan. Jika penghematan yang diperkirakan sangat kecil, prioritaskan masalah lain.
Bagaimana memastikan situs tidak rusak setelah optimasi?
Uji alur penting seperti menu, formulir, keranjang, dan checkout di ponsel dan desktop setelah setiap perubahan. Simpan cadangan pengaturan agar mudah dikembalikan jika ada masalah.