Bir kullanıcı sitenizi yükleyip ana ekrana kaydettiğinde, tarayıcı artık standart HTTP döngüsüyle çalışmaz. Servis worker (hizmet çalışanı) devreye girer, istekleri yakalar, önbellekten yanıt üretir ve ağ trafiğini filtreler. Geleneksel web mimarisinde her URL talebi sunucuya ulaşır, sunucu yanıt üretir ve tarayıcı gösterir. PWA mimarisinde bu döngü kırılır: aynı URL için farklı kaynaklardan yanıt üretilebilir, önbellekteki sürüm öne geçebilir ya da ağ cevabı beklenirken eski içerik sunulabilir.

Mimari açıdan kritik olan, bu durumun yalnızca teknik bir ayrıntı olmadığıdır. Site hiyerarşisi, navigasyon kararları ve içerik segmentasyonu, servis worker mantığıyla birlikte tasarlanmazsa tutarsız kullanıcı deneyimleri kaçınılmaz olur. Hangi sayfaların önbelleğe alınacağı, uygulama kabuğunun nereye yerleştirileceği ve navigasyonun nasıl işleneceği, geleneksel site yapısı kararlarıyla aynı süreçte ele alınmalıdır.

PWA mimarisi her proje için zorunlu değildir. Ancak uygulamaya karar verildikten sonra site yapısına geriye dönük ekleme yapmak, baştan planlamaktan çok daha maliyetlidir. Servis worker dosyasını bir sonraki adımda ekleriz diye ertelemek, çoğu zaman URL kapsam hatalarına, offline durumda boş sayfalar göstermesine ve arama motoru taranabilirliğinde tahmin edilmeyen kayıplara yol açar.

App Shell Mimarisi ve Sayfa Hiyerarşisi

App shell mimarisi, PWA'nın temel tasarım kalıbıdır. Fikir şudur: sitenin iskelet yapısı, yani navigasyon çubuğu, başlık alanı, sayfa çerçevesi, önbelleğe alınarak hızlı yüklenir; sayfa içeriği ayrı bir istekle, çoğunlukla bir API çağrısıyla gelir. Bu yaklaşım makul görünse de site hiyerarşisini iki ayrı katmana böler ve bu bölünme URL yapısına yansır.

Üst katmanda sabit kabuk bulunur: her sayfada değişmeyen navigasyon elemanları, genel düzen, temel stiller. Alt katmanda ise sayfa içerikleri yer alır. İki katman arasındaki sınır nereye çizilir? Bu soruyu yanıtlamak için hangi içeriklerin ağa bağımlı olduğunu, hangi içeriklerin offline durumda da anlamlı göründüğünü önceden belirlemek gerekir.

Örneğin bir haber sitesinde kategori sayfasının kabuğu önbellekte kalırken son dakika haberleri ağdan çekilebilir. Bu durumda /haber/spor URL'si iki ayrı kaynağın birleşiminden oluşur. Kullanıcı tarafında bu fark görünmez; ancak offline modda ağ isteği başarısız olduğunda kabuk yüklenip içerik alanı boş kalırsa, ziyaretçi yükleme bitti ama sayfa boş gibi bir deneyim yaşar. Bu sorunu çözmek için her içerik bölgesi için bir fallback içerik ya da "yüklenemiyor" mesajı site yapısının parçası olmalıdır.

App shell mimarisini benimseyen bir sitede ana navigasyonun kaç katman derinlik taşıyacağı da yeniden değerlendirilmelidir. Kabuk her sayfada aynıysa, kullanıcıların hangi bölümde olduğunu anlamaları için URL'nin ve sayfa başlığının çok daha belirgin sinyal vermesi gerekir. Derin bir hiyerarşide kabuk navigasyonu tek başına yeterli yön duygusu vermeyebilir.

Servis Worker'ın URL Eşleştirme Mantığı

Servis worker, fetch event dinleyicisi aracılığıyla tüm ağ isteklerini yakalar. Her URL talebi için hangi stratejinin uygulanacağını programcı tanımlar. Mimari açıdan kritik olan nokta şudur: bu eşleştirme mantığı site URL yapısıyla tutarlı olmak zorundadır; aksi takdirde aynı kapsam altındaki iki URL, birbirinden çok farklı önbellekleme davranışı sergileyebilir.

Tipik bir PWA konfigürasyonunda URL grupları ayrı ayrı ele alınır:

