Service Worker, tarayıcı ile ağ arasına yerleşen bir JavaScript katmanıdır. Sayfadan gelen her fetch isteğini yakalayabilir, önbellekten yanıtlayabilir, ağa iletebilir ya da bu iki yolu birleştirebilir. Bu esneklik güçlü bir araç sunar; ancak gücün büyüklüğü, dikkat edilmezse üretilen sorunun büyüklüğüyle doğru orantılı olur. Önbelleği yöneten kodu siz yazıyorsunuz; bu hem kazanımın hem olası tutarsızlığın tam sebebidir.

Service Worker'ın performansa katkısını değerlendirmek için "ekledik mi?" sorusu değil, "hangi stratejiyle, hangi içerik türüne uyguladık?" sorusu belirleyicidir. Bu ayrım yapılmadan verilen kararlar çoğunlukla ya kullanılmayan bir altyapı katmanı ya da bakımı güç bir önbellek karmaşası üretir.

Fetch olayını ele geçirmek: ağ ile tarayıcı arasındaki konum

Service Worker yüklendiğinde ve etkinleştiğinde, kapsamındaki tüm sayfalara ait fetch isteklerini dinlemeye başlar. Bir kullanıcı CSS dosyası istediğinde, bir API çağrısı yaptığında ya da bir görsel yüklendiğinde bu istek önce Service Worker'a ulaşır. Worker bu isteği ya önbellekten karşılar, ya ağa iletir ya da her ikisini de belirli bir sıraya göre dener.

Bu konumun getirdiği en somut kazanım, tekrar eden ziyaretçiler için ölçülebilir biçimde ortaya çıkar. İlk ziyarette statik varlıklar ağdan indirilir ve önbelleğe alınır. İkinci ziyarette bu dosyalar diskten gelir; ağ gecikmesi, sunucu yanıt süresi ve TLS maliyeti tamamen devre dışı kalır. CSS veya font gibi kritik varlıklar için bu fark, LCP süresini onlarca milisaniye kısaltabilir.

Ancak bu konumun bir maliyeti vardır: Service Worker'ın kendisi de bir kaynak kullanır. Kayıt, kurulum ve etkinleştirme aşamaları ilk yüklemede ek bir iş yükü oluşturur. İlk ziyarette performans kazanımı yoktur; tersine, küçük bir ek maliyet söz konusudur. Service Worker yatırımı yalnızca tekrar eden ziyaretçi oranının anlamlı olduğu projelerde gerçek bir performans metriki iyileşmesi üretir.

Cache-first strateji hız üretir, güncelleme sorununu da beraberinde getirir

Cache-first stratejide Service Worker önce önbelleğe bakar. İstek burada karşılanabiliyorsa ağa hiç çıkmaz. Bu yaklaşım tekrar eden ziyaretçiler için en hızlı yanıt süresini verir; statik varlıklar için mükemmel uyum sağlar. JS bundle, CSS, font ve değişmeyen görseller cache-first için ideal adaylardır.

Sorun, bu stratejinin içerik değiştiğinde ne yapacağını bilmemesinden kaynaklanır. Service Worker önbellekte bir yanıt bulduğu sürece ağa gitmez. Yeni bir deployment yaptınız, CSS güncellendi, ancak kullanıcı eski Service Worker ve önbellekle çalışmaya devam ediyor. Deployment sonrası yeni bir Service Worker yüklense bile etkinleşmesi için tüm sekmelerin kapatılması gerekir. Bu süreç saatler sürebilir; kullanıcılar bu süre içinde eski içerikle gezinir.

Bu nedenle cache-first strateji yalnızca içerik hash'iyle versiyonlanmış varlıklar için güvenlidir. URL'nin kendisi değiştiğinde Service Worker önbellekte eşleşen bir kayıt bulamaz ve ağa çıkar. Hash değişmemişse içerik de değişmemiştir; önbellekten karşılamak güvenlidir. Bu ayrım yapılmadan tüm varlıklara cache-first uygulamak, güncelleme sorununu sistematik hale getirir.

Network-first ve stale-while-revalidate: tazelik ile hız arasındaki denge

Network-first stratejide Service Worker önce ağa çıkar. Yanıt gelirse önbelleği günceller ve yanıtı iletir. Ağ erişilemezse önbellekteki eski sürümü kullanır. Bu yaklaşım içeriğin her zaman güncel olmasını ön planda tutar; ancak önbelleklemenin asıl hız kazanımından yararlanamaz. Çevrimdışı destek için bir güvenlik ağı sağlar, performans optimizasyonu için değil.

Stale-while-revalidate ise bu iki yaklaşım arasında daha nüanslı bir denge kurar. Service Worker önce önbellekteki yanıtı iletir —kullanıcı beklemez— arka planda ağa çıkarak önbelleği günceller. Sonraki istekte güncel sürüm hazırdır. Bu strateji her iki dünyanın avantajını birleştirmeye çalışır: mevcut istek hızlı karşılanır, gelecekteki istek güncel veriyle buluşur.

Stale-while-revalidate'in kısıtı, kullanıcının mevcut istekte her zaman en güncel içeriği göremeyebileceğidir. Bir haber sitesi, fiyat listesi veya anlık değişen veri için bu gecikme kabul edilemez olabilir. Değişim sıklığı düşük içerikler — dokümantasyon sayfaları, statik pazarlama içeriği, portföy siteleri — bu stratejiyle çok daha iyi uyum sağlar. Tarayıcı önbelleklemesiyle birlikte düşünüldüğünde her katmanın hangi içeriği ne kadar süre saklayacağının net olarak tanımlanması, tutarsız deneyimlerin önüne geçer.

Güncelleme döngüsü: yeni Service Worker neden bekler

