Service Worker ile Parçalı Sayfa Akışı ve Sınırları
Service Worker'ın hız vaadi çoğu yazıda tek cümleye iniyor: sayfayı önbellekten ver, ağı bekleme. Gerçek kazanç bundan dar ve koşullu. Sayfanın kalıbını önbellekten, içeriğini ağdan alıp akış halinde birleştirdiğinde tekrar ziyaretler belirgin biçimde hızlanır; ilk ziyaret ve oturuma göre değişen arayüzler ise faturayı öder.
Önce ne olduğunu netleştirelim
Service Worker, sayfanın ana thread'inden ayrı çalışan, tarayıcıyla ağ arasına giren bir proxy. İsteği yakalar, cevabı önbellekten verir, ağa gider, ikisini birleştirir. Kendi başına bir hızlandırıcı değil, senin yazdığın yönlendirme mantığı.
Bu yüzden "Service Worker kurduk, site hızlandı" cümlesi tek başına bir şey anlatmaz. Hızlanan şey kurduğun fetch stratejisidir, API değil.
Kalıbı önbellekten, içeriği ağdan
İlginç olan kurulum şu: bir sayfanın header ve footer'ı ziyaretten ziyarete neredeyse hiç değişmiyor, değişen kısım ortadaki içerik. O halde her gezinmede tüm HTML'i ağdan çekmenin anlamı yok. Header'ı önbellekten anında ver, içeriği ağdan iste, tarayıcıya tek bir akış olarak ilet. Tarayıcı ilk baytı aldığı anda boyamaya başlar, içeriğin geri kalanı gelmeye devam ederken üst kısım çoktan ekrandadır.
- Kurulumda tekrar eden parçaları önbelleğe al:
/partial-header,/partial-footer. activateiçinde navigation preload desteğini kontrol et, varsa aç. Böylece ağ isteği Service Worker ayağa kalkarken paralel yürür.fetchiçinde içerik parçasını preload yanıtından veya doğrudan ağdan al.- Üç parçayı
ReadableStreamile birleştirip tek yanıt olarak döndür.
Sayfa başlığı ve aktif menü gibi kalıba gömülü olan ama içeriğe göre değişen şeyleri JavaScript ile güncellemen gerekir, çünkü header artık her sayfada aynı.
Yüzdelere nasıl bakmalı
Bu yaklaşım anlatılırken çoğu yerde iddialı iyileşme oranları dolaşıyor. Oranların kaynağı, A List Apart'ta anlatılan tek bir sitenin kendi RUM verisi. O site için doğru olması, senin siten için doğru olacağı anlamına gelmiyor: kazancın büyüklüğü tamamen HTML'inin ne kadarının kalıp olduğuna bağlı. Kalıbın sayfanın yarısıysa kazanç büyük, sayfan zaten ince bir şablon ve kalın bir içerikse ölçeceğin fark gürültünün içinde kalabilir.
Daha önemlisi, bu ölçümler önbelleği dolu ziyaretçilerden geliyor. İlk ziyarette Service Worker'ın kendisi indirilir, kurulur ve o gezinmeye hiçbir katkısı olmaz. Trafiğinin büyük kısmı arama motorundan gelen tek sayfalık ziyaretlerse, optimize ettiğin senaryo kullanıcılarının çoğunun hiç yaşamadığı senaryodur. Rakamlara bakmadan önce analytics'te tekrar ziyaret oranına bakmak daha isabetli bir başlangıç.
Bedel nerede çıkıyor
Header'ı önbelleğe aldığın anda, header'daki her kişisel öğe problem haline gelir. Giriş yapmış kullanıcının adı, sepetteki ürün sayısı, bildirim rozeti: bunların hepsi artık önce yanlış halleriyle boyanıp sonra JavaScript ile düzeltilecek. LCP'de kazandığını düzeltme anındaki kaymayla geri verirsin. Oturum durumuna bağlı bir header'ı bu mimarinin içine sokmam; kişiselleşen kısmı header'dan çıkarıp içerik akışının içine almak, sonradan yama atmaktan temiz çıkıyor.
İkinci maliyet dağıtımda. Kalıp artık kullanıcının cihazında duruyor, yani her deploy'dan sonra o kopyanın geçersiz kılınması gerekiyor. Sürüm etiketi olmayan bir önbellek stratejisiyle, yeni içeriği eski header'la birlikte gösteren ziyaretçiler alırsın ve bu hatayı kendi tarayıcında göremezsin. Sunucu tarafında da içerik parçasının kalıpsız dönebilmesi ve Vary başlıklarının doğru ayarlanmış olması şart.
Navigation preload ve streaming her tarayıcıda aynı düzeyde desteklenmiyor, dolayısıyla klasik yanıt yolunu fallback olarak ayakta tutmak zorundasın. Yani iki yolu birden bakımda tutuyorsun. Çok özel bir ihtiyacın yoksa Workbox bu işin sıkıcı kısımlarını üstlenir.
Kime değer
Bu mimari, sayfa kalıbı ağır ve ziyaretçisi geri dönen siteler için değer: içerik portalları, dokümantasyon, kataloğunda gezinilen e-ticaret. Mobil şebekenin zayıf olduğu yerlerde fark daha da açılır, çünkü kazanılan şey baytlardan çok gidiş dönüş sayısıdır.
Buna karşılık tek sayfalık kampanya siteleri, arayüzü baştan aşağı kişiselleşen paneller ve zaten sunucu tarafında iyi önbelleklenmiş küçük sitelerde kurulum maliyeti kazancı geçiyor. Oralarda LCP'yi düzeltmenin daha ucuz yolları var: görsel boyutları, font yükleme, sunucu yanıt süresi. Service Worker'a en son bakılır, ilk değil.
Kaynaklar