/static/*    → Cache First   (önce önbellek, ağ başarısız olursa önbellek)
/api/*       → Network First (önce ağ, başarısız olursa önbellek)
/*.html      → Stale While Revalidate
/offline     → Cache Only

Bu ayrımı site mimarisini planlarken göz ardı etmek, tutarsız davranışlara yol açar. Bir blog yazısını Network First stratejisiyle yönetirken internet bağlantısı kesilirse sayfa boş görünür. Aynı yazıyı Cache First stratejisiyle yönetirseniz, güncellenen içerik bazen kullanıcıya geç ulaşır. Hangi strateji seçileceği, o URL grubundaki içeriğin güncelleme sıklığına ve offline önemine bağlıdır.

URL kapsam çakışmaları da dikkat isteyen bir alandır. /urunler/* kuralı yazıldıktan sonra /urunler/kampanya için farklı bir strateji eklenmek istenirse, eşleştirme sırası belirleyici olur. Servis worker dosyası içindeki kural sırası, bir anlamda site yapısının önceliklendirme belgesidir. Yeni bir URL segmenti eklediğinizde servis worker konfigürasyonu gözden geçirilmeden bırakmak, beklenmedik davranışlara zemin hazırlar.

Önbellek Stratejileri ve İçerik Tazeliği

Önbellek stratejisi seçimi, içeriğin güncellenme sıklığıyla doğrudan ilişkilidir. Statik varlıklar için Cache First açıktır: bir CSS dosyası günde yüzlerce kez değişmez ve versiyonlama ile önbellek geçersizleştirmesi kolayca yönetilir. Ancak haber içerikleri, fiyat bilgileri veya canlı stok durumu gibi sık değişen veriler için strateji hatalı seçilirse kullanıcı eski bilgiyle karar verir.

Stale While Revalidate stratejisi bir denge noktası sunar: önce önbellekteki sürümü göster, arka planda güncel sürümü çek ve bir sonraki ziyaret için hazırla. Çoğu durumda içerik sayfaları için bu strateji işlevsel bir seçimdir. Fiyat sayfaları, randevu formları veya ödeme akışları gibi anlık doğruluk gerektiren noktalarda kullanmak ise yanlış sonuç verir; bu URL'ler için Network First ya da Network Only tercih edilmelidir.

İçerik tazeliği sorununu yönetmenin pratik yolu, site mimarisinde URL segmentlerini güncelleme davranışına göre gruplamaktır. Geleneksel mimari genellikle içerik tipine göre segmentleme yapar: /blog, /urunler, /hakkimizda. PWA önbellekleme ise içeriğin ne sıklıkla değiştiğini ve offline değerini ayrıca sormak ister. Bu iki boyutu örtüştüren bir URL mimarisi, hem servis worker konfigürasyonunu sadeleştirir hem de gelecekte strateji değiştirmeyi kolaylaştırır.

SPA Navigasyonu ve URL Derinliği

PWA'lar çoğunlukla tek sayfa uygulama (SPA) mimarisiyle birleşir. Bu durumda tarayıcı URL'yi değiştirse de gerçek bir HTTP talebi yapılmaz; JavaScript History API'sı sayfa geçişini simüle eder. Servis worker perspektifinden bakıldığında, her "sayfa" aslında aynı HTML dosyasının farklı durumlarının gösteriminden ibarettir.

URL derinliği bu yapıda farklı bir anlam taşır. Geleneksel mimaride /urunler/elektronik/telefon yolu gerçek bir dosya hiyerarşisine karşılık gelir; sunucuda o klasör yapısı mevcuttur. SPA tabanlı bir PWA'da aynı URL, tek bir JavaScript giriş noktası tarafından yönetilen sanal bir hiyerarşidir. Kullanıcı açısından fark yoktur; ancak bağlantı verilirken, doğrudan URL'ye gidildiğinde ya da sayfa yenilendiğinde sunucunun tüm derinliklere aynı HTML'yi dönmesini sağlamak gerekir. Servis worker bu görevi üstlenebilir, ancak önce doğrudan ağ taleplerinin de ele alındığından emin olmak için sunucu tarafında da yapılandırma gerekir.

SPA navigasyonunda bir başka mimari mesele, geri-ileri gezinme davranışıdır. Tarayıcı geçmişi JavaScript tarafından yazıldığı için, servis worker önbellekten yüklenen bir sayfaya geri dönüldüğünde scroll pozisyonu veya sayfa durumu kaybolabilir. Durum yönetimi ile önbellek katmanı arasındaki bu gerilim, URL tasarımı sırasında hesaba katılmadığında kullanıcı deneyiminde görünmez ama sinir bozucu hatalar ortaya çıkar.

SPA zorunlu değildir. Servis worker, çoklu sayfa uygulamalarında (MPA) da çalışır ve her URL için ayrı HTML dosyası sunulur. MPA yapısında önbellekleme daha öngörülebilirdir çünkü her URL bağımsız bir kaynak olarak ele alınır. Offline davranış daha nettir ve SEO açısından herhangi bir JavaScript bağımlılığı sorunu taşımaz. Dinamik uygulama ihtiyacı yoksa MPA, PWA mimarisinin daha basit ve bakımı kolay bir uygulamasıdır.

Manifest Konfigürasyonu ve Uygulama Kapsamı

Web app manifest dosyası, PWA'nın başlangıç URL'sini (start_url) ve kapsamını (scope) tanımlar. Bu iki değer, sitenin hangi bölümlerinin uygulama bağlamında çalışacağını belirler ve site hiyerarşisi kararlarını doğrudan etkiler.

start_url parametresi kullanıcının uygulamayı ilk açtığında hangi sayfaya düşeceğini belirler. Bunu / olarak ayarlamak ana sayfadan başlatır; /dashboard veya /feed gibi değerler ise giriş yapmış kullanıcıları farklı bir başlangıç noktasına yönlendirebilir. scope parametresi ise hangi URL'lerin uygulama bağlamında kalacağını kısıtlar. Kapsam dışına çıkan bağlantılar tarayıcının standart görünümünde açılır ve uygulama çerçevesinin dışına çıkılmış olur.

Kapsamı doğru tanımlamak, site mimarisinin bir parçasıdır. Yalnızca /uygulama altındaki sayfaları kapsama almak ve /blog ya da /destek gibi bölümleri dışarıda bırakmak, ziyaretçilerin iki ayrı bağlamda gezindiği bir deneyim oluşturur. Bu ayrım mantıklı olabilir; ancak kullanıcıların bu geçişi fark edip etmeyeceğini, fark ettiklerinde kafalarının karışıp karışmayacağını gezinme akışlarında test etmek önemlidir. Kapsam sınırını beklenmedik bir yerde çizmek, bazı içeriklerin uygulamadan kopuk hissettirmesine yol açar.

SEO Taranabilirliği ve Mimari Uyum

Servis worker tarayıcıdaki istekleri yönetir; ancak Googlebot başta olmak üzere SEO tarama botları servis worker'ı atlar. Botlar her URL için doğrudan HTTP talebi yapar ve önbellek katmanından geçmez. Servis worker'ın varlığı tarama sürecini doğrudan etkilemez, bu anlamda PWA mimarisi SEO açısından şeffaftır.

Bununla birlikte, SPA mimarisiyle birleşen PWA'lar SEO riski taşır. İçerik JavaScript ile render ediliyorsa botlar bu içeriği her zaman göremez; bazı durumlarda görse de gecikmeli görebilir. Kritik sayfa içeriklerini, başlıklar, meta veriler, iç bağlantılar, sunucu tarafında üretmek ya da statik olarak pre-render etmek bu riski azaltır. Crawl bütçesi açısından değerlendirildiğinde, eksik pre-render sayfalar botlara içerik yerine boş kabuk döndürür ve botlar bu sayfaları indekslemeye çalışırken bütçe boşa harcanır.

Offline fallback sayfası da bir URL olarak ele alınmalıdır. /offline gibi bir fallback sayfası tanımlıyorsanız ve bu sayfa arama motorları tarafından keşfedilirse, içeriksiz bir sayfa indekse girebilir. noindex meta etiketi ile bu riski önlemek, servis worker mimarisini planlarken atlanan ama sonradan görünür hale gelen küçük bir mimari ayrıntıdır. Benzer şekilde, servis worker'ın bazı hata durumlarında ürettiği dinamik HTML yanıtları da beklenmedik URL'lerin botlar tarafından keşfedilmesine neden olabilir; bunları robots.txt veya noindex direktifleriyle yönetmek gerekir.

Bir diğer alan, yönlendirme davranışıdır. Geleneksel mimaride 301 yönlendirmesi sunucu tarafında gerçekleşir ve botlar bunu izler. Servis worker tarafından gerçekleştirilen yönlendirmeler ise botlar tarafından görülmez çünkü botlar servis worker'ı atlar. Dolayısıyla SEO açısından önemli yönlendirmelerin, PWA mimarisi eklendikten sonra da sunucu tarafında varlığını sürdürdüğünden emin olmak gerekir.

PWA mimarisinin site yapısına etkisi, servis worker dosyası yazılmadan önce URL segmentasyonunu, içerik güncelleme sıklığını ve offline senaryoları düşünmeyi gerektirir. Bu planlamayı uygulama geliştirmenin sonuna bırakmak, hem önbellek stratejisi hem de SEO uyumu açısından yeniden yapılanmaya zemin hazırlar.

Küçük içerik siteleri için tam PWA mimarisi çoğu zaman gereksizdir. Servis worker eklemek sayfa önbellekleme ve offline erişim sağlar; ancak app shell ve SPA yapısı her projeye uygun değildir. Statik içerikli bir blog için kritik kaynakları Cache First stratejisiyle önbelleklemek, kapsamlı bir SPA yeniden yapılanmasından çok daha pratik kazanım sağlar ve site mimarisini daha az karmaşık tutar.

Site mimarinizi PWA uyumlu tasarlamak istiyorsanız, önce URL segmentasyonunu belirleyin, ardından her segmentin güncelleme sıklığını ve offline değerini değerlendirin. Bu iki sorunun yanıtları hem önbellek stratejisini hem de uygulama kapsamını şekillendirir. Manifest konfigürasyonu, servis worker kuralları ve site navigasyonu birbirini fark etmeden etkilediği için, bu üç katmanı birlikte tasarlamak sonradan ortaya çıkacak uyumsuzlukları en baştan engeller.