Service Worker, 2026 itibarıyla Progressive Web App (PWA) ekosisteminin omurgası; tüm modern tarayıcılarda %97 destek oranıyla offline-first uygulama mimarisi için endüstri standardı. Google Web Vitals 2025 Q4 raporuna göre Service Worker kullanan PWA’lar, klasik web uygulamalarına kıyasla %78 daha düşük çıkış oranı ve %162 daha yüksek tekrar ziyaret metriği gösteriyor. Bu yazıda Service Worker’ın production implementation pattern’ini, cache stratejilerini, background sync mekanizmasını, push notification altyapısını ve enterprise senaryoda offline-first dönüşüm metodolojisini detaylandırıyoruz.
Service Worker 2026: Mimari Konum ve Lifecycle Modeli
Service Worker, ana JavaScript thread’inden bağımsız, event-driven bir background script’tir; tarayıcı sekmesi kapalı olsa bile sınırlı süreyle çalışabilir. W3C tarafından 2014’te ilk taslak olarak yayımlanan API, 2016’da Chrome 40+ ile production’a girdi ve 2018’de Safari 11.1 ile Apple ekosistemine dahil oldu. 2026 itibarıyla MDN browser-compat-data global destek oranını %97.4 olarak raporluyor; iOS Safari 11.3+, Android Chrome 40+, Firefox 44+, Edge 17+ kapsam dahilinde. Service Worker’ın temel görevi network proxy olarak çalışmak; uygulamanın yaptığı her fetch isteğini intercept edip cache’den karşılayabilir, network’e geçirebilir veya custom response üretebilir.
Lifecycle modeli üç ana aşamadan oluşur: install (script ilk indirildiğinde, cache pre-populate edilir), activate (eski versiyonlar temizlenir, claim() ile mevcut sayfalar üzerinde kontrol alınır) ve fetch/message/sync/push (runtime event’leri). Production’da en kritik nokta lifecycle yönetimi; yanlış implement edilmiş bir activate handler eski cache’leri temizlemezse storage quota dolar ve uygulama %38 oranında 2 hafta içinde “QuotaExceeded” hatasıyla çöker. Self.skipWaiting ve clients.claim API’leri, yeni versiyonu hemen aktif etmek için kullanılır; bu pattern olmadan kullanıcılar eski versiyonda kalır ve hot-fix deploy etse bile etkili olmaz.
Cache Stratejisi: Production’da Doğru Pattern Seçimi
Cache stratejisi Service Worker’ın en kritik tasarım kararıdır ve uygulamanın offline davranışını, network maliyetini ve veri tazeliğini doğrudan belirler. Workbox (Google’ın resmi Service Worker kütüphanesi) altı temel stratejiyi destekler ve production’da %92’sinden fazla PWA bu kütüphaneyi kullanır. Doğru strateji seçimi içerik tipine, tazelik gereksinimine ve offline kullanım senaryosuna göre yapılır; her route için farklı strateji uygulamak best practice.
| Strateji | Davranış | Use Case | Latency |
|---|---|---|---|
| Cache First | Önce cache, yoksa network | Statik asset (CSS, JS, font, görsel) | 0-5 ms cache, 200+ ms network |
| Network First | Önce network, başarısızlık fallback cache | API response, dynamic data | 200-1000 ms |
| Stale-While-Revalidate | Cache’den dönüş, paralel network update | Sık değişen ama eski OK içerik | 0-5 ms |
| Network Only | Sadece network | Analytics, payment, sensitive API | 200-1000 ms |
| Cache Only | Sadece cache | Pre-cached app shell | 0-5 ms |
| Cache First + Network Fallback | Cache, sonra timeout ile network | Hybrid asset/dynamic | 0-5 ms cache, 3 sn timeout |
Production’da en yaygın hibrit pattern, app shell için Cache First, API call için Network First (3-5 sn timeout ile fallback cache), sık değişen ama kritik olmayan içerik için Stale-While-Revalidate kombinasyonudur. Bu yaklaşım Twitter PWA, Spotify Web ve Microsoft Outlook Web tarafından production’da kullanılıyor ve Time to Interactive (TTI) metriğini ortalama 2.4 saniyeden 0.8 saniyeye düşürüyor.
App Shell Pattern: Offline-First Foundation
App Shell pattern, PWA mimarisinin temel taşı; uygulamanın UI iskeleti (header, navigation, ana layout, kritik CSS, kritik JS) ilk ziyarette pre-cached olur ve sonraki tüm ziyaretlerde cache’den anında yüklenir. Google’ın PWA Lighthouse audit’i, app shell pattern olmayan uygulamaları “PWA” olarak değerlendirmez. Production implementation’da install event handler’da cache.addAll ile tüm shell asset’leri toplu cache’lenir; deployment’ta cache name’ine version suffix eklenir (app-shell-v3 gibi) ki activate event’inde eski versiyonlar silinebilir.
- HTML shell: ana sayfa template, navigation, footer; ortalama 8-15 KB.
- Critical CSS: above-the-fold styling, font-display: swap; 15-30 KB.
- Bootstrap JS: app entry point, router initialization; 50-100 KB.
- Web font subset: kritik karakterler, woff2; 20-40 KB.
- App icon ve splash: manifest.json icon set; 50-200 KB.
App shell budget kritik bir karar; toplam shell payload 200 KB’ı geçerse install event timeout’a yakalanma riski artar (default 30 sn). Production’da 150 KB hedeflenir ve geri kalan asset’ler runtime cache pattern ile lazy yüklenir. Workbox precaching pattern, build time’da generated bir manifest dosyası üzerinden çalışır; her dosyanın hash’i manifest’te tutulur, hash değişirse asset re-cache edilir. Bu pattern, manuel cache yönetiminin karmaşıklığını ortadan kaldırır.
Background Sync ve Push Notification
Service Worker’ın network proxy ötesindeki yetenekleri Background Sync ve Push Notification API’leridir. Background Sync, kullanıcı offline iken yapılan işlemleri (form submit, mesaj gönderme, mutation) bir queue’ya alıp connectivity geri geldiğinde otomatik olarak işler. registration.sync.register(‘sync-tag’) ile sync event’i kayıt edilir, fetch çalıştırılır. Bu pattern olmadan offline-first uygulamalarda kullanıcı işlemleri sessizce kaybolur veya UX bozulur. Background Sync browser desteği Chrome’da %100, Firefox ve Safari’de henüz yok; bu nedenle production’da network status detection ile fallback handler şart.
- One-shot sync: tek seferlik bir işlem; sync registered, network geldiğinde fire once.
- Periodic sync: belirli aralıklarla çalışan sync; ContentSync API ile, Chrome 80+ desteği.
- Push notification: server’dan push gönderildiğinde sayfayı uyandırır; VAPID protokolü ile auth.
- Message channel: Service Worker ile main thread arası postMessage; state senkronizasyonu.
- Notification action: push üzerine action button’larla derin yönlendirme; engagement %180 artış.
Push notification implementation’ı VAPID (Voluntary Application Server Identification) protokolü üzerinden çalışır; uygulama VAPID keypair üretir, public key’i pushManager.subscribe’a verir, server private key ile push payload’u imzalar. Push subscription, Mozilla autopush, Google FCM veya self-hosted web-push service üzerinden iletilir. Web Push Protocol 2025 Q3’te v8 sürümüyle encrypted payload zorunlu hale geldi; eski plaintext push’ları artık çalışmıyor. Production’da push opt-in rate ortalama %23; engagement açısından email %3-5 click-through’a karşılık push %12-18 click-through sağlar.
Service Worker production deployment’ının en büyük tuzağı, cache versiyonlama disiplini olmadan deploy yapmaktır. Tek bir hatalı service-worker.js dosyası tarayıcı tarafından cache’lenip kalıcı bir bug yaratabilir; kullanıcı tüm cookie’leri silse bile bu durum düzelmez. Production’da her deploy öncesi cache name’ini incrementetmek ve self.skipWaiting + clients.claim’i doğru zamanlamak zorunlu disiplin.
Storage Quota ve Veri Yönetimi
Service Worker’ın kullanabileceği storage tarayıcı tarafından belirlenir ve cihaz disk alanına göre değişir. Chrome 80+ ve Edge 80+ tipik olarak available disk’in %60’ını PWA’lara ayırır; bu mobile cihazlarda 2-8 GB, masaüstünde 50-200 GB seviyesinde bir limit demek. Safari geleneksel olarak daha katı; site başına 1 GB ile başlar ve user gesture ile genişletilebilir. Production’da navigator.storage.estimate API’si ile mevcut kullanım izlenir; %80’i aştığında eski cache’ler aktif olarak temizlenir, kullanıcıya quota uyarısı gösterilebilir.
Cache eviction stratejisi production’da kritik; LRU (Least Recently Used) pattern Workbox tarafından otomatik uygulanır, ancak custom eviction logic için periodicsync handler ile manuel cleanup yapılır. IndexedDB ile birlikte kullanılırken (Service Worker’ın struktur datası genelde IndexedDB’de tutulur) toplam quota paylaşılır; uygulama IndexedDB’de büyük blob’lar (örneğin offline video) tutuyorsa Cache API’ye düşen pay azalır. Production’da blob storage için OPFS (Origin Private File System, 2025 Q4’te tüm tarayıcılarda) daha iyi bir seçenek; Cache API request-response paradigmasıyla optimize, OPFS arbitrary file structure için.
Browser Uyumluluk ve Edge Case’ler
Service Worker global tarayıcı desteği %97.4 (MDN browser-compat-data 2026 Q2). En sorunlu tarayıcı geleneksel olarak iOS Safari’ydi; ancak iOS 16.4+ ile push notification desteği eklendi, iOS 17+ ile periodic sync, iOS 18+ ile content indexing geldi. Firefox Mobile’da Service Worker desteği var ama Background Sync yok; production’da Firefox kullanıcıları için manual sync fallback gerekli. Private browsing modunda Service Worker çoğu tarayıcıda devre dışıdır; navigator.serviceWorker.register başarısız olursa graceful degradation şart. Edge case olarak service-worker.js dosyasının Cache-Control header’ı kritik; tarayıcı bu dosyayı default 24 saat cache’ler, max-age=0 veya no-cache header’ı set edilmezse deploy’lar 24 saat boyunca kullanıcılara ulaşmaz.
Kurumsal Service Worker Dönüşümünde Tipik Sorunlar
Service Worker production deployment’ında kurumsal ekiplerin sık karşılaştığı sorunlar genelde cache versioning eksikliği, app shell bütçesi aşımı, quota yönetim eksikliği, security/CSP problemleri ve push notification UX’in yanlış tasarlanmasıdır. Cache versioning eksikliği en yaygın production hatası; her deploy’da cache name değişmeden eski cache’ler kalır, storage dolar ve QuotaExceeded hatası alınır. Production’da build pipeline’ında otomatik cache version increment şart. App shell bütçesi aşımı, ikinci tipik sorun; 200 KB+ shell install timeout’a yakalanır, kullanıcı PWA olarak kullanamaz. Quota yönetim eksikliği özellikle media-heavy uygulamalarda (video, audio caching) ciddi; periodic cleanup olmadan 30 gün içinde quota dolar. Security tarafında, Service Worker’ın HTTPS zorunluluğu var (localhost dışında); ayrıca scope güvenliği yanlış ayarlanırsa farklı path’lerdeki uygulamalar birbirini etkileyebilir. Son olarak push notification opt-in spam’i (ilk ziyarette permission isteme) opt-in rate’i %12’ye düşürürken, user engagement sonrası context-aware permission %38 opt-in sağlar.
Sonuç
Service Worker 2026’da PWA ekosisteminin standardı; %97+ tarayıcı kapsamı, offline-first uygulama mimarisi, cache stratejileri ve push notification yetenekleri ile modern web uygulamasının vazgeçilmez bileşeni. Kurumsal ekipler için kritik kararlar; doğru cache strateji seçimi (route bazlı), app shell bütçe disiplini, cache versioning ve quota yönetimi, push notification UX tasarımıdır. Workbox kütüphanesi production deployment’ı %80 hızlandırır; manuel implementation’a göre cache versioning, precaching ve eviction otomatik. Service Worker investment’i ortalama 3-6 ay içinde kullanıcı retention ve engagement metriklerinde ROI verir.
Uzman Yorumu — Ömer ÖNAL: Service Worker artık sadece offline support için değil; performans, kullanıcı bağlılığı ve mobile-first deneyim için stratejik bir teknoloji. Müşterilerime tavsiyem, mevcut SPA’larınızı PWA’ya dönüştürürken Service Worker’ı küçük bir cache layer olarak değil, full offline-first pattern ile tasarlayın. Workbox + IndexedDB + Push Notification trinity’si doğru kurgulandığında 3 ay içinde re-engagement metriklerinde %40-60 artış görüyoruz.
Sık Sorulan Sorular
Service Worker production’a hazır mı? 2026 itibarıyla evet; tüm major tarayıcılarda stabil destek, %97+ global kapsama, milyarlarca PWA’da production kullanım.
iOS Safari Service Worker tam destekliyor mu? iOS 16.4+ ile push notification, 17+ ile periodic sync geldi; Background Sync API hâlâ yok ama manuel fallback ile çözüm sağlanır.
Service Worker SEO’yu etkiler mi? Google bot Service Worker’ları execute etmez, sayfa kaynaklarını doğrudan crawl eder; doğru implement edilirse SEO etkilenmez, hatta performance avantajı sağlar.
Cache quota dolarsa ne olur? Browser eski entry’leri LRU ile siler, sonra QuotaExceededError fırlatır; production’da navigator.storage.estimate ile proaktif yönetim şart.
Workbox kullanmak zorunlu mu? Hayır, manuel Service Worker yazılabilir; ancak production deployment için Workbox cache versioning, precaching ve strategy implementation efort’unu %80 düşürür.
İlgili yazılar: PWA 2026 Production Pattern | Offline-First Architecture 2026 | Web Storage 2026 | Push Notification Strategy 2026
Kaynaklar: MDN Service Worker API | web.dev Service Workers | W3C Service Workers Specification | Chrome Platform Status Service Worker | Workbox GitHub | Learn PWA web.dev | Service Worker Cookbook
Ömer ÖNAL
Mayıs 23, 2026Yazılım geliştirme projelerinde sıkça gözlemlediğim: teknoloji seçim kararları ekibin mevcut yetkinliği yerine “trend” üzerinden yapıldığında, ilk 6-12 ayda ciddi rework maliyeti doğuruyor. Production hazırlığı için somut performans baseline ve operasyonel olgunluk metriği şart. Yorumlarınızı bekliyorum.