05 Eyl 2025·7 dk
Web Workers vs Service Workers: nedir ve neden
Web Worker ve Service Worker nedir, nasıl farklılaşırlar ve daha hızlı sayfalar, arka plan görevleri, önbellekleme ile çevrimdışı destek için hangisini ne zaman kullanmalısınız öğrenin.
Web Worker ve Service Worker nedir, nasıl farklılaşırlar ve daha hızlı sayfalar, arka plan görevleri, önbellekleme ile çevrimdışı destek için hangisini ne zaman kullanmalısınız öğrenin.
Tarayıcılar JavaScript'in çoğunu ana iş parçacığında çalıştırır—kullanıcı girdisi, animasyonlar ve sayfanın çizimi aynı yerde yürütülür. Orada ağır işler (büyük verilerin ayrıştırılması, görüntü işleme, karmaşık hesaplamalar) olursa, UI takılabilir veya “donabilir.” Worker'lar belirli görevleri ana iş parçacığından uzaklaştırmak veya sayfanın doğrudan kontrolü dışına almak için vardır, böylece uygulamanız duyarlı kalır.
Sayfanız 200ms süren bir hesaplama yapıyorsa, tarayıcı düzgün kaydırma yapamaz, tıklara cevap veremez veya animasyonları 60fps'de tutamaz. Worker'lar arka planda iş yapmanızı sağlayarak ana iş parçacığının arayüze odaklanmasını sağlar.
Bir Web Worker, bir sayfadan oluşturduğunuz arka plan JavaScript iş parçacığıdır. UI'yi engelleyecek CPU-ağırlıklı işler için en uygunudur.
Bir Service Worker, web uygulamanız ile ağ arasında duran özel bir worker türüdür. İstekleri yakalayabilir, yanıtları önbelleğe alabilir ve çevrimdışı destek veya push bildirimleri gibi özellikleri etkinleştirebilir.
Web Worker'ı başka bir odada hesaplama yapan bir yardımcı olarak düşünün. Ona mesaj gönderirsiniz, o çalışır ve geri mesaj atar.
Service Worker'ı ise ön kapıda duran bir bekçi olarak düşünün. Sayfa, script ve API istekleri onun yanından geçer; ağdan çekmeye, önbellekten sağlamaya veya özel bir cevap vermeye karar verebilir.
Sonunda şunları bileceksiniz:
postMessage) worker modeline nerede uyduğu ve çevrimdışı için Cache Storage API'nin neden önemli olduğuBu genel bakış “neden” ve zihinsel modeli kurar—sonraki bölümde her worker türünün nasıl davrandığına ve gerçek projelerde nereye uyduğuna derinlemesine bakacağız.
Bir web sayfasını açtığınızda, “hissettiğiniz” çoğu şey ana iş parçacığında olur. Piksel çizimi (render), dokunma ve tıklamalara tepki (input) ve birçok JavaScript yürütme burada gerçekleşir.
Render, input işleme ve JavaScript genellikle aynı iş parçacığında sırayla çalıştığı için, tek bir yavaş görev her şeyi bekletebilir. Bu yüzden performans sorunları genellikle sadece “yavaş kod” değil, duyarlılık sorunları olarak görünür.
Kullanıcılar için “engelleme” şöyle hissedilir:
JavaScript birçok asenkron API'ye sahiptir—fetch(), zamanlayıcılar, olaylar—bunlar boş beklemeyi önlemeye yardımcı olur. Ancak asenkron olmak, ağır işlerin render ile aynı anda magiksel olarak gerçekleşmesi demek değildir.
Ana iş parçacığında pahalı hesaplamalar (görüntü işleme, büyük JSON ayrıştırma, kripto, karmaşık filtreleme) yaparsanız, bunlar yine UI güncellemeleriyle yarışır. “Asenkron” işi ne zaman çalıştıracağınızı erteleyebilir ama yine ana iş parçacığında çalışıyorsa çalıştığında jank yaratabilir.
Worker'lar, tarayıcıların sayfayı duyarlı tutarken anlamlı işler yapabilmesini sağlar.
Özetle: worker'lar ana iş parçacığını korumanın bir yoludur, böylece uygulamanız arayüzü sunarken arkada gerçek işler yapılabilir.
Bir Web Worker, JavaScript'i ana iş parçacığının dışında çalıştırmanın bir yoludur. UI işleriyle (render, kaydırma, tıklamalara yanıt) yarışmak yerine, worker kendi arka plan iş parçacığında çalışır; böylece ağır görevler sayfanın “takılma” hissi vermeden tamamlanır.
Bunu şöyle düşünün: sayfa kullanıcı etkileşimine odaklanırken, worker büyük bir dosyayı ayrıştırma, sayı hesabı yapma veya grafikler için veri hazırlama gibi CPU-ağırlıklı işleri halleder.
Bir Web Worker, kendi global kapsamına sahip ayrı bir iş parçacığında çalışır. Hâlâ birçok web API'sine erişimi vardır (zamanlayıcılar, pek çok tarayıcıda fetch, crypto vb.), fakat sayfadan kasıtlı olarak izole edilmiştir.
Yaygın iki tür vardır:
Eğer hiç worker kullanmadıysanız, gördüğünüz örneklerin çoğu Dedicated Worker olur.
Worker'lar sayfanızdaki fonksiyonları doğrudan çağırmaz. Bunun yerine iletişim mesajlaşma ile olur:
postMessage() ile worker'a gönderir.postMessage() ile geri gönderir.Büyük ikili veriler için, ArrayBuffer'ın sahipliğini transfer ederek (kopyalamak yerine) performansı iyileştirebilirsiniz; bu, mesajlaşmayı hızlı tutar.
Worker izole olduğu için birkaç önemli kısıtlama vardır:
window veya document yoktur. Worker'lar self altında çalışır ve kullanılabilen API'lar ana sayfadan farklı olabilir.Doğru kullanıldığında, bir Web Worker ana iş parçacığı performansını artırmanın en basit yollarından biridir—uygulamanızın ne yaptığını değiştirmeden sadece pahalı işin nerede yapıldığını değiştirirsiniz.
Web Worker'lar, sayfanız JavaScript nedeniyle “takılıyorsa” mükemmel bir çözümdür. Ana iş parçacığı kullanıcı etkileşimleri ve render için sorumludur, bu yüzden oradaki ağır işler jank, gecikmeli tıklamalar ve donmuş kaydırma yaratabilir.
DOM'a doğrudan erişmesi gerekmeyen CPU-ağırlıklı işler için Web Worker kullanın:
Pratik örnek: büyük bir JSON yükü alıyorsunuz ve ayrıştırma UI'yi takıyorsa, ayrıştırmayı bir worker'a taşıyın ve sonucu geri gönderin.
Worker ile iletişim postMessage ile olur. Büyük ikili verilerde, tarayıcıya bellek sahipliğini aktarması için transferable nesneler (ArrayBuffer gibi) kullanın; böylece veri kopyalanmaz:
// main thread
worker.postMessage(buffer, [buffer]); // ArrayBuffer'ı transfer eder
Bu, ses buffer'ları, görüntü baytları veya diğer büyük veri parçaları için özellikle faydalıdır.
Worker'ların bir maliyeti vardır: ekstra dosyalar, mesajlaşma gecikmesi ve farklı bir hata ayıklama akışı. Onları şu durumlarda kullanmayın:
postMessage ping-pong faydayı yok edebilir.Bir görev gözle görülür bir duraklama (genellikle ~50ms+) yaratabiliyorsa ve “girdi → hesapla → çıktı” şeklinde DOM erişimi gerektirmeden ifade edilebiliyorsa, genellikle Web Worker değer. İş çoğunlukla UI güncelleme ise ana iş parçacığında kalın ve orayı optimize edin.
Bir Service Worker, tarayıcının arka planında çalışan ve siteniz için programlanabilir bir ağ katmanı gibi davranan özel bir JavaScript dosyasıdır. Sayfanın kendisinden ziyade uygulamanız ile ağ arasına oturur; kaynaklar (HTML, CSS, API çağrıları, resimler) istendiğinde ne yapılacağına karar verebilir.
Service Worker'ın yaşam döngüsü tek bir sekmeden ayrıdır:
Tarayıcı worker'ı durdurup yeniden başlatabileceği için, onu olay odaklı bir script gibi ele alın: işleri hızlı yapın, durumu kalıcı depolamada saklayın ve her zaman açık olduğunu varsaymayın.
Service Worker'lar aynı origin ile sınırlıdır (aynı domain/protokol/port) ve yalnızca kendi kapsamları altındaki sayfaları kontrol edebilir—genellikle worker dosyasının sunulduğu klasör ve altı. Ayrıca HTTPS gerektirir (localhost hariç) çünkü ağ isteklerini etkileyebilirler.
Service Worker esasen uygulamanız ile ağ arasına oturur. Ağın ne zaman kullanılacağına, ne zaman önbelleğe başvurulacağına ve ne zaman arka planda biraz iş yapılacağına karar verebilir—sayfayı engellemeden.
En yaygın işi, varlıkları ve yanıtları önbelleğe alarak çevrimdışı veya zayıf bağlantı deneyimleri sağlamaktır.
Yaygın önbellekleme stratejileri:
Bu genellikle Cache Storage API ve fetch event işleme ile uygulanır.
Service Worker'lar dönüş ziyaretlerinde algılanan hızı artırabilir:
Sonuç: daha az ağ isteği, daha hızlı başlatma ve zayıf bağlantılarda daha tutarlı performans.
Service Worker'lar push bildirimleri ve background sync gibi arka plan özelliklerini destekleyebilir (tarayıcı ve platforma göre değişir). Bu sayede kullanıcıyı bildirebilir veya başarısız olan bir isteği bağlantı geri geldiğinde tekrar deneyebilirsiniz—sayfa açık olmasa bile.
Bir progressive web app geliştiriyorsanız, Service Worker'lar şunların arkasındaki temel parçadır:
Sadece bir şeyi unutmayın: Web Worker'lar sayfanızın UI'sını dondurmadan ağır işi yapmasına yardım eder, oysa Service Worker'lar uygulamanızın ağ isteklerini kontrol etmesine ve bir kurulumla (PWA) yüklenebilir davranmasına yardımcı olur.
Web Worker CPU-ağırlıklı işler içindir—büyük veriyi ayrıştırma, küçük resimler oluşturma, sayı hesaplama—böylece ana iş parçacığı duyarlı kalır.
Service Worker istek işleme ve uygulama yaşam döngüsü işleri içindir—çevrimdışı destek, önbellekleme stratejileri, background sync ve push bildirimleri. Ağ ile uygulama arasına oturabilir.
Web Worker genellikle bir sayfa/sekme ile bağlıdır. Sayfa kapanınca worker da genellikle kapanır (SharedWorker hariç).
Service Worker ise olay odaklıdır. Tarayıcı bir olayı (fetch, push vb.) işlemek için worker'ı başlatabilir; sayfa açık olmasa bile çalışabilir.
Web Worker sayfanın yaptığı ağ isteklerini yakalayamaz. Kendi fetch() çağrılarını yapabilir ama diğer sayfa isteklerini yeniden yazamaz veya genel olarak serve edemez.
Service Worker fetch eventi aracılığıyla ağ isteklerini yakalayabilir, ağdan mı çekileceğine, önbellekten mi verileceğine veya yedek bir cevap mı döndürüleceğine karar verebilir.
Web Worker HTTP önbelleklemesini yönetmez.
Service Worker genellikle Cache Storage API'yi kullanarak istek/yanıt çiftlerini depolar—bu çevrimdışı önbellekleme ve “anında” tekrar yüklemelerin temelidir.
Worker çalıştırmak çoğunlukla nereden çalıştığına ve nasıl yüklendiğine bağlıdır. Web Worker'lar sayfa tarafından doğrudan oluşturulur. Service Worker'lar sayfa tarafından kayıt edilir ve siteniz için isteklerin “önünde” oturur.
Bir Web Worker, sayfanız onu yarattığında başlar. Ayrı bir JavaScript dosyasına işaret edersiniz ve postMessage ile iletişim kurarsınız.
// main.js (sayfada çalışıyor)
const worker = new Worker('/workers/resize-worker.js', { type: 'module' });
worker.postMessage({ action: 'start', payload: { /* ... */ } });
worker.onmessage = (event) => {
console.log('From worker:', event.data);
};
İyi bir zihinsel model: worker dosyası sayfanızın alabileceği başka bir script URL'sidir, ama ana iş parçacığının dışında çalışır.
Service Worker'lar bir sayfa tarafından kaydedilmelidir:
// main.js
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/sw.js');
}
Kayıttan sonra tarayıcı install/activate yaşam döngüsünü yönetir. sw.js içinde install, activate ve fetch gibi olayları dinleyebilirsiniz.
Service Worker'lar ağ isteklerini yakalayabilir ve yanıtları önbelleğe alabilir. Kayıt HTTP üzerinden izin verilseydi, bir saldırgan kötü amaçlı bir sw.js ile ziyaretleri kontrol edebilir. HTTPS (veya geliştirme için http://localhost) script'i ve etkileyeceği trafiği korur.
Tarayıcılar worker'ları normal script'lerden farklı şekilde önbellekler ve günceller. Güncellemeyi planlayın:
sw.js/worker bundle yayınlayın).Daha yumuşak bir dağıtım stratejisi isterseniz, update kenar durumlarını erken yakalayan test alışkanlıkları için /blog/debugging-workers bölümüne bakın.
Worker'lar “normal” sayfa JavaScript'inden farklı şekillerde başarısız olur: ayrı bağlamlarda çalışır, kendi konsolu vardır ve tarayıcı tarafından yeniden başlatılabilir. Güçlü bir hata ayıklama rutini saatler kazandırır.
DevTools'u açın ve worker'a özel hedefleri arayın. Chrome/Edge'de worker'ları genellikle Sources altında (veya “Dedicated worker” girişiyle) ve Console bağlam seçicisinde görürsünüz.
Aynı araçları ana iş parçacığında kullandığınız gibi kullanın:
onmessage handler'larında ve uzun süren fonksiyonlarda adım adım ilerleyin.Mesajlar “kayboluyormuş” gibiyse, her iki tarafı da inceleyin: worker.postMessage(...) çağrıldığını, worker'da self.onmessage = ... olduğunu ve mesaj yapısının eşleştiğini doğrulayın.
Service Worker'lar Application panelinde en iyi şekilde hata ayıklanır:
Ayrıca kuruluma/aktivasyona/fetch hatalarına ilişkin logları Console'da izleyin—bunlar genellikle önbellekleme veya çevrimdışı davranışın neden çalışmadığını açıklar.
Önbellekleme sorunları en büyük zaman kaybıdır: yanlış dosyaları (veya aşırı agresif şekilde) önbelleğe almak eski HTML/JS'in kalmasına neden olabilir. Testler sırasında hard reload yapın ve gerçekte neyin servis edildiğini doğrulayın.
Gerçekçi test için DevTools'u kullanın:
PWA üzerinde hızlı iterasyon yaparken, öngörülebilir bir Service Worker ve build çıktısı olan temiz bir başlangıç uygulaması üretmek ve sonra önbellek stratejilerini buradan geliştirmek yardımcı olur. Koder.ai gibi platformlar bu tür denemeler için kullanışlı olabilir: bir React tabanlı web uygulamasını sohbet isteminden prototipleyebilir, kaynak kodu dışa aktarabilir ve worker kurulumunuzu daha sık geri bildirim döngüsüyle ayarlayabilirsiniz.
Worker'lar uygulamaları daha yumuşak ve yetenekli yapar, ancak kodun nerede çalıştığını ve nereye eriştiğini değiştirir. Güvenlik, gizlilik ve performans açısından kısa bir kontrol sizi sürpriz hatalardan ve memnuniyetsiz kullanıcılardan korur.
Hem Web Worker hem Service Worker same-origin policy ile kısıtlanır: doğrudan sadece aynı scheme/host/port'tan kaynaklara erişebilirler (sunucu CORS ile açıkça izin vermedikçe). Bu, bir worker'ın başka bir siteden sessizce veri çekip uygulamanıza karıştırmasını önler.
Service Worker'lar ek güvenlik önlemlerine sahiptir: genellikle HTTPS gerektirirler (veya geliştirme için localhost). Onları ayrıcalıklı kod gibi düşünün: bağımlılıkları az tutun, dinamik kod yüklemekten kaçının ve önbellek mantığınızı sürümlendirerek eski önbelleklerin servis edilmesini engelleyin.
Arka plan özellikleri öngörülebilir hissettirmelidir. Push bildirimleri güçlüdür ama izin istemleri kötüye kullanılmaya çok açıktır.
İznin net bir faydası olduğunda isteyin (ör. kullanıcı ayarlarda uyarıları açtığında) ve neler alacaklarını açıklayın. Arka planda veri senkronize ediyorsanız veya önceden veri indiriyorsanız bunu sade dille belirtin—kullanıcılar beklenmeyen ağ etkinliğini veya bildirimleri fark eder.
Worker'lar “ücretsiz” performans sunmaz. Aşırı kullanımları ters etki yaratabilir:
postMessage çağrıları (özellikle büyük nesnelerle) darboğaz yaratabilir. Toplu işlemeyi ve uygun yerlerde transferable kullanmayı tercih edin.Her tarayıcı her capability'i desteklemez (veya kullanıcı izinleri bloke edebilir). Özelliği tespit edin ve düzgün şekilde degrade edin:
if ('serviceWorker' in navigator) {
// service worker kaydet
} else {
// çevrimdışı özellikler olmadan devam et
}
Hedef: temel işlevsellik yine de çalışsın; “iyi-olması-gerekenler” (çevrimdışı, push, ağır hesaplamalar) mevcut olduğunda üst üste eklenebilsin.
Web Worker ve Service Worker farklı problemleri çözdüğünden, bir uygulama hem ağır hesaplama hem hızlı güvenilir yükleme istediğinde birlikte iyi eşleşirler. İyi bir zihinsel model: Web Worker = hesaplama, Service Worker = ağ + önbellek, ana iş parçacığı = UI.
Kullanıcıların fotoğraf düzenlediği (yeniden boyutlandırma, filtre, arka plan kaldırma) ve daha sonra bağlantı olmadan galeriyi görüntülediği bir uygulama düşünün.
Bu “hesapla sonra önbelleğe al” yaklaşımı sorumlulukları net tutar: worker çıktı üretir, service worker nasıl saklanıp servis edileceğine karar verir.
Feed, form veya saha verisi olan uygulamalar için:
Tam background sync olmasa bile service worker tekrar ziyaretlerde önbellekten hizmet vererek algılanan hızı iyileştirir.
Rolleri karıştırmaktan kaçının:
postMessage ile).Bir Web Worker, işi girdi → hesaplama → çıktı olarak ifade edilebilen ve DOM'a erişmesi gerekmeyen CPU-ağırlıklı işler için kullanın.
İyi örnekler: büyük yükleri ayıklama/dönüştürme, sıkıştırma, kriptografi, görüntü/ ses işleme ve karmaşık filtreleme. İş çoğunlukla UI güncellemeleri veya sık DOM okuma/yazma içeriyorsa, worker yardımcı olmaz (ayrıca worker'lar DOM'a erişemez).
Ağ düzeyinde kontrol gerektiğinde Service Worker kullanın: çevrimdışı destek, önbellek stratejileri, tekrar ziyaretlerde hız ve istek yönlendirme ile (destekliyorsa) push/background sync.
UI, hesaplama yaparken donuyorsa Web Worker sorunudur. Yükleme yavaşsa veya çevrimdışı deneyim bozuksa Service Worker çözümüdür.
Hayır. Web Worker ve Service Worker bağımsız özelliklerdir.
İhtiyaç varsa tek başlarına veya birlikte kullanılabilirler.
Özetle kapsam ve yaşam süresi farkı vardır.
fetch gibi bir olayla uyanabilir, görevini yapıp boşta kaldığında kapanabilir.Hayır. Web Worker'ların window/document erişimi yoktur.
UI'yi etkilemeniz gerekiyorsa, veriyi ana iş parçacığına postMessage() ile gönderin; DOM güncellemelerini sayfa kodunda yapın. Worker'ı saf hesaplamaya odaklı tutun.
Hayır. Service Worker'ların da DOM erişimi yoktur.
Kullanıcıya gösterilecek şeyi etkilemek için kontrol ettiği sayfalarla mesajlaşın (ör. Clients API + postMessage()), ve sayfanın UI'yı güncellemesine izin verin.
İki taraf da postMessage() kullanır.
worker.postMessage(data)self.postMessage(result)Büyük ikili veriler için, kopyalamayı önlemek üzere transferable nesneler (ör. ArrayBuffer) tercih edin:
Service Worker'lar uygulamanız ile ağ arasına oturur ve istekleri Cache Storage API ile yanıtlayabilir.
Yaygın stratejiler:
Kaynak türüne göre strateji seçin (app shell vs API verisi).
Evet; sorumlulukları net tutun.
Yaygın desen:
Bu, arka plan mantığını UI'dan ayırır ve performansı tahmin edilebilir kılar.
Her biri için doğru DevTools yüzeyini kullanın.
onmessage içinde breakpoint koyun ve ana iş parçacığının responsive kaldığını doğrulamak için profil alın.Önbellekleme hatalarını ayıklarken, hangi cevabın (ağ mı önbellek mi) döndüğünü doğrulayın ve offline/throttling testleri yapın.
worker.postMessage(buffer, [buffer]);