Website sering mulai terasa lambat bukan setelah server diganti, melainkan setelah fitur-fitur kecil ditambahkan satu per satu: chat customer service, analytics, pixel iklan, widget media sosial, pop-up promosi, atau video embed. Masing-masing tampak ringan jika dilihat sendiri. Masalahnya, browser harus memuat dan menjalankan semuanya dalam waktu yang hampir bersamaan.
JavaScript pihak ketiga adalah kode yang berasal dari layanan atau domain di luar website kita. Kode ini bisa membantu bisnis, tetapi juga dapat menambah permintaan jaringan, penggunaan CPU, waktu parsing, dan pekerjaan pada main thread—jalur utama browser untuk memproses tampilan dan interaksi. Akibatnya, halaman mungkin terlihat sudah muncul, tetapi tombol belum responsif atau pengguna harus menunggu sebelum bisa menggulir dengan nyaman. ([web.dev](https://web.dev/articles/optimizing-content-efficiency-loading-third-party-javascript?hl=en&utm_source=openai))
Kenapa JavaScript pihak ketiga sering luput dari perhatian?
Karena kode tersebut biasanya tidak berada di repositori utama website. Tim marketing mungkin memasangnya melalui Google Tag Manager, plugin menambahkannya otomatis, atau vendor meminta sebuah potongan kode ditempel di bagian <head>. Setelah itu, fitur dianggap selesai karena tampil dengan benar.
Namun, “tampil” tidak sama dengan “murah bagi performa”. Sebuah script dapat memanggil beberapa domain lain, mengunduh file tambahan, membuat elemen baru, menjalankan pelacakan, atau menunggu respons dari server eksternal. Jika salah satu layanan lambat, dampaknya dapat terlihat pada pengalaman pengguna, meskipun server utama website bekerja normal.
Google memasukkan LCP, INP, dan CLS sebagai Core Web Vitals. LCP mengukur seberapa cepat konten utama terlihat, INP mengukur respons halaman terhadap interaksi, sedangkan CLS mengukur pergeseran tata letak yang tidak terduga. Script yang berat terutama berisiko memperburuk INP karena pekerjaan JavaScript yang panjang dapat menahan browser merespons klik atau tap. ([web.dev](https://web.dev/articles/defining-core-web-vitals-thresholds?hl=en&utm_source=openai))
Mulai audit dari daftar, bukan dari dugaan
Langkah pertama bukan langsung menaikkan spesifikasi server. Buat daftar semua layanan eksternal yang dipakai halaman, lalu tanyakan fungsi masing-masing.
- Analytics dan pengukuran konversi.
- Chat, chatbot, atau sistem tiket.
- Pixel iklan dan remarketing.
- Video, peta, ulasan, atau media sosial yang disematkan.
- Tools A/B testing dan personalisasi.
- Font, ikon, atau library JavaScript dari CDN eksternal.
Untuk setiap item, catat tiga hal: siapa pemiliknya, halaman mana yang membutuhkannya, dan apa akibatnya jika script tersebut tidak dimuat. Sering kali script yang dipasang secara global sebenarnya hanya diperlukan di satu halaman, misalnya script pembayaran yang ikut dimuat di halaman artikel.
Gunakan DevTools untuk melihat biaya sebenarnya
Buka Chrome DevTools, masuk ke tab Network, lalu muat ulang halaman dengan cache dinonaktifkan. Gunakan filter JS untuk melihat file JavaScript, kemudian periksa domain asal, ukuran transfer, dan waktu pemuatannya.
Setelah itu, buka tab Performance dan rekam proses saat halaman dimuat. Perhatikan bagian yang menunjukkan tugas panjang atau long task. Jika ada pekerjaan JavaScript yang berlangsung lama di main thread, coba identifikasi apakah sumbernya berasal dari kode utama website atau dari domain pihak ketiga.
Lighthouse dan PageSpeed Insights juga dapat membantu menemukan script eksternal yang memakan waktu. Akan tetapi, hasil pengujian laboratorium bukan gambaran seluruh pengguna. Perangkat murah, jaringan seluler yang tidak stabil, dan browser dengan CPU lebih lambat dapat merasakan dampak lebih besar. Karena itu, bandingkan hasil lab dengan data pengguna nyata jika tersedia. ([web.dev](https://web.dev/articles/optimizing-content-efficiency-loading-third-party-javascript?hl=en&utm_source=openai))
Empat cara mengurangi dampaknya
1. Hapus script yang tidak lagi bernilai
Ini sering menjadi optimasi paling efektif. Periksa script yang dipasang untuk kampanye lama, widget yang tidak digunakan, atau layanan yang hanya dipertahankan karena “siapa tahu masih perlu”. Setiap script memiliki biaya pemeliharaan, risiko privasi, dan potensi gangguan.
Jangan hanya bertanya, “Apakah fitur ini terlihat?” Tanyakan juga, “Apakah fitur ini menghasilkan nilai yang bisa diukur?” Jika tidak ada manfaat yang jelas, menghapusnya lebih baik daripada terus mencoba mengakalinya.
2. Jangan memuat semua script di semua halaman
Script chat mungkin penting di halaman produk, tetapi belum tentu perlu pada halaman dokumentasi. Video embed sebaiknya hanya dimuat pada artikel yang menampilkannya. Pixel tertentu juga dapat dibatasi pada halaman kampanye yang relevan.
Pemisahan ini bisa dilakukan melalui template, aturan tag manager, atau kondisi di sisi server. Tujuannya sederhana: pengguna hanya membayar biaya performa untuk fitur yang benar-benar mereka gunakan.
3. Gunakan async dan defer dengan alasan yang tepat
Atribut async memungkinkan script diunduh tanpa menghentikan parsing HTML, tetapi script akan dijalankan segera setelah selesai diunduh. Urutan eksekusinya tidak dijamin.
Sementara itu, defer juga mengunduh script secara paralel, tetapi menunggu hingga parsing HTML selesai dan mempertahankan urutan eksekusi. Untuk script yang tidak diperlukan agar konten awal tampil, defer sering menjadi pilihan yang lebih mudah diprediksi. Google menyarankan penggunaan async atau defer untuk script pihak ketiga, kecuali script tersebut memang berada di jalur kritis rendering. ([web.dev](https://web.dev/articles/efficiently-load-third-party-javascript?utm_source=openai))
<script src="https://contoh-vendor.com/widget.js" defer></script>Namun, menambahkan atribut ini bukan jaminan otomatis. Script yang dijalankan setelah halaman muncul tetap dapat menghabiskan CPU dan mengganggu interaksi. Ukur kembali setelah perubahan.
4. Tunda fitur berat sampai benar-benar dibutuhkan
Untuk chat, video, atau peta, pertimbangkan pola facade: tampilkan gambar atau tombol ringan terlebih dahulu, lalu muat layanan asli setelah pengguna mengkliknya. Cara ini mengurangi pekerjaan awal tanpa menghilangkan fitur.
Untuk layanan yang berada jauh di bawah layar, lazy loading juga dapat membantu. Tetapi pastikan ruang elemen sudah ditentukan sejak awal agar pemuatan tidak menyebabkan layout bergeser. Embedding pihak ketiga yang tidak memiliki ukuran tetap dapat memperburuk CLS. ([web.dev](https://web.dev/articles/embed-best-practices?hl=en&utm_source=openai))
Apa artinya bagi kita?
Performa bukan hanya urusan developer atau hosting. Keputusan bisnis—seperti menambah tool pemasaran, pop-up, pelacak konversi, dan widget eksternal—ikut menentukan seberapa cepat website terasa bagi pengunjung.
Karena itu, setiap permintaan fitur sebaiknya memiliki “anggaran performa”. Sebelum dipasang, tentukan halaman yang membutuhkan, kapan script dimuat, metrik apa yang dipantau, dan kapan layanan tersebut dievaluasi kembali.
Yang bisa dilakukan sekarang
- Buat inventaris semua script dan embed eksternal.
- Hapus layanan yang tidak memiliki fungsi terukur.
- Batasi script hanya pada halaman yang memerlukannya.
- Uji penggunaan
async,defer, atau pemuatan setelah interaksi. - Bandingkan INP, LCP, dan waktu respons sebelum dan sesudah perubahan.
- Uji dengan perangkat dan jaringan yang realistis, bukan hanya komputer developer.
Website yang cepat bukan berarti tanpa fitur. Prinsipnya adalah memuat fitur pada saat yang tepat, di halaman yang tepat, dan dengan biaya yang bisa dipertanggungjawabkan.
Sumber & bacaan lebih lanjut
- Efficiently load third-party JavaScript
- Load Third-Party JavaScript
- Optimize Interaction to Next Paint
- How the Core Web Vitals metrics thresholds were defined
- Best practices for using third-party embeds
– Rio Yotto @rioyotto