Web Workers vs Service Workers: apa itu dan mengapa

Web Workers vs Service Workers: ringkasan cepat

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.

Masalah yang dipecahkan worker

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.

Definisi cepat

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.

Model mental sederhana: “thread” vs “proxy jaringan”

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.

Apa yang akan Anda pelajari di artikel ini

Di akhir bacaan, Anda akan tahu:

• kapan web worker adalah alat yang tepat untuk performa (dan apa yang tidak dapat diaksesnya)
• apa yang service worker aktifkan untuk caching offline, pembaruan, dan perilaku PWA
• bagaimana messaging (seperti postMessage) cocok dalam model worker, dan mengapa Cache Storage API penting untuk offline

Ringkasan ini menetapkan “mengapa” dan model mental—selanjutnya kita akan menyelam ke cara tiap jenis worker berperilaku dan di mana mereka cocok di proyek nyata.

Mengapa browser punya worker sejak awal

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.

Main thread ibarat antrean kasir bersama

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:

• Scrolling tersendat (jank)
• Tombol tidak segera merespons klik
• Pengetikan terlambat dari keyboard
• Animasi berhenti sejenak

Async tidak sama dengan paralel

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.

Di mana worker cocok dalam arsitektur browser

Worker ada agar browser dapat menjaga halaman tetap responsif sambil tetap melakukan pekerjaan bermakna.

• Web Workers memungkinkan Anda menjalankan JavaScript di thread latar untuk tugas CPU-heavy.
• Service Workers berjalan terpisah dari halaman mana pun, berperan lebih sebagai lapisan jaringan dan caching yang dapat bekerja bahkan saat halaman tidak terbuka.

Singkatnya: worker adalah cara untuk melindungi main thread sehingga aplikasi tetap interaktif sambil melakukan pekerjaan nyata di latar.

Apa itu Web Worker?

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.

Di mana ia berjalan

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.

Dedicated Worker vs Shared Worker

Ada beberapa variasi umum:

• Dedicated Worker: terhubung ke satu halaman/tab. Ketika halaman itu hilang, worker biasanya dihentikan.
• Shared Worker: dapat dibagikan oleh banyak halaman/tab dari origin yang sama, berguna untuk mengoordinasikan kerja antar-tab (mis. berbagi satu koneksi atau menyinkronkan state).

Jika Anda belum pernah menggunakan worker sebelumnya, sebagian besar contoh yang Anda lihat adalah dedicated worker.

Bagaimana Web Worker berkomunikasi

Worker tidak langsung memanggil fungsi di halaman Anda. Komunikasi terjadi dengan mengirim pesan:

• Halaman mengirim data ke worker dengan postMessage().
• Worker merespons kembali juga dengan postMessage().
• Data dipindahkan menggunakan structured clone algorithm, yang mendukung banyak tipe bawaan (object, array, string, number, Map/Set, ArrayBuffer, dan lain-lain).

Untuk data biner besar, Anda bisa meningkatkan performa dengan mentransfer kepemilikan ArrayBuffer (agar tidak disalin), sehingga menjaga pengiriman pesan tetap cepat.

Batasan umum (atas dasar desain)

Karena worker diisolasi, ada beberapa batasan kunci:

• Tidak ada akses DOM langsung: worker tidak bisa membaca atau mengubah HTML, CSS, atau layout halaman.
• Global berbeda: Anda tidak mendapat window atau document. Worker berjalan di bawah self (scope global worker), dan API yang tersedia bisa berbeda dari halaman utama.
• Pola asinkron: karena semuanya berbasis pesan, Anda menyusun kode dengan pola mengirim tugas dan menerima hasil kembali.

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.

Kapan menggunakan Web Workers (dan kapan tidak)

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.

Cocoknya Web Workers

Gunakan Web Worker saat Anda punya pekerjaan CPU-heavy yang tidak perlu akses DOM:

• Komputasi berat: perhitungan, simulasi, pengolahan data.
• Parsing dan transformasi: penguraian JSON besar, parsing CSV, validasi skema.
• Kompresi / dekompresi: beban kerja zip/gzip, encoding/decoding.
• Pemrosesan gambar: resize, filtering, membuat thumbnail (sering dipasangkan dengan OffscreenCanvas di browser yang mendukung).

Contoh praktis: jika Anda menerima payload JSON besar dan mengurai itu menyebabkan UI tersendat, pindahkan parsing ke worker, lalu kirim kembali hasilnya.

Tips penanganan data (untuk kecepatan)

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.

Kapan tidak menggunakan Web Workers

Worker punya overhead: file tambahan, pengiriman pesan, dan alur debugging yang berbeda. Hindari mereka ketika:

• Tugasnya kecil (milidetik) dan jarang terjadi.
• Pekerjaan membutuhkan pembacaan/penulisan DOM yang sering (worker tidak bisa menyentuh DOM).
• Anda butuh latensi bolak-balik yang sangat rendah; ping-pong postMessage yang konstan bisa menghapus manfaatnya.

