Web sitesini PWA uygulamasına çevirme detaylı

Web sitesini PWA uygulamasına çevirme işlemi nasıl yapılır

Mevcut kodu bozmadan bu iki katmanı eklediğimizde uygulama davranışı ortaya çıkıyor. Biz bu yapıyı kurduğumuzda ana ekrana ekleme, çevrim dışı açılma ve uygun ayarda rozet gösterimi birlikte çalışıyor. Sağlık turizmi panelinde okunmamış mesaj sayısını simgenin üstünde göstermiştik. Rozet eklendikten sonra bildirim tıklanma oranı %32 arttı, ekip bunu özellikle kullandı.

Siteyi baştan yazmak gerekmiyor. Biz çoğu projede iskeleti koruyor, PWA katmanını üstüne ortalama 3-4 iş günü içinde ekliyoruz. Kullanıcı mağaza aramıyor; siteye giriyor, şartlar uygunsa ekleme seçeneğini görüyor.

Bir Siteyi PWA'ya Çevirmek İçin Hangi Şartlar Sağlanmalı?

Tarayıcı bir siteyi PWA olarak tanımadan önce üç şeye bakıyor. Bunlar HTTPS bağlantısı, geçerli bir manifest.json dosyası ve kayıtlı bir service worker'dır. Bunlardan biri eksikse kurulum isteği çıkmıyor.

• HTTPS bağlantısı: Site SSL ile açılmalı; adres satırında https:// görünmeli. Yerelde localhost ayrı tutuluyor.
• Geçerli bir manifest.json dosyası: Uygulamanın adı, simgesi ve açılış davranışı burada tanımlanıyor.
• Kayıtlı bir service worker: Arka planda çalışan ve önbelleği yöneten JavaScript dosyası.

Biz dosyaları kök dizinde tutuyoruz: index.html, manifest.json, sw.js ve ikonların durduğu icons klasörü. Service worker’ı alt klasöre koyunca kapsam daralıyor; ana sayfa dışarıda kalabiliyor. Bu ayrıntıyı bir projede atlamıştık, panel sayfası çalıştı ama giriş sayfası offline açılmadı.

Manifest Dosyası Nasıl Oluşturulur?

Manifest tarafında sitenin adını, açılış şeklini ve ikonlarını tarayıcıya tanıtan JSON dosyasını kök dizine manifest.json adıyla koyarız. İçine şu yedi temel alanı yazarız; bu iş çoğu zaman 15-20 dakikada biter:

• "name": Uygulamanın tam adı, örneğin İdel Yazılım Panel
• "short_name": Ana ekrandaki kısa ad, örneğin İdel Panel
• "start_url": Açılışta gidilecek adres, çoğu işte / kullanıyoruz
• "display": Görünüm biçimi; en sık standalone seçiyoruz
• "background_color": Açılış arka plan rengi
• "theme_color": Üst çubuğun rengi
• "icons": Farklı boyutlardaki ikon listesi

Manifest içinde kalan tek bir virgül bile tarayıcının dosyayı reddetmesine yetiyor. icons alanı da kendi içinde bir liste. Biz burada her ikon için src, sizes ve type bilgilerini tek tek giriyoruz. 192x192 ve 512x512 dosyaları çoğu Android kurulumunda doğrudan iş görüyor.

Display Seçenekleri ve Görünüm Farkları

display değeri, uygulamanın tarayıcı çerçevesinden ne kadar ayrılacağını belirler. Dört seçenek de geçerli; davranışları aynı değil.

Manifest Dosyası HTML Sayfasına Nasıl Bağlanır?

Manifest’i yazmak yetmiyor; index.html içindeki <head> bölümüne bağlamak gerekiyor. Biz burada link rel="manifest" satırını ekliyor, href ile dosya yolunu veriyoruz. Aynı alana theme-color meta etiketini de koyuyoruz; renk kodu manifest ile aynı olmalı. Geçen ay bir kurumsal sitede bu eşleşmeyi düzeltince ana ekran kartı doğru renkte görünmeye başladı.

