Pelajari apa itu Web Worker dan Service Worker, bagaimana perbedaannya, dan kapan menggunakan masing‑masing untuk halaman lebih cepat, tugas latar, caching, dan dukungan offline.
Browser menjalankan sebagian besar JavaScript Anda di main thread—tempat yang sama yang menangani input pengguna, animasi, dan me-render halaman. Ketika pekerjaan berat terjadi di sana (mengurai data besar, pemrosesan gambar, perhitungan kompleks), UI bisa tersendat atau “membeku.” Worker ada untuk memindahkan tugas tertentu keluar dari main thread atau di luar kontrol langsung halaman, sehingga aplikasi tetap responsif.
Jika halaman Anda sibuk melakukan komputasi 200ms, browser tidak bisa melakukan scroll halus, merespons klik, atau menjaga animasi di 60fps. Worker membantu dengan membiarkan Anda melakukan pekerjaan latar belakang sementara main thread fokus pada antarmuka.
Sebuah Web Worker adalah thread JavaScript latar belakang yang Anda buat dari sebuah halaman. Ia cocok untuk tugas berat CPU yang kalau dijalankan di main thread akan memblokir UI.
Sebuah Service Worker adalah jenis worker khusus yang berada di antara web app Anda dan jaringan. Ia dapat mencegat permintaan, meng-cache respons, dan mengaktifkan fitur seperti dukungan offline dan push notification.
Anggap Web Worker sebagai asisten yang melakukan perhitungan di ruangan lain. Anda mengirim pesan, ia bekerja, lalu mengirim balik hasil.
Anggap Service Worker sebagai penjaga pintu depan. Permintaan untuk halaman, skrip, dan panggilan API melewatinya, dan ia bisa memutuskan apakah mengambil dari jaringan, melayani dari cache, atau merespons dengan cara kustom.
Di akhir bacaan, Anda akan tahu:
postMessage) cocok dalam model worker, dan mengapa Cache Storage API penting untuk offlineRingkasan ini menetapkan “mengapa” dan model mental—selanjutnya kita akan menyelam ke cara tiap jenis worker berperilaku dan di mana mereka cocok di proyek nyata.
Saat Anda membuka sebuah halaman web, sebagian besar apa yang Anda “rasakan” terjadi di main thread. Ia bertanggung jawab untuk menggambar piksel (rendering), merespons ketukan dan klik (input), dan menjalankan banyak JavaScript.
Karena rendering, penanganan input, dan JavaScript sering bergantian di thread yang sama, satu tugas lambat bisa membuat semuanya menunggu. Itulah mengapa masalah performa cenderung muncul sebagai masalah responsiveness, bukan sekadar “kode lambat.”
Rasa “blocking” bagi pengguna:
JavaScript memiliki banyak API asinkron—fetch(), timer, event—yang membantu menghindari menunggu secara pasif. Tapi async tidak serta-merta membuat pekerjaan berat berjalan bersamaan dengan rendering.
Jika Anda melakukan komputasi mahal (pemrosesan gambar, penguraian JSON besar, kripto, penyaringan kompleks) di main thread, itu masih bersaing dengan pembaruan UI. “Async” bisa menunda kapan ia berjalan, tapi mungkin tetap berjalan di main thread yang sama dan tetap menyebabkan jank saat dieksekusi.
Worker ada agar browser dapat menjaga halaman tetap responsif sambil tetap melakukan pekerjaan bermakna.
Singkatnya: worker adalah cara untuk melindungi main thread sehingga aplikasi tetap interaktif sambil melakukan pekerjaan nyata di latar.
Sebuah Web Worker adalah cara menjalankan JavaScript di luar main thread. Alih-alih bersaing dengan pekerjaan UI (rendering, scrolling, merespons klik), seorang worker berjalan di thread latar sendiri sehingga tugas berat dapat selesai tanpa membuat halaman terasa “terbengkalai.”
Anggaplah halaman tetap fokus pada interaksi pengguna, sementara worker menangani pekerjaan CPU-heavy seperti mengurai file besar, menghitung angka, atau menyiapkan data untuk grafik.
Web Worker berjalan di thread terpisah dengan scope globalnya sendiri. Ia masih memiliki akses ke banyak web API (timer, fetch di banyak browser, crypto, dll.), tetapi sengaja diisolasi dari halaman.
Ada beberapa variasi umum:
Jika Anda belum pernah menggunakan worker sebelumnya, sebagian besar contoh yang Anda lihat adalah dedicated worker.
Worker tidak langsung memanggil fungsi di halaman Anda. Komunikasi terjadi dengan mengirim pesan:
postMessage().postMessage().Untuk data biner besar, Anda bisa meningkatkan performa dengan mentransfer kepemilikan ArrayBuffer (agar tidak disalin), sehingga menjaga pengiriman pesan tetap cepat.
Karena worker diisolasi, ada beberapa batasan kunci:
window atau document. Worker berjalan di bawah self (scope global worker), dan API yang tersedia bisa berbeda dari halaman utama.Jika digunakan dengan baik, Web Worker adalah salah satu cara paling sederhana untuk meningkatkan performa main thread tanpa mengubah apa yang dilakukan aplikasi—hanya memindahkan di mana pekerjaan mahal dijalankan.
Web Workers cocok ketika halaman Anda terasa “terkunci” karena JavaScript melakukan terlalu banyak pekerjaan di main thread. Main thread juga bertanggung jawab untuk interaksi pengguna dan rendering, sehingga tugas berat di sana dapat menyebabkan jank, klik tertunda, dan scroll terhenti.
Gunakan Web Worker saat Anda punya pekerjaan CPU-heavy yang tidak perlu akses DOM:
Contoh praktis: jika Anda menerima payload JSON besar dan mengurai itu menyebabkan UI tersendat, pindahkan parsing ke worker, lalu kirim kembali hasilnya.
Komunikasi dengan worker lewat postMessage. Untuk data biner besar, utamakan transferable objects (seperti ArrayBuffer) agar browser bisa menyerahkan kepemilikan memori ke worker daripada menyalinnya.
// main thread
worker.postMessage(buffer, [buffer]); // mentransfer ArrayBuffer
Ini sangat berguna untuk buffer audio, byte gambar, atau potongan data besar lainnya.
Worker punya overhead: file tambahan, pengiriman pesan, dan alur debugging yang berbeda. Hindari mereka ketika:
postMessage yang konstan bisa menghapus manfaatnya.Jika sebuah tugas bisa menyebabkan jeda yang terlihat (sering ~50ms+) dan bisa diekspresikan sebagai “input → compute → output” tanpa akses DOM, Web Worker biasanya sepadan. Jika sebagian besar adalah pembaruan UI, tetaplah di main thread dan optimalkan di sana.
Sebuah Service Worker adalah file JavaScript khusus yang berjalan di latar browser dan berperan sebagai lapisan jaringan yang dapat diprogram untuk situs Anda. Alih-alih berjalan di halaman itu sendiri, ia berada di antara web app dan jaringan, memungkinkan Anda memutuskan apa yang terjadi saat aplikasi meminta resource (HTML, CSS, API, gambar).
Service Worker memiliki lifecycle yang terpisah dari tab mana pun:
Karena ia bisa dihentikan dan dijalankan ulang kapan saja, perlakukan ia seperti skrip event-driven: lakukan pekerjaan dengan cepat, simpan state di penyimpanan persisten, dan jangan berasumsi ia selalu berjalan.
Service Worker dibatasi pada origin yang sama (domain/protokol/port yang sama) dan hanya mengontrol halaman di bawah scope-nya—biasanya folder tempat file worker disajikan (dan subfoldernya). Mereka juga memerlukan HTTPS (kecuali localhost) karena dapat memengaruhi permintaan jaringan.
Service Worker terutama digunakan untuk berada di antara aplikasi Anda dan jaringan. Ia dapat memutuskan kapan menggunakan jaringan, kapan menggunakan data yang di-cache, dan kapan melakukan sedikit pekerjaan di latar—tanpa memblokir halaman.
Tugas paling umum adalah memungkinkan pengalaman offline atau saat koneksi buruk dengan meng-cache aset dan respons.
Beberapa strategi caching praktis:
Biasanya diimplementasikan dengan Cache Storage API dan penanganan event fetch.
Service Worker dapat meningkatkan kecepatan yang dirasakan pada kunjungan berikutnya dengan:
Hasilnya: lebih sedikit request jaringan, start-up lebih cepat, dan performa lebih konsisten pada koneksi yang fluktuatif.
Service Worker bisa memberi fitur latar seperti push notification dan background sync (dukungan bervariasi antar browser dan platform). Artinya Anda bisa memberi notifikasi atau mencoba ulang request yang gagal nanti—meskipun halaman tidak terbuka.
Jika membangun progressive web app, Service Worker adalah bagian inti di balik:
Kalau hanya mengingat satu hal: Web Workers membantu halaman Anda melakukan kerja berat tanpa membekukan UI, sedangkan Service Workers membantu aplikasi mengontrol permintaan jaringan dan berperilaku seperti aplikasi yang dapat diinstal (PWA).
Web Worker untuk tugas CPU-heavy—mengurai data besar, membuat thumbnail, menghitung—agar main thread tetap responsif.
Service Worker untuk penanganan request dan tugas lifecycle aplikasi—dukungan offline, strategi caching, background sync, dan push notification. Ia bisa berada di antara aplikasi dan jaringan.
Web Worker biasanya terikat pada halaman/tab. Saat halaman hilang, worker biasanya ikut berhenti (kecuali kasus khusus seperti SharedWorker).
Service Worker bersifat event-driven. Browser bisa memulainya untuk menangani event (seperti fetch atau push), lalu menghentikannya saat idle. Itu berarti ia bisa berjalan meski tidak ada tab terbuka, selama ada event yang membangunkannya.
Web Worker tidak bisa mencegat request jaringan yang dibuat oleh halaman. Ia bisa memanggil fetch(), tapi tidak bisa menulis ulang, meng-cache, atau melayani respons untuk bagian lain dari situs Anda.
Service Worker bisa mencegat request jaringan (melalui event fetch), memutuskan apakah ke jaringan, melayani dari cache, atau mengembalikan fallback.
Web Worker tidak mengelola caching HTTP untuk aplikasi Anda.
Service Worker sering menggunakan Cache Storage API untuk menyimpan dan melayani pasangan request/response—ini dasar untuk caching offline dan pemuatan ulang instan.
Menjalankan worker sebagian besar soal di mana ia berjalan dan bagaimana ia dimuat. Web Workers dibuat langsung oleh skrip halaman. Service Workers didaftarkan oleh browser dan berada “di depan” permintaan jaringan untuk situs Anda.
Web Worker hidup saat halaman membuatnya. Anda menunjuk ke file JavaScript terpisah, lalu berkomunikasi lewat postMessage.
// main.js (berjalan di halaman)
const worker = new Worker('/workers/resize-worker.js', { type: 'module' });
worker.postMessage({ action: 'start', payload: { /* ... */ } });
worker.onmessage = (event) => {
console.log('From worker:', event.data);
};
Model mental yang baik: file worker adalah skrip URL lain yang bisa di-fetch halaman Anda, tapi dijalankan di luar main thread.
Service Worker harus didaftarkan dari halaman yang dikunjungi pengguna:
// main.js
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/sw.js');
}
Setelah registrasi, browser menangani lifecycle install/activate. sw.js Anda bisa mendengarkan event seperti install, activate, dan fetch.
Service Worker dapat mencegat request jaringan dan meng-cache respons. Jika registrasi diizinkan lewat HTTP, penyerang jaringan bisa mengganti sw.js berbahaya dan pada dasarnya mengontrol kunjungan berikutnya. HTTPS (atau http://localhost untuk pengembangan) melindungi skrip dan trafik yang dapat dipengaruhinya.
Browser meng-cache dan meng-update worker berbeda dari skrip halaman biasa. Rencanakan pembaruan:
sw.js/bundle worker baru).Jika Anda menginginkan strategi rollout yang lebih mulus nanti, lihat /blog/debugging-workers untuk kebiasaan pengujian yang menangkap edge case update lebih awal.
Worker gagal dengan cara yang berbeda dibandingkan JavaScript halaman biasa: mereka berjalan di konteks terpisah, punya console sendiri, dan bisa dimulai ulang oleh browser. Rutinitas debugging yang baik menghemat banyak waktu.
Buka DevTools dan cari target worker khusus. Di Chrome/Edge, Anda sering melihat worker terdaftar di bawah Sources (atau melalui entri “Dedicated worker”) dan di pemilih konteks Console.
Gunakan alat yang sama seperti di main thread:
onmessage dan fungsi panjang.Jika pesan tampak “hilang”, periksa kedua sisi: pastikan Anda memanggil worker.postMessage(...), worker punya self.onmessage = ..., dan bentuk pesan cocok.
Service Worker paling baik didebug di panel Application:
Juga perhatikan Console untuk error install/activate/fetch—ini sering menjelaskan kenapa caching atau perilaku offline tidak bekerja.
Masalah caching adalah penyebab paling banyak membuang waktu: meng-cache file yang salah (atau terlalu agresif) bisa membuat HTML/JS lama tetap terlayani. Saat pengujian, coba hard reload dan konfirmasi apa yang sebenarnya disajikan dari cache.
Untuk pengujian realistis, gunakan DevTools untuk:
Jika Anda cepat beriterasi pada PWA, membantu untuk membuat baseline app yang bersih (dengan Service Worker dan output build yang dapat diprediksi) lalu menyempurnakan strategi caching dari sana. Platform seperti Koder.ai dapat berguna untuk eksperimen semacam ini: Anda bisa mem-prototype aplikasi React dari prompt chat, mengekspor kode sumber, lalu menyesuaikan setup worker dan aturan caching dengan siklus umpan balik yang lebih ketat.
Worker bisa membuat aplikasi lebih mulus dan kapabel, tetapi mereka juga mengubah di mana kode berjalan dan apa yang bisa diakses. Pemeriksaan cepat pada keamanan, privasi, dan performa akan menyelamatkan Anda dari bug mengejutkan—dan pengguna yang tidak senang.
Baik Web Workers maupun Service Workers dibatasi oleh same-origin policy: mereka hanya bisa berinteraksi langsung dengan resource dari skema/host/port yang sama (kecuali server secara eksplisit mengizinkan akses lintas-origin melalui CORS). Ini mencegah worker menarik data dari situs lain dan mencampurnya ke aplikasi Anda tanpa izin.
Service Workers punya pengaman ekstra: mereka umumnya membutuhkan HTTPS (atau localhost saat development) karena bisa mencegat request jaringan. Perlakukan mereka sebagai kode yang berhak istimewa: minimalisir dependensi, hindari pemuatan kode dinamis, dan versi logika caching Anda dengan hati-hati supaya cache lama tidak terus menyajikan berkas usang.
Fitur latar harus terasa dapat diprediksi. Push notification kuat, tetapi prompt izin mudah disalahgunakan.
Minta izin hanya ketika ada manfaat yang jelas (mis. setelah pengguna mengaktifkan notifikasi di pengaturan), dan jelaskan apa yang akan mereka terima. Jika Anda menyinkronkan atau mem-fetch data di latar, komunikasikan dengan bahasa sederhana—pengguna memperhatikan aktivitas jaringan atau notifikasi yang tak terduga.
Worker bukan “performan gratis.” Penggunaan berlebihan bisa berbalik merugikan:
postMessage yang sering (terutama dengan objek besar) bisa menjadi bottleneck. Utamakan batching dan gunakan transferable ketika sesuai.Tidak semua browser mendukung setiap kemampuan (atau pengguna mungkin memblokir izin). Lakukan feature-detect dan degrade dengan rapi:
if ('serviceWorker' in navigator) {
// register service worker
} else {
// continue without offline features
}
Tujuannya: fungsionalitas inti tetap bekerja, dengan “nice-to-haves” (offline, push, komputasi berat) ditambahkan bila tersedia.
Web Workers dan Service Workers memecahkan masalah berbeda, jadi mereka cocok dipasangkan ketika sebuah aplikasi membutuhkan komputasi berat sekaligus pemuatan yang cepat dan andal. Model mental yang baik: Web Worker = compute, Service Worker = network + caching, main thread = UI.
Misalkan aplikasi Anda membiarkan pengguna mengedit foto (resize, filter, hapus latar) dan melihat galeri nanti tanpa koneksi.
Pendekatan “compute then cache” ini menjaga tanggung jawab jelas: worker menghasilkan output, service worker memutuskan cara menyimpan dan menyajikannya.
Untuk aplikasi dengan feed, form, atau data lapangan:
Bahkan tanpa full background sync, service worker tetap meningkatkan kecepatan yang dirasakan dengan melayani respons cached sementara aplikasi memperbarui di latar.
Hindari mencampur peran:
postMessage).Tidak. Service Worker berjalan di latar, terpisah dari tab halaman mana pun, dan tidak memiliki akses DOM (elemen HTML halaman).
Pem segregasian ini disengaja: Service Worker dirancang untuk tetap bekerja bahkan bila tidak ada halaman terbuka (mis. menanggapi event push atau menyajikan file yang di-cache). Karena mungkin tidak ada dokumen aktif yang bisa dimanipulasi, browser menjaga isolasi tersebut.
Jika Service Worker perlu memengaruhi apa yang dilihat pengguna, ia berkomunikasi dengan halaman lewat messaging (mis. postMessage) sehingga halaman dapat memperbarui UI.
Tidak. Web Workers dan Service Workers independen.
Anda bisa menggunakan salah satu saja atau mengombinasikannya jika aplikasi perlu kedua kemampuan tersebut.
Di browser modern, Web Workers didukung luas dan biasanya merupakan baseline yang aman.
Service Workers juga didukung secara luas di versi terbaru browser utama, tetapi ada lebih banyak persyaratan dan edge case:
localhost untuk development).Jika kompatibilitas lebar penting, perlakukan fitur Service Worker sebagai progressive enhancement: bangun pengalaman inti yang baik terlebih dulu, lalu tambahkan offline/push bila tersedia.
Tidak otomatis.
Keuntungan nyata datang dari menggunakan worker yang tepat untuk bottleneck yang tepat, dan mengukur sebelum dan sesudah.
Gunakan Web Worker ketika Anda punya pekerjaan CPU-intensif yang bisa diekspresikan sebagai input → compute → output dan tidak membutuhkan akses DOM.
Cocok untuk parsing/transformasi payload besar, kompresi, kriptografi, pemrosesan gambar/audio, dan penyaringan kompleks. Jika kerja utamanya adalah pembaruan UI atau pembacaan/penulisan DOM yang sering, worker tidak akan membantu (dan worker memang tidak dapat mengakses DOM).
Gunakan Service Worker ketika Anda membutuhkan kontrol jaringan: dukungan offline, strategi caching, meningkatkan kecepatan kunjungan ulang, routing request, dan (jika didukung) push/background sync.
Jika masalah Anda adalah “UI membeku saat melakukan perhitungan”, itu masalah untuk Web Worker. Jika masalahnya adalah “loading lambat / offline tidak bekerja”, itu masalah untuk Service Worker.
Tidak. Web Workers dan Service Workers adalah fitur yang berdiri sendiri.
Anda bisa menggunakan salah satu saja, atau menggabungkannya ketika aplikasi butuh komputasi dan fitur offline/jaringan.
Utamanya soal cakupan dan masa hidup.
fetch) bahkan saat tidak ada tab terbuka, lalu dimatikan saat menganggur.Tidak. Web Workers tidak memiliki akses window/document.
Jika Anda perlu memengaruhi UI, kirim data kembali ke main thread lewat postMessage(), lalu perbarui DOM di kode halaman Anda. Biarkan worker fokus pada komputasi murni.
Tidak. Service Workers juga tidak memiliki akses DOM.
Untuk memengaruhi apa yang dilihat pengguna, komunikasikan dengan halaman yang dikendalikan lewat messaging (mis. menggunakan Clients API + postMessage()), dan biarkan halaman melakukan pembaruan UI.
Gunakan postMessage() di kedua sisi.
worker.postMessage(data)self.postMessage(result)Untuk data biner besar, gunakan transferables (seperti ArrayBuffer) agar browser bisa menyerahkan kepemilikan memori ke worker alih-alih menggandakannya:
Service Worker berada di antara aplikasi Anda dan jaringan dan bisa merespon permintaan menggunakan Cache Storage API.
Strategi umum:
Pilih strategi per jenis resource (app shell vs data API), bukan satu aturan untuk semuanya.
Bisa, tetapi jaga batas tanggung jawab tetap jelas.
Contoh pola umum:
Dengan begitu Anda menghindari mencampurkan logika UI ke konteks latar belakang dan menjaga performa lebih dapat diprediksi.
Gunakan permukaan DevTools yang tepat untuk tiap jenis worker.
onmessage, dan profil untuk memastikan main thread tetap responsif.Saat debug masalah caching, selalu verifikasi apa yang benar-benar disajikan (network vs cache) dan uji mode offline/throttling.
worker.postMessage(buffer, [buffer]);