Web Workers vs Service Workers: nedir ve neden

Web Workers vs Service Workers: hızlı bakış

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.

Worker'ların çözdüğü sorun

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.

Kısa tanımlar

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.

Basit bir zihinsel model: “iş parçacıkları” vs “ağ vekili”

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.

Bu makalede neler öğreneceksiniz

Sonunda şunları bileceksiniz:

• performans için ne zaman bir Web Worker doğru araçtır (ve neler erişilemez)
• Service Worker ile çevrimdışı önbellekleme, güncellemeler ve PWA davranışlarının neler sağladığı
• mesajlaşmanın (ör. postMessage) worker modeline nerede uyduğu ve çevrimdışı için Cache Storage API'nin neden önemli olduğu

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

Tarayıcıların worker'lara neden ihtiyacı var

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.

Ana iş parçacığı bir ortak kasa sırası gibidir

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:

• Kaydırma takılmaları (jank)
• Butonların tıklamalara hemen yanıt vermemesi
• Yazma tuşlarına gecikmeli tepki
• Animasyonların bir an için donması

Asenkron, paralel demek değildir

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ı mimarisinde nereye uyar

Worker'lar, tarayıcıların sayfayı duyarlı tutarken anlamlı işler yapabilmesini sağlar.

• Web Worker'lar CPU-ağırlıklı işler için JavaScript'i arka planda çalıştırmanızı sağlar.
• Service Worker'lar herhangi bir sayfaya bağlı olmadan çalışır, ağ ve önbellek katmanı gibi davranır ve sayfa açık olmasa bile görev yapabilir.

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

Web Worker nedir?

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.

Nerede çalışır

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.

Dedicated Worker vs Shared Worker

Yaygın iki tür vardır:

• Dedicated Worker: tek bir sayfa/sekme ile bağlantılıdır. O sayfa kapandığında worker genellikle sonlandırılır.
• Shared Worker: aynı origin'den gelen birden çok sayfa/sekme tarafından paylaşılabilir; birden fazla sekme arasında ortak bir bağlantı veya durum senkronizasyonu için faydalıdır.

Eğer hiç worker kullanmadıysanız, gördüğünüz örneklerin çoğu Dedicated Worker olur.

Web Worker iletişimi nasıl olur

Worker'lar sayfanızdaki fonksiyonları doğrudan çağırmaz. Bunun yerine iletişim mesajlaşma ile olur:

• Sayfa veriyi postMessage() ile worker'a gönderir.
• Worker da yanıtı postMessage() ile geri gönderir.
• Veri, structured clone algoritması ile aktarılır; bu, nesneler, diziler, Map/Set, ArrayBuffer gibi pek çok yerleşik tipi destekler.

Büyük ikili veriler için, ArrayBuffer'ın sahipliğini transfer ederek (kopyalamak yerine) performansı iyileştirebilirsiniz; bu, mesajlaşmayı hızlı tutar.

Yaygın sınırlamalar (tasarımdan dolayı)

Worker izole olduğu için birkaç önemli kısıtlama vardır:

• Doğrudan DOM erişimi yok: worker sayfanın HTML'ini, CSS'ini veya düzenini okuyamaz/değiştiremez.
• Farklı global'ler: window veya document yoktur. Worker'lar self altında çalışır ve kullanılabilen API'lar ana sayfadan farklı olabilir.
• Asenkron yaklaşım: her şey mesaj tabanlı olduğundan kodunuzu işi gönderip sonucu almak üzere yapılandırırsınız.

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 ne zaman kullanılmalı (ve ne zaman kullanılmamalı)

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.

Web Worker için en iyi kullanım alanları

DOM'a doğrudan erişmesi gerekmeyen CPU-ağırlıklı işler için Web Worker kullanın:

• Ağır hesaplamalar: simülasyonlar, veri sıkıştırma, analizler
• Ayrıştırma ve dönüşüm: büyük JSON ayrıştırma, CSV işlemleri, şema doğrulama
• Sıkıştırma / açma: zip/gzip tarzı işler, kodlama/çözme
• Görüntü işleme: yeniden boyutlandırma, filtreleme, küçük resim oluşturma (destekleyen tarayıcılarda OffscreenCanvas ile birlikte)

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.

Veri işleme ipuçları (hız için)

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.

Web Worker kullanmamayı tercih etmeniz gereken durumlar

