Cara Mengurangi Beban JavaScript agar Website Lebih Cepat
Website yang terasa lambat tidak selalu disebabkan oleh server atau ukuran gambar. File JavaScript yang terlalu besar, terlalu banyak dijalankan saat halaman pertama kali dibuka, atau memproses pekerjaan berat di main thread juga dapat membuat halaman terlambat tampil dan kurang responsif saat digunakan.
Solusinya bukan sekadar melakukan minifikasi semua file JavaScript. Kamu perlu mengetahui skrip mana yang menjadi bottleneck, menentukan JavaScript yang benar-benar dibutuhkan saat halaman pertama dibuka, kemudian mengurangi pekerjaan browser secara bertahap sambil mengukur hasil setiap perubahan.
Dalam panduan ini, kamu akan melakukan optimasi dengan alur audit → identifikasi masalah → optimasi JavaScript → optimasi pengiriman aset → pengujian ulang. Pendekatan tersebut membuat optimasi lebih terukur dibandingkan menerapkan banyak teknik sekaligus tanpa mengetahui sumber masalahnya.
Kenapa JavaScript Bisa Membuat Website Terasa Lambat?
Saat membuka halaman, browser tidak hanya mengambil HTML dan menampilkannya kepada pengguna. Browser juga perlu memproses CSS, mengunduh JavaScript, menjalankan kode, memperbarui DOM, menghitung layout, dan menampilkan hasilnya pada layar.
Kamu dapat mempelajari proses tersebut lebih lengkap melalui artikel cara kerja browser saat menampilkan halaman website. Dengan memahami proses ini, kamu akan lebih mudah menentukan bagian yang harus dioptimalkan.
Masalah biasanya muncul ketika browser menerima terlalu banyak pekerjaan JavaScript pada awal pemuatan halaman. Beberapa kondisi yang perlu diperhatikan antara lain:
- ukuran bundle JavaScript terlalu besar;
- banyak kode dikirim tetapi tidak pernah digunakan;
- skrip pihak ketiga dimuat pada semua halaman;
- JavaScript menghambat proses parsing HTML;
- pekerjaan berat berjalan terlalu lama pada main thread;
- event handler menjalankan proses yang terlalu kompleks;
- komponen yang belum dibutuhkan ikut dimuat sejak awal; dan
- file JavaScript selalu diunduh ulang karena konfigurasi cache kurang optimal.
Masalah tersebut dapat memengaruhi pengalaman pengguna secara langsung. Halaman mungkin terlihat sudah terbuka, tetapi tombol, menu, atau form baru merespons beberapa saat setelah pengguna mencoba berinteraksi.
Mulai dari Audit, Jangan Langsung Mengubah Kode
Optimasi sebaiknya dimulai dengan pengukuran agar kamu mengetahui sumber masalah yang sebenarnya. Tanpa baseline, kamu tidak dapat mengetahui apakah perubahan yang dilakukan benar-benar membuat website lebih cepat atau hanya memindahkan bottleneck ke bagian lain.
1. Uji Halaman dengan PageSpeed Insights
Masukkan URL halaman yang ingin diuji ke Google PageSpeed Insights, kemudian perhatikan hasil pengujian pada perangkat mobile terlebih dahulu. Pengguna mobile biasanya memiliki keterbatasan CPU, memori, dan koneksi yang lebih besar dibandingkan pengguna desktop sehingga masalah JavaScript lebih mudah terlihat.
Kamu tidak perlu langsung mengejar skor 100. Prioritaskan rekomendasi yang menunjukkan masalah seperti Reduce unused JavaScript, waktu eksekusi JavaScript yang tinggi, pekerjaan main thread yang berat, atau resource yang menghambat pemuatan halaman.
Jika kamu belum terbiasa membaca hasil pengujian tersebut, kamu dapat mempelajari terlebih dahulu cara kerja PageSpeed dan penggunaannya untuk mengevaluasi kecepatan website.
2. Periksa Network di Chrome DevTools
Selanjutnya, buka halaman menggunakan Chrome lalu masuk ke DevTools → Network. Pilih filter JS untuk melihat seluruh file JavaScript yang diunduh oleh browser beserta ukuran dan waktu pemuatannya.
Urutkan file berdasarkan ukuran untuk menemukan JavaScript terbesar. Periksa juga apakah ada library, widget, tracker, atau script eksternal yang sebenarnya hanya dibutuhkan pada halaman tertentu tetapi ikut dimuat di seluruh website.
3. Cari Kode yang Tidak Digunakan dengan Coverage
File berukuran besar belum tentu menjadi masalah jika sebagian besar kodenya memang dibutuhkan. Sebaliknya, bundle yang sebagian besar tidak digunakan akan memaksa browser mengunduh, melakukan parsing, dan memproses kode yang tidak memberikan manfaat pada halaman tersebut.
Kamu dapat membuka DevTools → Command Menu → Show Coverage, kemudian melakukan reload halaman. Chrome akan menunjukkan bagian CSS dan JavaScript yang digunakan maupun tidak digunakan selama pengujian.
Cara Mengurangi Beban JavaScript pada Website
Setelah menemukan sumber masalah, kamu dapat menentukan optimasi berdasarkan bottleneck yang ditemukan. Jangan menerapkan seluruh teknik sekaligus karena setiap website mempunyai struktur, framework, plugin, dan kebutuhan JavaScript yang berbeda.
1. Hapus JavaScript yang Tidak Lagi Dibutuhkan
Langkah pertama sebaiknya bukan menambahkan tool optimasi baru, melainkan menghapus kode yang tidak memberikan fungsi nyata. Semakin sedikit JavaScript yang dikirim ke browser, semakin sedikit pula data yang perlu diunduh, diparsing, dikompilasi, dan dieksekusi.
Periksa library lama, widget yang sudah tidak digunakan, eksperimen A/B yang telah selesai, script analytics ganda, serta fitur frontend yang sebenarnya sudah dihapus. Website WordPress juga perlu diperiksa karena tema dan plugin dapat menambahkan file JavaScript secara otomatis pada halaman yang sebenarnya tidak membutuhkan file tersebut.
Sebagai contoh, plugin formulir mungkin hanya digunakan pada halaman Kontak. Jika file JavaScript plugin tersebut tetap dimuat pada halaman blog, produk, dan landing page, browser harus memproses resource tambahan tanpa memberikan fungsi kepada pengunjung.
2. Gunakan defer untuk Script yang Tidak Harus Dieksekusi Saat Parsing
Script JavaScript biasa dapat menghentikan proses parsing HTML ketika browser harus mengunduh dan mengeksekusinya terlebih dahulu. Untuk script yang tidak harus dijalankan sebelum struktur halaman selesai dibaca, atribut defer dapat digunakan.
|
1 |
<script src="/js/app.js" defer></script> |
Dengan defer, browser tetap dapat mengambil file JavaScript tanpa menghentikan proses parsing HTML. Script tersebut kemudian dijalankan setelah dokumen selesai diproses dan urutan script dengan defer tetap dapat dipertahankan.
Namun, jangan menambahkan defer secara massal tanpa pengujian. Script tertentu dapat memiliki dependensi atau membutuhkan urutan eksekusi tertentu sehingga perubahan cara pemuatan dapat menyebabkan fungsi website tidak berjalan.
3. Gunakan async untuk Script yang Independen
Atribut async cocok untuk JavaScript yang dapat bekerja secara independen dan tidak bergantung pada script lain. Browser dapat mengambil file tersebut sambil tetap memproses halaman, lalu mengeksekusinya segera setelah file selesai diunduh.
|
1 |
<script src="/js/analytics.js" async></script> |
Perbedaannya dengan defer terletak pada waktu dan urutan eksekusi. Script async tidak menjamin urutan eksekusi, sehingga jangan menggunakannya pada kumpulan script yang saling bergantung.
| Metode | Cocok untuk | Urutan eksekusi |
|---|---|---|
defer |
Script yang membutuhkan DOM atau mempunyai dependensi | Dipertahankan sesuai urutan dokumen |
async |
Script independen seperti beberapa script pihak ketiga | Tidak dijamin |
4. Pecah Bundle dan Muat Fitur Hanya Saat Dibutuhkan
Website modern dapat memiliki satu bundle JavaScript yang berisi kode untuk banyak halaman sekaligus. Pengguna akhirnya harus mengunduh kode untuk slider, dashboard, editor, checkout, atau fitur lain meskipun halaman yang sedang dibuka tidak menggunakannya.
Pendekatan code splitting membagi JavaScript menjadi beberapa bagian yang dapat dimuat sesuai kebutuhan. Salah satu implementasinya adalah menggunakan import() dinamis untuk memuat modul ketika fungsi tertentu benar-benar digunakan.
|
1 2 3 4 5 6 |
const tombolGaleri = document.querySelector('#buka-galeri'); tombolGaleri.addEventListener('click', async () => { const galeri = await import('./galeri.js'); galeri.buka(); }); |
Pada contoh tersebut, kode untuk galeri tidak perlu menjadi bagian dari beban awal halaman. Browser baru mengambil modul ketika pengguna benar-benar mencoba membuka galeri.
Teknik ini sangat berguna untuk modal, editor, grafik, peta, galeri besar, atau komponen interaktif lain yang tidak langsung diperlukan saat halaman pertama kali ditampilkan.
5. Evaluasi Script Pihak Ketiga
JavaScript pihak ketiga sering luput dari audit karena kode tersebut tidak dibuat oleh developer website. Padahal live chat, heatmap, analytics, iklan, social widget, video embed, consent manager, dan berbagai tracker dapat menambah request serta pekerjaan pada browser.
Buat daftar setiap script pihak ketiga dan tentukan fungsi bisnisnya. Jika dua tool mengumpulkan data yang sama atau sebuah script sudah tidak digunakan, menghapusnya sering memberikan hasil yang lebih nyata dibandingkan mengoptimalkan beberapa baris kode internal.
Kamu juga dapat menunda script yang tidak dibutuhkan pada tampilan awal. Misalnya, widget chat dapat dipertimbangkan untuk dimuat setelah halaman utama selesai atau setelah pengguna mulai berinteraksi, selama implementasinya tidak mengganggu fungsi utama website.
6. Kurangi Pekerjaan Berat pada Main Thread
Browser menggunakan main thread untuk banyak pekerjaan penting, termasuk menjalankan JavaScript dan menangani interaksi pengguna. Jika sebuah proses JavaScript berjalan terlalu lama, browser tidak dapat merespons klik, input, atau navigasi dengan cepat.
Periksa bagian Performance di Chrome DevTools untuk mencari tugas JavaScript yang menghabiskan waktu besar. Jika satu proses melakukan banyak pekerjaan sekaligus, pecah pekerjaan tersebut menjadi bagian yang lebih kecil atau jalankan proses hanya ketika benar-benar dibutuhkan.
Masalah ini terutama penting untuk halaman interaktif karena berkaitan dengan kemampuan website merespons input pengguna. Jika kamu sedang mengevaluasi performa pengalaman pengguna secara keseluruhan, baca juga panduan optimasi Core Web Vitals agar perbaikannya tidak hanya berfokus pada skor loading.
7. Hindari Manipulasi DOM yang Berulang
JavaScript sering digunakan untuk menambahkan, menghapus, atau memperbarui elemen HTML. Namun, perubahan DOM yang dilakukan berulang kali dapat memicu browser menghitung ulang style dan layout secara lebih sering daripada yang diperlukan.
Sebaiknya kelompokkan perubahan yang berkaitan dan hindari membaca serta mengubah layout secara bergantian di dalam loop yang panjang. Untuk komponen yang memperbarui banyak elemen sekaligus, ukur performanya melalui DevTools agar kamu dapat melihat apakah proses rendering menjadi bottleneck.
Optimalkan Cara File JavaScript Dikirim dari Server
Setelah kode JavaScript lebih efisien, tahap berikutnya adalah memastikan file tersebut dikirim kepada pengguna dengan efektif. Optimasi pada tahap ini berbeda dari optimasi eksekusi JavaScript karena fokusnya berada pada ukuran transfer, cache, dan jarak pengiriman resource.
1. Aktifkan Kompresi Brotli atau Gzip
File JavaScript berbasis teks dapat dikompresi sebelum dikirim dari server ke browser. Ukuran transfer yang lebih kecil mengurangi jumlah data yang harus diunduh pengguna, terutama saat koneksi jaringan tidak stabil.
Salah satu metode yang umum digunakan pada web modern adalah Brotli. Kamu dapat membaca pembahasan mengenai cara kerja kompresi Brotli pada website untuk memahami perbedaannya dengan file yang dikirim tanpa kompresi.
2. Atur Browser Cache untuk File Statis
JavaScript yang tidak berubah pada setiap kunjungan tidak harus selalu diunduh ulang dari server. Cache browser dapat menyimpan file tersebut sehingga kunjungan berikutnya dapat menggunakan resource yang sudah tersedia secara lokal.
Pada aplikasi yang menggunakan proses build, kamu dapat menggunakan nama file berbasis hash seperti app.a84f21.js. Ketika isi JavaScript berubah, proses build menghasilkan nama baru sehingga browser dapat menyimpan versi lama dalam waktu panjang tanpa membuat pengguna tertahan pada file yang sudah usang.
3. Pertimbangkan CDN untuk Pengunjung dari Banyak Lokasi
Jika website melayani pengunjung dari berbagai wilayah, CDN dapat membantu mendistribusikan aset statis seperti JavaScript dari lokasi yang lebih dekat dengan pengguna. Pendekatan ini mengurangi ketergantungan seluruh request aset terhadap satu origin server.
Kamu dapat mempelajari fungsi CDN untuk website atau melihat contoh penerapan cache dan CDN menggunakan Cloudflare. Namun, CDN tetap tidak dapat memperbaiki JavaScript yang membutuhkan waktu eksekusi terlalu lama di browser sehingga optimasi kode tetap harus dilakukan.
Kapan Masalahnya Bukan Lagi JavaScript?
JavaScript bukan satu-satunya komponen yang menentukan kecepatan website. Browser mungkin sudah menerima bundle JavaScript yang ringan, tetapi halaman tetap lambat apabila server membutuhkan waktu terlalu lama untuk memberikan HTML atau resource yang dibutuhkan pengguna.
Kamu dapat membedakan masalah tersebut melalui pengujian. Jika waktu respons server tinggi sebelum browser mulai menerima halaman, fokuskan investigasi pada hosting, database, aplikasi backend, cache server, atau konfigurasi web server.
Sebaliknya, jika respons server sudah cepat tetapi setelah halaman diterima browser masih membutuhkan waktu lama untuk memproses JavaScript, meningkatkan resource hosting belum tentu menyelesaikan masalah tersebut. Bottleneck pada sisi browser tetap membutuhkan optimasi frontend.
Bagaimana JavaScript Berkaitan dengan Core Web Vitals?
Optimasi JavaScript sebaiknya tidak berhenti pada ukuran file. Dampak akhirnya perlu dilihat dari pengalaman yang dirasakan pengguna ketika membuka dan berinteraksi dengan halaman.
JavaScript yang terlalu berat dapat berhubungan dengan beberapa kondisi berikut:
- LCP terasa lebih lambat apabila JavaScript menghambat proses yang diperlukan untuk menampilkan konten utama.
- INP memburuk apabila main thread terlalu sibuk sehingga browser terlambat merespons interaksi pengguna.
- CLS dapat meningkat apabila JavaScript menambahkan elemen ke halaman tanpa menyediakan ruang layout sebelumnya.
Karena itu, jangan mengevaluasi JavaScript hanya berdasarkan satu angka. Bandingkan hasil audit teknis dengan metrik pengalaman pengguna agar optimasi benar-benar menyelesaikan masalah yang terlihat oleh pengunjung.
Workflow Optimasi JavaScript yang Bisa Kamu Ikuti
Optimasi akan lebih mudah dikelola jika dilakukan secara bertahap. Gunakan satu halaman penting sebagai sampel terlebih dahulu sebelum menerapkan perubahan secara luas ke seluruh website.
- Catat baseline. Simpan hasil PageSpeed Insights dan pengujian Chrome DevTools sebelum melakukan perubahan.
- Identifikasi file terbesar. Gunakan Network untuk melihat JavaScript yang memberikan beban transfer terbesar.
- Periksa unused code. Gunakan Coverage untuk mengetahui bundle yang mengirim banyak kode yang tidak digunakan.
- Audit third-party script. Hapus atau tunda tool yang tidak diperlukan pada saat halaman pertama kali dibuka.
- Perbaiki strategi loading. Terapkan
defer,async, atau pemuatan dinamis sesuai karakteristik script. - Kurangi pekerjaan main thread. Cari proses JavaScript panjang melalui Performance panel.
- Optimalkan transfer file. Pastikan kompresi, browser cache, dan CDN digunakan sesuai kebutuhan.
- Uji kembali. Jalankan pengujian menggunakan kondisi dan halaman yang sama dengan baseline.
- Periksa fungsi website. Pastikan menu, form, checkout, analytics, dan komponen interaktif tetap berjalan setelah optimasi.
Untuk website WordPress, sebagian proses optimasi file dapat dibantu oleh plugin caching dan optimasi frontend. Namun, hindari mengaktifkan banyak plugin dengan fungsi serupa karena konfigurasi yang bertumpuk justru dapat menimbulkan konflik. Kamu dapat menggunakan panduan meningkatkan kecepatan WordPress sebagai referensi khusus untuk lingkungan WordPress.
Contoh Prioritas Berdasarkan Hasil Audit
| Temuan | Prioritas Perbaikan |
|---|---|
| Unused JavaScript sangat tinggi | Hapus dependency yang tidak digunakan dan terapkan code splitting. |
| Banyak script menghambat parsing HTML | Evaluasi penggunaan defer, async, atau module script. |
| Main thread dipenuhi long task | Kurangi pekerjaan sinkron dan pecah proses menjadi pekerjaan yang lebih kecil. |
| Third-party JavaScript mendominasi | Evaluasi fungsi bisnis setiap script lalu hapus atau tunda yang tidak kritis. |
| Ukuran transfer JavaScript tinggi | Aktifkan kompresi dan optimalkan bundle. |
| File yang sama terus diunduh ulang | Periksa browser cache dan strategi versioning aset. |
| TTFB tinggi tetapi JavaScript relatif ringan | Audit server, backend, database, cache server, dan resource hosting. |
Ukur Hasil Sebelum Menyatakan Optimasi Berhasil
Website tidak otomatis menjadi lebih cepat hanya karena ukuran JavaScript berkurang. Setelah melakukan perubahan, ulangi pengujian pada URL, perangkat, dan kondisi yang sama agar hasil sebelum dan sesudah optimasi dapat dibandingkan secara masuk akal.
Periksa perubahan pada ukuran JavaScript yang ditransfer, unused code, waktu pekerjaan main thread, serta metrik Core Web Vitals. Jangan lupa melakukan pengujian fungsi karena optimasi yang menghasilkan skor tinggi tetapi merusak menu atau checkout tetap merupakan optimasi yang gagal.
Untuk website dengan traffic nyata, hasil pengujian laboratorium juga sebaiknya dibandingkan dengan data pengguna apabila tersedia. Kondisi perangkat, jaringan, lokasi, dan perilaku pengguna di dunia nyata dapat menghasilkan pengalaman yang berbeda dari satu kali pengujian pada komputer developer.
Optimasi JavaScript Harus Dimulai dari Bottleneck yang Tepat
Meningkatkan performa website tidak harus dimulai dengan mengganti framework atau menambahkan teknologi baru. Pada banyak kasus, hasil yang lebih berarti justru berasal dari menghapus JavaScript yang tidak digunakan, memperbaiki strategi loading, menunda fungsi nonkritis, mengurangi pekerjaan main thread, dan mengoptimalkan pengiriman aset.
Gunakan hasil pengukuran sebagai dasar setiap keputusan. Jika bottleneck berada di browser, optimalkan JavaScript dan frontend. Jika bottleneck berada pada response server, barulah evaluasi cache, aplikasi backend, konfigurasi server, atau kapasitas hosting.
Dengan pendekatan tersebut, performa aplikasi JavaScript dapat ditingkatkan tanpa menerapkan optimasi secara acak. Website pun menjadi lebih ringan, lebih responsif saat digunakan, serta mempunyai fondasi performa yang lebih mudah dipantau ketika fitur dan traffic terus berkembang.