Bağlantı doğruysa tarayıcı sayfayı açtığında manifest’i okur. Chrome adres çubuğunda yükleme simgesi belirmişse dosya okunmuştur.

İkonlar Nasıl Hazırlanır?

Tek bir görseli her boyutta kullanmak çoğu zaman yetmez. Küçük ekranlarda bulanıklık çıkıyor, bazı yerlerde kenarlar kırpılıyor. Biz bu yüzden birkaç boyutu ayrı ayrı hazırlıyoruz.

192x192 ve 512x512 boyutlarını biz zorunlu gibi ele alıyoruz. Diğerleri eklendiğinde farklı cihazlarda görüntü daha dengeli oluyor. purpose: "maskable" etiketi de işe yarıyor; özellikle Android’de yuvarlak ve kare maskelerde logonun kenarı kesilmiyor. Bir projede logonun etrafına 20 piksel boşluk bırakmıştık, kesilme sorunu tamamen kalktı.

Service Worker Nedir, Neden PWA'nın Arka Planındaki Asıl Güç?

Service worker, tarayıcının arka planda çalıştırdığı ayrı bir JavaScript dosyasıdır. Sayfa kapalıyken kısa süreliğine devrede kalır, ağ isteklerini yakalar, gerekirse önbellekten yanıt döndürür. Offline çalışma, ana ekrana ekleme ve bildirim tarafındaki yük büyük ölçüde onun üzerindedir.

Sayfadaki normal JavaScript akışıyla bunu karıştırmamak lazım. Sayfa kodu DOM üzerinde çalışır; service worker olay dinler. Bizde ilk kez kuran ekipler bu farkı sık karıştırıyor, sonra çevrim dışı testte durum netleşiyor.

Service Worker Dosyası Nasıl Yazılır?

Arka plandaki süreç install, activate ve fetch aşamalarından geçer. Bu üç olayla birlikte genelde beş dosyayı —index.html, style.css, app.js, manifest.json ve ikon dosyasını— önbelleğe alıyoruz. İkinci ziyarette açılış gözle görülür biçimde hızlanıyor.

sw.js içinde genelde üç olayı dinliyoruz: install, activate ve fetch.

• install olayı: Worker ilk kurulduğunda bir kez çalışır. Önce hangi dosyaların önbelleğe alınacağını burada belirleriz.
• activate olayı: Yeni sürüm aktif olurken çalışır. Eski önbellekleri temizlemek için kullanırız.
• fetch olayı: Sayfa her istek yaptığında devreye girer. Yanıtın önbellekten mi, ağdan mı döneceğine burada karar verilir.

install içinde caches.open() ile bir önbellek adı açıyoruz; mesela site-v1. Ardından cache.addAll() ile dosyaları tek tek veriyoruz: index.html, style.css, app.js, manifest.json ve ikonlar. Bir eğitim portalında giriş ekranını bu listeye eklediğimizde, sayfa açılış süresi ilk ziyarette 2,4 saniyeydi; ikinci ziyarette 0,6 saniyeye düştü.

fetch tarafında event.respondWith() ile isteği biz karşılıyoruz. Önce caches.match() ile dosya var mı bakıyoruz; varsa onu döndürüyoruz, yoksa fetch() ile ağdan alıyoruz. Bizde en sık çalışan düzen bu; aynı portalda ölçtüğümüzde isteklerin yüzde 70’i önbellekten karşılanıyor, geri kalan yüzde 30’u ağa düşüyordu.

Cache Stratejisi Nasıl Seçilir?

Her dosyayı aynı sepete koyamayız. Sabit logo ile dakika başı değişen ürün listesi aynı davranışı istemez. Biz projede dosyanın yapısına göre strateji seçiyoruz.

Küçük kurumsal sitelerde çoğu zaman iki kural yetiyor: sabit dosyalarda Cache First, API isteklerinde Network First. Biz isteğin adresine bakarak ayırıyoruz; örneğin /api/ ile başlayan talepleri farklı ele almak işi sadeleştiriyor. Bir müşteri panelinde liste sayfaları böyle ayrılınca eski veri şikâyeti neredeyse kaybolmuştu.