Worker'ların bir maliyeti vardır: ekstra dosyalar, mesajlaşma gecikmesi ve farklı bir hata ayıklama akışı. Onları şu durumlarda kullanmayın:

• Görev çok küçük (milisaniyeler) ve nadiren çalışıyorsa.
• İş sık sık DOM okuma/yazma gerektiriyorsa (worker'lar DOM'a dokunamaz).
• Ultra düşük gecikmeli sürekli mesajlaşma gerekiyorsa; sık postMessage ping-pong faydayı yok edebilir.

Basit bir pratik kural

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.

Service Worker nedir?

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.

Yaşam döngüsü temelleri (register → install → activate → control)

Service Worker'ın yaşam döngüsü tek bir sekmeden ayrıdır:

• Register: sayfa tarayıcıya “bu site bir service worker'a sahip” der (genellikle ana JS'ten).
• Install: tarayıcı script'i indirir ve install adımını çalıştırır; bu adım genellikle önemli dosyaları önbelleğe almak için kullanılır.
• Activate: yeni worker devralır, genellikle eski sekmeler kapandıktan veya güvenli bir değişim zamanında.
• Control: aktif olduğunda kapsam içindeki sayfaları “kontrol” edebilir ve istekleri yakalamaya başlayabilir.

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.

Scope ve origin kuralları (yüksek seviyede)

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.

Sık görülen API'lar

• Fetch event: istekleri yakalayın ve ağ mı, önbellek mi yoksa özel bir cevap mı döndürüleceğine karar verin.
• Cache Storage API: çevrimdışı kullanım ve hız için yanıtları depolayın/getirin.
• Clients API: worker'ın kontrol ettiği açık sekmeleri/ pencereleri yönetin ve onlarla iletişim kurun.

Service Worker ne için kullanılır

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.

Çevrimdışı destek (akıllı önbellekleme)

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:

• Cache-first: statik dosyalar (CSS, JS, logolar) için mükemmel. Hızlı, çevrimdışı çalışır.
• Network-first: sık değişen içerik için iyi (haberler, feed). Çevrimdışıyken önbelleğe döner.
• Stale-while-revalidate: önbellekteki içeriği hemen gösterir, arka planda günceller.

Bu genellikle Cache Storage API ve fetch event işleme ile uygulanır.

Tekrar ziyaretlerde daha hızlı yükleme

Service Worker'lar dönüş ziyaretlerinde algılanan hızı artırabilir:

• Precaching: kurulum sırasında “olmazsa olmaz” dosyaları kaydetme (genellikle app shell).
• Runtime caching: kullanıcı gezinirken sayfaları veya API yanıtlarını önbelleğe alma.

Sonuç: daha az ağ isteği, daha hızlı başlatma ve zayıf bağlantılarda daha tutarlı performans.

Arka plan özellikleri (destek varsa)

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.

PWA yapı taşları

Bir progressive web app geliştiriyorsanız, Service Worker'lar şunların arkasındaki temel parçadır:

• Installability (web app manifest ile birlikte)
• Güvenilir çevrimdışı sayfalar (ör. kullanıcı dostu bir fallback)
• Hızlı gezinme için app shell modeli

Temel farklar: Web Worker vs Service Worker

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.

Nerede çalışırlar (hangi işe yararlar)

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.

Yaşam süresi ve “kimin kontrolünde olduğu”

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.

Ağ erişimi ve kontrol

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.

Depolama ve önbellekleme

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.

Nasıl kurulur (yüksek seviyede adımlar)

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.

Web Worker: sayfadan oluşturun

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: bir kez kaydedin ve tarayıcının yüklemesine izin verin

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.

Neden Service Worker HTTPS gerektirir

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.

Versiyonlama zihniyeti: worker dosyalarını dağıtılabilir “sürümler” gibi düşünün

Tarayıcılar worker'ları normal script'lerden farklı şekilde önbellekler ve günceller. Güncellemeyi planlayın:

• Davranış değiştiğinde dosyayı değiştirin (genellikle yeni bir sw.js/worker bundle yayınlayın).
• Service Worker'da yeni worker kurulur, güvenli olduğunda devreye girer. Güncelleme akışını bekleyin.
• Önbellek kurallarını değiştirdiğinizde, activation sırasında eski önbellekleri temizleyecek mantık ekleyin.

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.

Tarayıcıda worker'ları hata ayıklama ve test etme

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.

Web Worker hata ayıklama (DevTools)

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:

• Konsol logları: Web Worker logları DevTools'ta görünür; doğru bağlamı görüntülediğinizden emin olun.
• Breakpoint'ler: worker script içinde breakpoint koyun; onmessage handler'larında ve uzun süren fonksiyonlarda adım adım ilerleyin.
• Performans profili: bir Performance kaydı alın ve ana iş parçacığının worker ağır işi yaparken duyarlı kaldığını doğrulayın.

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 hata ayıklama (Application paneli)

Service Worker'lar Application panelinde en iyi şekilde hata ayıklanır:

• Kayıt durumu, scope, aktif/waiting/installed sürümleri kontrol edin.
• Skip waiting ve Unregister gibi yaşam döngüsü kontrollerini kullanarak kötü bir durumu sıfırlayın.
• İterasyon sırasında stale kod peşinde koşmayı önlemek için Update on reload özelliğini açın.

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.

Yaygın tuzaklar ve test ipuçları

Ö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:

• Offline modunu simüle edin ve fallback sayfalarını doğrulayın
• Ağ yavaşlatma uygulayın
• Service Worker güncellemelerini ve mesajlaşmayı doğrulamak için sayfayı birkaç kez yeniden yükleyin

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.

Güvenlik, gizlilik ve performans dikkate alınması gerekenler

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.

Güvenlik sınırları (ve neden aynı-origin önemlidir)

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.

Gizlilik ve kullanıcı beklentileri

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.

İzlenecek performans riskleri

Worker'lar “ücretsiz” performans sunmaz. Aşırı kullanımları ters etki yaratabilir:

• Mesaj yükü: sık postMessage çağrıları (özellikle büyük nesnelerle) darboğaz yaratabilir. Toplu işlemeyi ve uygun yerlerde transferable kullanmayı tercih edin.
• Bellek maliyeti: her worker kendi belleğine ve başlatma maliyetine sahiptir; çok fazla worker RAM kullanımını ve pil tüketimini artırabilir.
• Önbellek büyümesi: agresifçe önbelleğe alan bir Service Worker depolamayı şişirebilir. Güncellemeler sırasında önbellek sınırlamaları ve temizlik ekleyin.

Zarif geri dönüş (graceful fallback)

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.

Hem birlikte kullanılan yaygın desenler

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.

Desen 1: Görüntü işlemeden oluşan çevrimdışı galeri

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.

• Web Worker CPU-ağırlıklı işi yapar (decode, transform, küçük resimler üretme) böylece kaydırma ve dokunuşlar akıcı kalır.
• Service Worker üretilen küçük resimleri ve orijinallerini Cache Storage'da (veya metadata için IndexedDB'de) önbelleğe alır ve tekrar ziyaretlerde veya çevrimdışında anında servis eder.

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.

Desen 2: Veri senkronizasyonu + arka plan önbellekleme

Feed, form veya saha verisi olan uygulamalar için:

• Web Worker büyük JSON'ları normalleştirebilir, diff hesaplayabilir veya veri doğrulama yapabilir; UI'yı engellemez.
• Service Worker API yanıtlarını hızlı başlatma için önbelleğe alabilir ve çevrimdışı okumaları yönetir. Bağlantı geri geldiğinde önbelleği yenileyebilir ve (destekliyorsa) background sync ile koordinasyon sağlayabilir.

Tam background sync olmasa bile service worker tekrar ziyaretlerde önbellekten hizmet vererek algılanan hızı iyileştirir.

Sorumlulukları ayrı tutmak

Rolleri karıştırmaktan kaçının:

• UI iş parçacığı: render, kullanıcı girişi, erişilebilirlik, minimal durum bağlantısı.
• Web Worker: saf hesaplama ve veri hazırlama (genellikle postMessage ile).
• Service Worker: istek yönlendirme, önbellek stratejisi, çevrimdışı fallback.

Hızlı kontrol listesi: hangisine ihtiyacınız var?

• Görev CPU-ağırlıklı mı (ayrıştırma, kodlama, kripto, görüntü/ses işleme)? Web Worker kullanın.
• Görev fetch yakalama, çevrimdışı davranış veya önbellekleme ile ilgili mi? Service Worker kullanın.
• Hem hızlı UI hem hızlı yükleme/çevrimdışı mı istiyorsunuz? İkisini de kullanın, ama sınırı net tutun: hesaplama web worker'da, saklama/servis service worker'da.