Service Worker'ın güncelleme mekanizması çoğu geliştirici için beklenmedik davranışlar üretir. Tarayıcı, mevcut Service Worker dosyasını arka planda periyodik olarak kontrol eder. Byte düzeyinde bir değişiklik tespit edilirse yeni Worker indirilir ve kurulum aşamasına geçer. Ancak etkinleştirme hemen gerçekleşmez.

Yeni Worker, eski Worker'ın kontrol ettiği tüm sekmeler kapanana kadar "bekleyen" durumda kalır. Kullanıcı sekmeyi yenilese bile yeni Worker devreye girmez; yenileme mevcut sekmeyi kapatıp açmak değildir. Bu davranış skipWaiting() çağrısıyla atlatılabilir; ancak bu yöntem kendi risklerini taşır. Eski Worker önbelleğiyle çalışan bir sekme varken yeni Worker devreye girerse, aynı oturumda farklı önbellek sürümleri çakışabilir ve beklenmedik uygulama hataları oluşabilir.

Production ortamında bu sorunu yönetmenin en güvenilir yolu, güncelleme tespitinde kullanıcıya bir bildirim göstermek ve sayfayı yenilemeleri için açık bir davet sunmaktır. Sessiz güncelleme beklemek ya da skipWaiting()'i koşulsuz kullanmak, her ikisi de belirli senaryolarda sorun üretir. Güncelleme döngüsünü anlamadan yazılan Service Worker kodu, deployment süreçlerini öngörülemez hale getirir.

Offline destek gerçekte ne kadar iş gerektirir

Service Worker'ın en çekici vaatlerinden biri offline destektir. Kullanıcı internetsiz kaldığında bile uygulamanın çalışmaya devam etmesi, özellikle mobil kullanım senaryolarında anlamlı bir deneyim farkı oluşturabilir. Ancak bu vaadin gerçekleşmesi düşündüğünden çok daha fazla iş gerektirir.

Offline destek, yalnızca statik varlıkları önbelleğe almaktan ibaret değildir. Uygulamanın hangi sayfalarının çevrimdışı çalışması gerektiği, bu sayfalardaki hangi API verilerinin önbelleğe alınacağı, önbelleğin ne zaman geçersizleştirileceği, çevrimdışı durumdayken yapılan form gönderimlerinin nasıl ele alınacağı ve ağ bağlantısı geri geldiğinde bekleyen işlemlerin nasıl senkronize edileceği — bunların her biri ayrı bir uygulama kararı gerektirir. Background Sync ve IndexedDB gibi API'lerin devreye girmesiyle birlikte kapsam hızla genişler.

Gerçek offline destek ihtiyacı olan projeler — PWA olarak dağıtılan mobil uygulamalar, saha çalışanlarına yönelik araçlar, düşük bağlantı kaliteli ortamlarda çalışan sistemler — bu yatırımı haklı kılar. Buna karşılık, kullanıcıların büyük çoğunluğunun kararlı internet bağlantısıyla eriştiği bir içerik sitesi için offline destek altyapısı kurmak, bakım yükünü performans kazanımından çok daha büyük bir boyuta taşır.

Service Worker gereksiz karmaşıklık ürettiği durumlar

Service Worker'ın eklenmesi her proje için doğru karar değildir. CDN'de olduğu gibi, altyapı katmanı ancak belirli koşullar karşılandığında değer üretir. Bu koşullar yoksa Service Worker yalnızca debug edilmesi güç bir önbellek katmanı ekler.

Tekrar eden ziyaretçi oranı düşük olan siteler — tek seferlik trafik ağırlıklı, arama motorundan gelenler — Service Worker'dan ölçülebilir bir hız kazanımı elde edemez. İlk yüklemede hiçbir avantaj yoktur; tekrar eden ziyaret yoksa yatırımın geri dönüşü de olmaz. Hızlıca değişen içerik ağırlıklı projeler —güncel haber, gerçek zamanlı veri— cache-first veya stale-while-revalidate stratejilerinden yeterince yararlanamaz; network-first ise çoğu zaman Service Worker olmadan da sağlanabilecek bir davranışı daha karmaşık bir yapıyla üretir.

Cache-Control başlıkları ve ETag doğrulaması doğru yapılandırıldığında, Service Worker olmadan da statik varlıklar için çok verimli önbellekleme elde edilebilir. Bu altyapı genellikle sunucu yapılandırmasıyla sağlanır, ek JavaScript kodu gerektirmez ve güncelleme davranışı çok daha öngörülebilirdir. Service Worker, bu temel katmanın üstüne uygulama özelinde önbellekleme mantığı gerektiren projelerde anlam kazanır; onun yerine geçmeyi hedeflememelidir.

Service Worker doğru uygulandığında — versiyonlanmış statik varlıklar için cache-first, değişken içerik için stale-while-revalidate, güncelleme döngüsü açıkça yönetilmiş — tekrar eden ziyaretçiler için ölçülebilir bir yükleme hızı iyileşmesi sağlar. Yanlış uygulandığında ise deployment sonrası içerik tutarsızlığı, beklenmedik önbellek çakışmaları ve yorucu debug süreçleri üretir. Kazanım ve sorun aynı mekanizmadan beslenir; fark, stratejinin bilinçli seçilip seçilmediğinde yatar.

Projenizde Service Worker kullanmayı düşünüyorsanız başlangıç noktası şu iki sorudur: Tekrar eden ziyaretçi oranınız anlamlı mı? Önbelleğe alacağınız içeriğin güncelleme sıklığı ve versiyonlama stratejisi net mi? Bu iki soruya yanıt vermeden yazılan Service Worker kodu, performans optimizasyonu değil yönetim yükü üretir.