Service Worker Sayfaya Nasıl Kaydedilir?

sw.js hazırlandıktan sonra onu tarayıcıya tanıtıyoruz. Bunun için navigator.serviceWorker desteğini kontrol ediyor, sayfa yüklendiğinde register() çağrısını yapıyoruz. Dosya yolu doğru olmalı; küçük bir yazım hatası kayıt işlemini bozuyor.

Tarayıcı worker kaydını bir kez yaptıktan sonra onu saklıyor. Sayfa her açıldığında yeniden kurmuyor, dosyada değişiklik görürse güncelliyor. Başarılı kayıt bizde genelde konsolda kısa bir mesajla doğrulanır, hata varsa catch içinde görünür.

Sürüm Güncelleme ve Eski Önbelleği Temizleme

Yeni sürüm geldiğinde eski dosyalar bazen sayfada kalıyor. Kullanıcı eski CSS ile açılan bir ekran görüyor; biz bu şikâyeti çok duymuşuzdur. Burada işi önbellek adına sürüm ekleyerek çözüyoruz.

site-v1 yerine site-v2 yazdığımızda activate içinde eski sürümleri ayıklayabiliyoruz. caches.keys() ile tüm isimleri alıyor, güncel olmayanları caches.delete() ile siliyoruz. Bir e-ticaret sitesinde kampanya banner’ı değiştiği halde eski görseli göstermeyi bu şekilde bitirmiştik.

Service worker dosyasının kendisi değişmedikçe tarayıcı yeni önbelleği hemen fark etmeyebiliyor. O yüzden biz her yayında sw.js içinde en az bir sürüm izi güncelliyoruz; çoğu zaman sayı değişimi yeterli oluyor.

Offline Sayfa Nasıl Hazırlanır?

Kullanıcı çevrim dışıyken önbellekte olmayan bir sayfaya giderse boş ekran görmek istemeyiz. Bunun için ayrı bir offline.html sayfası hazırlarız. Kısa bir mesaj, tekrar dene düğmesi, bazen de destek iletişimi eklenir.

Hazırladığımız offline.html dosyasını da önbelleğe dahil ediyoruz. Ağ isteği başarısız olduğunda ve istek sayfa açılışıysa, request.mode değeri navigate ise offline.html döndürüyoruz. Böylece ziyaretçi bembeyaz bir hatayla değil, durumu anlatan net bir ekranla karşılaşıyor.

Tarayıcı Üzerinde PWA Testi Nasıl Yapılır?

Chrome DevTools içinde iki bölüm bu işte işe yarıyor: Application ve Lighthouse.

• Application sekmesi: Manifest’in okunup okunmadığını, ikonların görünüp görünmediğini ve service worker durumunu buradan kontrol ediyoruz.
• Network sekmesindeki Offline kutusu: İnterneti kapatmış gibi davranıp offline sayfanın devreye girip girmediğine bakıyoruz.
• Lighthouse sekmesi: PWA denetimi hangi şartların sağlandığını tek tek gösteriyor; eksik dosya varsa orada açıkça görülüyor.

Canlıya çıkmadan önce bu üç kontrolü yapıyoruz. Bir projede yalnızca ikon boyutunu atlamıştık; kurulum seçeneği görünmedi, sebep o çıktı. Ölçülerden biri eksik kaldığında sistem hata vermeden yükleme butonunu gizliyor.

Ana Ekrana Ekleme Davranışı Nasıl Yönetilir?

Manifest ve service worker koşulları sağlandığında tarayıcı beforeinstallprompt olayını tetikleyebiliyor. Biz bu davranışı yakalıyor, preventDefault() ile varsayılan akışı durduruyor ve olayı saklıyoruz. Sonra kendi butonumuzu gösteriyoruz. Sağlık turizmi tarafında bunu randevu kartının altına koyduğumuzda kullanıcı yükleme seçeneğini daha rahat fark etmişti.