Aturan praktis sederhana

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.

Apa itu Service Worker?

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).

Dasar lifecycle (register → install → activate → control)

Service Worker memiliki lifecycle yang terpisah dari tab mana pun:

• Register: halaman memberi tahu browser “situs ini punya service worker” (biasanya dari JS utama).
• Install: browser mengunduhnya dan menjalankan langkah install, sering dipakai untuk precache berkas penting.
• Activate: worker baru mengambil alih, biasanya setelah menutup tab lama atau saat aman mengganti versi yang lebih lama.
• Control: setelah aktif, ia dapat “mengontrol” halaman dalam scopenya dan mulai mencegat request.

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.

Aturan scope dan origin (secara tinggi)

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.

API kunci yang sering muncul

• Fetch event: mencegat permintaan dan memutuskan apakah menggunakan jaringan, cache, atau respons kustom.
• Cache Storage API: menyimpan dan mengambil respons yang di-cache untuk penggunaan offline dan kecepatan.
• Clients API: berkomunikasi dengan dan mengelola tab/jendela terbuka yang dikendalikan worker Anda.

Untuk apa Service Workers dipakai

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.

Dukungan offline (caching pintar)

Tugas paling umum adalah memungkinkan pengalaman offline atau saat koneksi buruk dengan meng-cache aset dan respons.

Beberapa strategi caching praktis:

• Cache-first: bagus untuk file statis (CSS, JS, logo). Cepat, bekerja offline.
• Network-first: cocok untuk konten yang sering berubah (berita, feed). Menggunakan cache saat offline.
• Stale-while-revalidate: tampilkan konten cache segera, lalu perbarui di latar untuk kunjungan berikutnya.

Biasanya diimplementasikan dengan Cache Storage API dan penanganan event fetch.

Kunjungan ulang yang lebih cepat

Service Worker dapat meningkatkan kecepatan yang dirasakan pada kunjungan berikutnya dengan:

• Precaching: menyimpan berkas “penting” selama install (sering disebut app shell).
• Runtime caching: meng-cache halaman atau respons API saat pengguna bernavigasi.

Hasilnya: lebih sedikit request jaringan, start-up lebih cepat, dan performa lebih konsisten pada koneksi yang fluktuatif.

Fitur latar (jika didukung)

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.

Komponen dasar PWA

Jika membangun progressive web app, Service Worker adalah bagian inti di balik:

• Installability (dipasangkan dengan web app manifest)
• Halaman offline yang ramah (mis. fallback)
• Model app shell untuk navigasi yang responsif

Perbedaan kunci: Web Worker vs Service Worker

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).

Di mana mereka berjalan (tujuan tugas)

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.

Masa hidup dan “siapa pemiliknya”

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.

Akses dan kontrol jaringan

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.

Penyimpanan dan caching

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.

Cara menyiapkannya (langkah tingkat tinggi)

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: buat dari halaman

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: daftarkan (sekali) dan biarkan browser menginstalnya

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.

Kenapa Service Worker memerlukan HTTPS

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.

Pola versi: perlakukan file worker seperti “rilis” yang dideploy

Browser meng-cache dan meng-update worker berbeda dari skrip halaman biasa. Rencanakan pembaruan:

• Ubah file saat perilaku berubah (sering dengan deploy sw.js/bundle worker baru).
• Pada Service Worker, harapkan alur “update”: worker baru terinstall, lalu aktif saat aman.
• Saat mengubah aturan caching, sertakan logika pembersihan di activation supaya cache lama tidak tertinggal.

Jika Anda menginginkan strategi rollout yang lebih mulus nanti, lihat /blog/debugging-workers untuk kebiasaan pengujian yang menangkap edge case update lebih awal.

Debugging dan pengujian worker di browser

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.

Debugging Web Worker (DevTools)

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:

• Console logging: log dari Web Worker muncul di DevTools, tetapi pastikan Anda melihat konteks yang benar.
• Breakpoints: pasang breakpoint di dalam skrip worker; telusuri handler onmessage dan fungsi panjang.
• Performance profiling: rekam trace Performance dan verifikasi main thread tetap responsif saat worker melakukan pekerjaan berat.

Jika pesan tampak “hilang”, periksa kedua sisi: pastikan Anda memanggil worker.postMessage(...), worker punya self.onmessage = ..., dan bentuk pesan cocok.

Debugging Service Worker (Application panel)

Service Worker paling baik didebug di panel Application:

• Periksa status registrasi, scope, dan versi active/waiting/installed.
• Gunakan kontrol lifecycle seperti Skip waiting dan Unregister untuk mereset state yang bermasalah.
• Aktifkan Update on reload untuk menghindari mengejar kode usang saat iterasi.

Juga perhatikan Console untuk error install/activate/fetch—ini sering menjelaskan kenapa caching atau perilaku offline tidak bekerja.

Perangkap umum dan tips pengujian

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:

• mensimulasikan mode Offline dan verifikasi halaman fallback
• menerapkan network throttling
• me-reload berulang untuk memvalidasi pembaruan Service Worker dan penanganan pesan

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.

Pertimbangan keamanan, privasi, dan performa

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.

Batas keamanan (dan kenapa same-origin penting)

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.

Privasi dan ekspektasi pengguna

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.

Risiko performa yang perlu diwaspadai

Worker bukan “performan gratis.” Penggunaan berlebihan bisa berbalik merugikan:

• Overhead pesan: postMessage yang sering (terutama dengan objek besar) bisa menjadi bottleneck. Utamakan batching dan gunakan transferable ketika sesuai.
• Biaya memori: setiap worker punya memori dan biaya startup sendiri; terlalu banyak worker bisa meningkatkan penggunaan RAM dan daya.
• Pertumbuhan cache: Service Worker yang terlalu agresif meng-cache bisa membuat penyimpanan membengkak. Tambahkan batas cache dan pembersihan saat update.

Fallback secara anggun

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.

Pola umum yang menggunakan keduanya bersama

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.

Pola 1: Pemrosesan gambar + galeri offline

Misalkan aplikasi Anda membiarkan pengguna mengedit foto (resize, filter, hapus latar) dan melihat galeri nanti tanpa koneksi.

• Web Worker melakukan pekerjaan CPU-heavy (decode, transform, generate thumbnails) sehingga scrolling dan ketukan tetap mulus.
• Service Worker meng-cache thumbnail dan file asli di Cache Storage (atau metadata di IndexedDB) dan menyajikannya langsung pada kunjungan ulang atau saat offline.

Pendekatan “compute then cache” ini menjaga tanggung jawab jelas: worker menghasilkan output, service worker memutuskan cara menyimpan dan menyajikannya.

Pola 2: Sinkronisasi data + caching latar

Untuk aplikasi dengan feed, form, atau data lapangan:

• Web Worker dapat menormalisasi payload JSON besar, menjalankan diffing, atau memvalidasi data tanpa menghambat UI.
• Service Worker dapat meng-cache respons API untuk startup cepat dan menangani pembacaan saat offline. Saat konektivitas kembali, ia dapat menyegarkan cache dan (jika didukung) mengoordinasikan background sync.

Bahkan tanpa full background sync, service worker tetap meningkatkan kecepatan yang dirasakan dengan melayani respons cached sementara aplikasi memperbarui di latar.

Menjaga tanggung jawab terpisah

Hindari mencampur peran:

• UI thread: rendering, input pengguna, aksesibilitas, wiring state minimal.
• Web Worker: komputasi murni dan persiapan data (sering lewat postMessage).
• Service Worker: routing request, strategi caching, fallback offline.

Checklist cepat: mana yang Anda butuhkan?

• Apakah tugasnya CPU-heavy (parsing, encoding, kripto, pemrosesan gambar/audio)? Gunakan Web Worker.
• Apakah tugasnya soal intercept fetch, perilaku offline, atau caching? Gunakan Service Worker.
• Apakah Anda butuh UI cepat dan pemuatan/offline cepat? Gunakan keduanya, tapi jaga batasnya jelas: komputasi di web worker, penyimpanan/penyajian lewat service worker.

FAQ: pertanyaan praktis yang sering ditanyakan

Bisakah Service Worker mengakses DOM?

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.

Apakah saya perlu Service Worker untuk Web Worker?

Tidak. Web Workers dan Service Workers independen.

• Web Worker: dipakai untuk memindahkan kerja JavaScript berat dari main thread (seperti parsing, perhitungan, pemrosesan gambar) agar UI tetap responsif.
• Service Worker: dipakai untuk fitur jaringan (offline caching, intercept request, background sync, push).

Anda bisa menggunakan salah satu saja atau mengombinasikannya jika aplikasi perlu kedua kemampuan tersebut.

Apakah worker didukung di semua browser?

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:

• Mereka memerlukan HTTPS (kecuali localhost untuk development).
• Beberapa fitur (seperti push notification) bervariasi antar browser dan platform.

Jika kompatibilitas lebar penting, perlakukan fitur Service Worker sebagai progressive enhancement: bangun pengalaman inti yang baik terlebih dulu, lalu tambahkan offline/push bila tersedia.

Apakah ini otomatis membuat situs saya lebih cepat?

Tidak otomatis.

• Web Worker membantu ketika situs Anda melambat karena JavaScript CPU-heavy di main thread. Memindahkan pekerjaan itu bisa mengurangi jank dan meningkatkan responsivitas—tetapi Anda tetap membayar overhead untuk mengirim data bolak-balik.
• Service Worker membantu ketika situs Anda melambat karena request jaringan. Caching dan penanganan fetch yang cerdas bisa membuat kunjungan ulang terasa instan—tetapi caching yang salah bisa menyebabkan konten kadaluarsa.

Keuntungan nyata datang dari menggunakan worker yang tepat untuk bottleneck yang tepat, dan mengukur sebelum dan sesudah.