Kullanıcı butona bastığında saklanan olay üzerinden prompt() çalışıyor. Tarayıcının onay penceresi açılıyor; userChoice ile de seçimi okuyabiliyoruz. Böylece yükleme çağrısını kendi tasarımımıza bağlıyoruz, tarayıcının kendi başına bıraktığı bir uyarı gibi değil.

iOS'ta Durum Neden Farklı

Safari, PWA tarafında Chrome kadar rahat davranmıyor. iPhone kullananlar için bazı ayarlar ayrıca gerekiyor.

iOS ağırlıklı bir kitlede biz apple-touch-icon ve apple-mobile-web-app-capable etiketlerini ekliyoruz. Kullanıcıya Safari paylaş menüsünü gösteren kısa bir yönlendirme kutusu ekliyoruz; çünkü otomatik yükleme penceresi gelmiyor. Bu tarafta akış farklı, bazen daha sabırlı olmak gerekiyor.

Push Bildirim Altyapısı Nasıl Kurulur?

Web sitesini PWA uygulamasına çevirme işleminden sonra PWA’nın isteğe bağlı parçalarından biri push bildirimdir. Önce izin isteriz: Notification.requestPermission() ile tarayıcı izin penceresi açılır. İzin verildiğinde service worker üzerinden abonelik oluşturulur, sonra bu bilgi sunucuya yazılır.

Bildirim gönderebilmek için sunucu tarafı da gerekir. Biz çoğu kurumsal işte önce offline tarafı ve ana ekrana eklemeyi tamamlıyor, bildirimi ikinci aşamada ele alıyoruz. İlk aşamada her projeye yüklemek doğru sonuç vermiyor; bazı işlerde kullanıcıyı erken izin penceresiyle sıkıştırmak ters tepiyor.

Yayına Almadan Önce Hangi Noktalar Kontrol Edilmeli?

• Site tamamen HTTPS ile açılıyor mu, karma içerik uyarısı var mı
• manifest.json doğru şekilde bağlanmış mı
• 192x192 ve 512x512 ikonlar gerçekten mevcut mu
• sw.js kök dizinde mi, register() doğru yolu mu gösteriyor
• Önbelleğe alınan dosya listesi güncel mi
• Sürüm numarası her yayında değişiyor mu
• Offline sayfa çalışıyor mu, Network sekmesinde test edildi mi
• Lighthouse PWA denetiminde eksik kalmış bir madde var mı

PWA Kurulumunda Sık Yapılan Hatalar Nelerdir?

Service worker dosyasını /js/sw.js gibi alt klasöre attığımızda işler karışıyor. Böyle olunca worker ana sayfayı değil, yalnızca kendi klasörünü kontrol ediyor. Biz dosyayı kökte tutarak bu karışıklığı baştan kapatıyoruz.

Önbellek adını değiştirmeden dosyayı güncellemek de sorun çıkarıyor. Kullanıcı yeni CSS beklerken eski sürümle karşılaşıyor. Bir yayında renklerin değişip diğer yayında değişmemesi çoğu zaman buradan geliyor.

manifest.json içinde fazladan virgül ya da kapanmamış tırnak varsa tarayıcı dosyayı sessizce reddedebiliyor. Ana ekrana ekleme seçeneği hiç görünmeyebiliyor. Biz bu yüzden manifest’i yazdıktan sonra Application sekmesinde mutlaka kontrol ediyoruz.

start_url alanında kök dizin kullanıyorsak / yazmak daha güvenli. Bazı sunucularda eksik eğik çizgi yönlendirmeyi bozuyor; küçük bir detay ama etkisi büyük.

Tarayıcı ve İşletim Sistemi Desteğini Karşılaştırma

PWA desteği tarayıcıdan tarayıcıya aynı değil. Chrome ve Edge, Blink motoru sayesinde service worker, push bildirim ve yükleme akışını güçlü biçimde destekliyor. Firefox service worker tarafında iyi, ama masaüstünde ana ekrana ekleme davranışı daha sınırlı. Safari ise özellikle iOS tarafında daha temkinli davranıyor.

Hedef kitle çoğunlukla iPhone kullanıyorsa push bildirim birinci öncelik olmuyor. Biz böyle projelerde hızı ve offline erişimi öne alıyoruz; bildirim sonra geliyor.

App Shell Mimarisiyle Sayfa Açılış Hızını Düşürme

App shell, sitenin her sayfada tekrar eden iskelet bölümüdür: üst menü, alt bilgi, yan alanlar gibi parçalar. Bu iskeleti önbelleğe alıp değişen içeriği ağdan çektiğimizde açılış daha hızlı oluyor.

Bir e-ticaret işinde header, footer ve kategori menüsünü ayrı tuttuk. Lighthouse raporunda İlk İçerik Boyaması 2,3 saniyeydi; app shell düzenine geçince tekrar ziyarette 0,7 saniyeye indi. Çünkü tasarım iskeleti diskten hızlı geldi, ürün listesi ayrı yüklendi.

Burada ölçüyü kaçırmamak gerekiyor. Biz her CSS ve JS dosyasını iskelete sokmuyoruz; önbellek şişerse ilk kurulum yavaşlıyor. Sadece iskelet dosyaları ayrılıyor.

Güncelleme Bildirimini Kullanıcıya Gösterme

Yeni bir service worker yayınladığımızda tarayıcı dosyayı indirir ama hemen devreye almaz. Sekme açık kaldığı sürece eski sürüm yaşamaya devam eder. Kullanıcıyı bekletmek istemiyorsak bu akışı biz yönetiyoruz.

registration.waiting varsa küçük bir uyarı çubuğu gösteriyoruz: yeni sürüm hazır. Kullanıcı tıklayınca skipWaiting() çağrılıyor, ardından controllerchange ile sayfa yenileniyor.

navigator.serviceWorker.register('/sw.js').then(reg => {
  reg.addEventListener('updatefound', () => {
    const yeniWorker = reg.installing;
    yeniWorker.addEventListener('statechange', () => {
      if (yeniWorker.state === 'installed' && navigator.serviceWorker.controller) {
        // güncelleme çubuğunu göster
      }
    });
  });
});

Güncelleme bildirimi eklenmeyen projelerde kullanıcı eski arayüzde kalabiliyor. Sekme kapanmadıkça tarayıcı geri duruyor; küçük bildirim çubuğu bu beklemeyi kırıyor.

Arka Planda Senkronizasyon ile Bağlantı Kesintileri Nasıl Yönetilir?

Background Sync API, bağlantı yokken gönderilen formu daha sonra tekrar iletmeyi sağlar. İletişim formu, sipariş ve yorum alanlarında kullanışlıdır.

Akış basit: gönderim başarısızsa veriyi IndexedDB'ye yazıyoruz, ardından sync.register('form-gonder') ile görev oluşturuyoruz. Bağlantı geldiğinde service worker sync olayını alıyor ve bekleyen veriyi sunucuya iletiyor.

Tarayıcı desteği eşit değil. Chrome ve Edge bu işi destekliyor, Safari ve Firefox desteklemiyor. O yüzden biz bunu ana akışa değil, yedek yol olarak kuruyoruz. Desteklenmeyen tarafta kullanıcıya açık bir uyarı gösteriyoruz.

Push Bildirimleri Nasıl Devreye Alınır?

Bildirim için önce sunucuda bir VAPID anahtar çifti üretiriz. Genel anahtar tarayıcıya gider, özel anahtar sunucuda kalır. Çoğu Node.js kurulumunda web-push bunu hızlıca çözüyor.

Kullanıcı izin verince pushManager.subscribe() bir abonelik nesnesi döndürür; bunu veritabanına kaydediyoruz. Bildirim gönderirken bu abonelikle sunucudan mesaj yolluyoruz, service worker da push olayında showNotification() ile bildirimi gösteriyor.

Sağlık turizmi tarafında randevu hatırlatmasını bu yolla kurduğumuz bir projede açılma oranı e-postaya göre yaklaşık üç kat yüksekti. Sebep basit: bildirim kilit ekranında görünüyor, e-posta ise çoğu zaman sekmeler arasında kayboluyor.

iOS tarafında bu akış yalnızca uygulama ana ekrana eklendikten sonra çalışıyor. Tarayıcı sekmesinde açıkken push isteği beklediğimiz gibi davranmıyor; kullanıcıya bunu baştan söylemek gerekiyor.

Depolama Sınırlarını ve IndexedDB Kullanımını Anlama

Cache Storage sınırsız değil. Tarayıcılar diskin bir bölümünü PWA’ya ayırıyor; doluluk durumunda eski veriler silinebiliyor. Biz bu yüzden büyük dosya yükünü dikkatli taşıyoruz.

Metin ve görsel önbelleklemede Cache Storage yeterli oluyor. Sepet, taslak form ya da kullanıcı tercihi gibi yapılandırılmış veriler için ise IndexedDB kullanıyoruz. Bu, tarayıcı içinde çalışan nesne tabanlı bir veritabanı.

Bir eğitim platformunda yarım bırakılan sınav cevaplarını burada tuttuğumuzda, öğrenci bağlantı kopsa da işaretlemeye devam edebildi. Bağlantı geri geldiğinde veriler senkronize oldu; kısa kesintiler veri kaybına dönüşmedi.

HTTPS Zorunluluğu Nedir, Karma İçerik Sorunları Nasıl Çözülür?

Service worker yalnızca HTTPS altında çalışır; localhost geliştirme ortamı ayrı tutulur. Sertifika süresi dolmuşsa ya da yanlış kurulmuşsa kayıt işlemi başarısız olur.

Karma içerik, HTTPS sayfa içinde HTTP kaynak kullanılmasıdır. Görsel, script ya da font tarafında bu olursa tarayıcı kaynağı engeller. Eski temadan kalmış bir http:// CDN bağlantısı bizde en sık gördüğümüz hata tiplerinden biri. Dış kaynakları https:// ya da protokolden bağımsız biçime çevirmek gerekiyor.

Ücretsiz sertifikalarda otomatik yenileme kurulmamışsa işler aksıyor. Let’s Encrypt kullanılıyorsa certbot ile yenilemeyi otomatikleştirmek güvenli yol; bir gün gecikme bile PWA özelliklerini kapatabiliyor.

WordPress ve Hazır Altyapılarda PWA Uygulaması Nasıl Yapılır?

WordPress’te iki yol var: eklenti kullanmak ya da manifest ve service worker dosyalarını temaya elle eklemek. Eklenti hızlı kurulur ama önbellek stratejisini ayrıntılı yönetmek zorlaşır; WooCommerce gibi dinamik yapılarda bu bazen eski fiyat gösterir.

Biz çoğu WordPress işinde manifest.json dosyasını tema köküne koyuyor, sw.js dosyasını da doğrudan kökten kaydediyoruz. Böylece eklenti güncellemesi geldiğinde PWA ayarı bozulmuyor. Sepet ve ödeme sayfalarını ağ öncelikli, ürün görsellerini ve sabit sayfaları önbellek öncelikli bırakıyoruz.

Yayın Sonrası Bakım ve Sürüm Takibi

PWA kurulduktan sonra takip bırakılmaz. Yeni CSS, değişen görsel, güncellenen API adresi; bunların hepsi önbellek ve sürüm numarasıyla birlikte ele alınır. Biz bu takibi küçük bir değişiklik tablosuyla tutuyoruz.

Biz üç ayda bir Lighthouse taraması yapıyoruz. Tarayıcı güncellemeleri ve sunucu tarafındaki küçük değişiklikler puanı aşağı çekebiliyor; bunu canlıda değil, kontrol sırasında yakalamak daha rahat. Bir projede tema dosyası güncellendiği halde önbellek adı değişmemişti, üç hafta sonra fark edildi. O yüzden düzenli kontrolü aksatmıyoruz.