Gönderilen içeriğin hikayesi, etkinin nasıl ölçüldüğü ve yapılan ödünleşim.
Arka plan
Google'da hemen hemen her konuda arama yaptığınızda, anlamlı ve alakalı sonuçların yer aldığı anında fark edebileceğiniz bir sayfayla karşılaşırsınız. Muhtemelen fark etmemiş olduğunuz şey bu arama sonuçları sayfasının, belirli senaryolarda hizmet çalışanı adı verilen güçlü bir web teknolojisi tarafından sunulduğudur.
Google Arama için hizmet çalışanı desteğinin performansı olumsuz yönde etkilemeden kullanıma sunulması, birden çok ekipte çalışan düzinelerce mühendisi gerektiriyordu. Bu, neyin gönderildiği, performansın nasıl ölçüldüğü ve hangi dengelerin yapıldığının hikayesidir.
Service Worker'ları keşfetmenin temel nedenleri
Service Worker'ı bir web uygulamasına sitenizde yaptığınız herhangi bir mimari değişikliği yaparken olduğu gibi, net hedefler göz önünde bulundurarak eklemelisiniz. Google Arama ekibi açısından, bir hizmet çalışanı eklemenin keşfedilmeye değer birkaç temel nedeni vardı.
Sınırlı arama sonucunu önbelleğe alma
Google Arama ekibi, kullanıcıların kısa süre içinde aynı terimleri bir defadan fazla aramasının yaygın olduğunu tespit etti. Arama ekibi, aynı sonuçları sağlayabilecek yeni bir arka uç isteğini tetiklemek yerine, önbelleğe alma özelliğinden yararlanmak ve bu tekrarlanan istekleri yerel olarak gerçekleştirmek istedi.
Güncelliğin önemi de göz ardı edilemez. Bazen kullanıcılar, sürekli gelişen bir konu olduğu için aynı terimleri tekrar tekrar ararlar ve yeni sonuçlar almayı beklerler. Service Worker kullanmak, Arama ekibinin ayrıntılı bir mantık uygulayarak yerel olarak önbelleğe alınan arama sonuçlarının ömrünü kontrol etmesini ve kullanıcılara en iyi şekilde hizmet verdiğini düşündükleri hız-yenilik arasındaki tam dengeyi yakalamasını sağlar.
Anlamlı çevrimdışı deneyim
Ayrıca Google Arama ekibi anlamlı bir çevrimdışı deneyim sunmak istiyordu. Kullanıcılar bir konuyla ilgili bilgi edinmek istediğinde, etkin bir internet bağlantısı konusunda endişelenmeden doğrudan Google Arama sayfasına gitmek ve aramaya başlamak isterler.
Service Worker olmadan, çevrimdışıyken Google arama sayfasını ziyaret etmek yalnızca tarayıcının standart ağ hatası sayfasına yönlendirilir ve kullanıcıların bağlantı tekrar kurulduğunda geri dönüp tekrar denemesi gerektiğini unutmamak gerekir. Service Worker sayesinde özel bir çevrimdışı HTML yanıtı sunabilir ve kullanıcıların arama sorgularını hemen girmelerine izin verebilirsiniz.
İnternet bağlantısı kurulana kadar sonuçlar kullanılamaz ancak hizmet çalışanı aramanın ertelenmesine ve cihaz background Sync API'yi kullanarak tekrar çevrimiçi olduğu anda Google'ın sunucularına gönderilmesine izin verir.
Daha akıllı JavaScript önbelleğe alma ve sunma
Diğer bir amaç ise, arama sonuçları sayfasındaki çeşitli özellik türlerini destekleyen modüler hale getirilmiş JavaScript kodunun önbelleğe alınmasını ve yüklenmesini optimize etmekti. JavaScript paketlerinin sunduğu birçok avantaj, hizmet çalışanı katılımı olmadığında mantıklıdır. Bu nedenle, Arama ekibi yalnızca gruplamayı tamamen bırakmak istemedi.
Arama ekibi, bir Service Worker'ın çalışma zamanında ayrıntılı JavaScript parçalarını sürüm ve önbelleğe alma özelliğini kullanarak, önbellek karmaşasını azaltabileceklerini ve gelecekte yeniden kullanılacak JavaScript'in verimli bir şekilde önbelleğe alınabileceğinden şüpheleniyordu. Service Worker'ın içindeki mantık, birden fazla JavaScript modülü içeren bir paket için giden HTTP isteğini analiz edebilir ve yerel olarak önbelleğe alınmış birden fazla modülü birleştirerek bunu mümkün olduğunda etkili bir şekilde "ayrıştırabilir". Bu, kullanıcı bant genişliğini azaltır ve genel yanıt verme hızını artırır.
Bir hizmet çalışanı tarafından sunulan önbelleğe alınmış JavaScript kullanmanın performans açısından avantajları da vardır: Chrome'da, bu JavaScript'in ayrıştırılmış, bayt kod gösterimi saklanıp yeniden kullanılır. Böylece, sayfada JavaScript'i yürütmek için çalışma zamanında yapılması gereken işlerin azalması sağlanır.
Zorluklar ve çözümler
Aşağıda, ekibin belirttiği hedeflere ulaşmak için aşılması gereken engellerden birkaçı verilmiştir. Bu zorluklardan bazıları Google Arama'ya özel olsa da çoğu, hizmet çalışanı dağıtımı olarak düşünülebilecek çeşitli siteler için geçerlidir.
Sorun: hizmet çalışanı ek yükü
Google Arama'da bir Service Worker'ın başlatılmasının önündeki en büyük zorluk ve gerçek engel, kullanıcı tarafından algılanan gecikmeyi artıracak herhangi bir işlem yapılmadığından emin olmaktı. Google Arama, performansa çok önem verir ve geçmişte, belirli bir kullanıcı nüfusu için on milisaniye ek gecikmeye yol açmış olsa da yeni işlevlerin kullanıma sunulmasını engelliyordu.
Ekip, ilk denemeleri sırasında performans verileri toplamaya başladığında bir sorun olduğu anlaşıldı. Arama sonucu sayfası için gezinme isteklerine yanıt olarak döndürülen HTML dinamiktir ve Arama'nın web sunucularında çalışması gereken mantığa bağlı olarak büyük ölçüde değişiklik gösterir. Şu anda hizmet çalışanının bu mantığı çoğaltarak önbelleğe alınmış HTML'yi hemen döndürmesi mümkün değildir. Yapabileceği en iyi şey gezinme isteklerini arka uç web sunucularına iletmektir ve bu da bir ağ isteğini gerektirir.
Service Worker olmadan bu ağ isteği, kullanıcı gezinmesinin hemen ardından gerçekleşir. Bir hizmet çalışanı kaydedildiğinde her zaman başlatılması ve bu getirme işleyicilerinin ağa gitmekten başka bir şey yapma olasılığı olmadığında bile fetch etkinlik işleyicilerini yürütme fırsatı verilmesi gerekir. Hizmet çalışanı kodunu başlatmak ve çalıştırmak için gereken süre, her gezinmeye eklenen tamamen ek yüktür:
Bu da Service Worker'ın uygulanmasında diğer avantajları haklı çıkarmak için çok fazla gecikme dezavantajı oluşturur. Ayrıca ekip, gerçek dünyadaki cihazlarda hizmet çalışanı başlatma sürelerinin ölçümüne dayalı olarak başlatma sürelerinin geniş bir dağılım gösterdiğini tespit etti. Bunun yanı sıra, düşük teknolojiye sahip bazı mobil cihazların da Service Worker'ı başlatması, sonuç sayfasının HTML'si için ağ isteğinde bulunmak için gereken kadar zaman aldığını tespit etti.
Çözüm: Gezinme önceden yükleme özelliğini kullanın
Google Arama Ekibi'nin hizmet çalışanı lansmanıyla ilerlemesini sağlayan en önemli ve tek özellik, gezinme önceden yüklemesidir. Gezinme önyüklemesini kullanmak, gezinme isteklerini karşılamak için ağdan yanıt kullanması gereken tüm hizmet çalışanları için önemli bir performans kazancıdır. Tarayıcının, Service Worker çalışmaya başlar başlamaz, gezinme isteğinde bulunmaya hemen başlaması için bir ipucu sağlar:
Service Worker'ın başlatılması için gereken süre, ağdan yanıt almak için gereken süreden kısa olduğu sürece Service Worker tarafından hiçbir gecikme ek yükü oluşmaz.
Arama ekibinin, düşük teknolojiye sahip mobil cihazlarda hizmet çalışanı başlatma süresinin navigasyon isteğini aşabileceği durumlarda hizmet çalışanı kullanmaktan kaçınması da gerekiyordu. "Düşük teknolojili " bir cihaz olarak kabul edilen hızlı bir kural olmadığından, cihazda yüklü toplam RAM'i kontrol etme bulgusu elde ettiler. 2 gigabayttan daha az bellek içeren tüm hizmetler, hizmet çalışanı başlatma süresinin kabul edilemez olduğu alt segment cihaz kategorisinde yer alır.
Gelecekte kullanılmak üzere önbelleğe alınacak kaynakların tamamı birkaç megabayta kadar çalışabileceğinden, kullanılabilir depolama alanı bir diğer unsurdur. navigator.storage arayüzü, Google Arama sayfasının verileri önbelleğe alma denemelerinin depolama alanı kotasındaki hatalar nedeniyle başarısız olma riski taşıyıp taşımadığını önceden öğrenmesine olanak tanır.
Bu durum, Arama ekibine, hizmet çalışanı kullanılıp kullanılmayacağını belirlemek için kullanabilecekleri çok sayıda kriter kaldı: Kullanıcı Google Arama sayfasına, gezinme ön yüklemesini destekleyen bir tarayıcı kullanarak gelirse ve en az 2 gigabayt RAM ve yeterli boş depolama alanına sahipse hizmet çalışanı kayıtlıdır. Bu ölçütleri karşılamayan tarayıcılar veya cihazlar bir hizmet çalışanı oluşturmaz ancak her zaman olduğu gibi Google Arama deneyimini görmeye devam ederler.
Bu seçici kaydın bir yanı, daha küçük ve verimli bir hizmet çalışanı gönderebilmektir. Oldukça modern tarayıcıları Service Worker kodunu çalıştıracak şekilde hedeflemek, eski tarayıcılar için transpirasyon ve çoklu dolguların ek yükünü ortadan kaldırır. Bunun sonucunda, Service Worker uygulamasının toplam boyutundan yaklaşık 8 kilobaytlık sıkıştırılmamış JavaScript kodu kesilmiştir.
Sorun: Service Worker kapsamları
Arama ekibi yeterli sayıda gecikme denemesi yürüttükten ve navigasyon ön yükleme kullanımının, hizmet çalışanı kullanımı için uygun ve gecikmeden etkilenmeyen bir yol sunduğundan emin olduktan sonra bazı pratik sorunlar ön plana çıkmaya başladı. Bu sorunlardan biri, Service Worker'ın kapsam oluşturma kurallarıyla ilgilidir. Service Worker'ın kapsamı, hangi sayfaların kontrolünü alabileceğini belirler.
Kapsam oluşturma, URL yolu önekine göre çalışır. Normalde yalnızca maksimum kapsamı / olan bir Service Worker kullanmanız gerektiğinden, tek bir web uygulaması barındıran alanlar için bu bir soruna yol açmaz. Bu hizmet, alan adı altındaki herhangi bir sayfanın denetimini üstlenebilir.
Ancak Google Arama'nın URL yapısı biraz daha karmaşıktır.
Hizmet çalışanına maksimum / kapsamı verseydi www.google.com (veya bölgesel eşdeğeri) altında barındırılan herhangi bir sayfanın kontrolünü ele geçirebilirdi ve bu alan adı altında, Google Arama ile hiçbir ilgisi olmayan URL'ler vardır. Daha makul, kısıtlayıcı bir kapsam /search olacaktır. Bu da en azından arama sonuçlarıyla tamamen alakasız URL'leri ortadan kaldırır.
Ne yazık ki, /search URL yolu bile Google Arama sonuçlarının farklı türleri arasında paylaşılmaktadır. URL sorgu parametreleri, hangi arama sonucu türünün gösterileceğini belirler. Bu tatlardan bazıları, geleneksel web arama sonucu sayfasından
tamamen farklı kod tabanları kullanır. Örneğin, Görsel Arama ve Alışveriş Arama, /search URL yolu altında farklı sorgu parametreleriyle sunulur ancak bu arayüzlerin hiçbiri kendi hizmet çalışanı deneyimini sunmaya hazır değildir (henüz).
Çözüm: Bir dağıtım ve yönlendirme çerçevesi oluşturun
Service Worker kapsamlarını belirlemek için URL yolu öneklerinden daha güçlü bir yönteme olanak tanıyan bazı teklifler olsa da Google Arama ekibi, kontrol ettiği sayfaların alt kümesi için hiçbir şey yapmayan bir hizmet çalışanı dağıtma işlemini yapmakta zorlanmıştı.
Bu sorunu çözmek için Google Arama ekibi, istemci sayfasının sorgu parametreleri gibi ölçütleri kontrol edecek ve bunları kullanarak hangi kod yolunun aşağı gideceğini belirlemek üzere yapılandırılabilecek özel bir dağıtım ve yönlendirme çerçevesi oluşturdu. Sistem, kurallara gömmek yerine esnek olacak şekilde tasarlanmıştır. Görsel Arama ve Alışveriş Arama gibi URL alanını paylaşan ekiplerin, bu özelliği uygulamaya karar vermeleri durumunda kendi hizmet çalışanı mantığını takip etmelerine olanak tanır.
Sorun: kişiselleştirilmiş sonuçlar ve metrikler
Kullanıcılar Google Hesaplarını kullanarak Google Arama'da oturum açabilir ve arama sonuçları deneyimleri, kendi hesap verilerine göre özelleştirilebilir. Giriş yapmış kullanıcılar, saygın ve yaygın olarak desteklenen bir standart olan belirli tarayıcı çerezleri ile tanımlanır.
Bununla birlikte, tarayıcı çerezlerini kullanmanın dezavantajı, hizmet çalışanlarının içinde açığa çıkmamaları ve değerlerini otomatik olarak incelemenin ve kullanıcının çıkış yapması veya hesap değiştirmesi nedeniyle değişmediğinden emin olmanın bir yolu olmamasıdır. (Hizmet çalışanlarına çerez erişimi sağlamak için çalışmalar yapılmaktadır, ancak bu yazı hazırlandığı sırada, yaklaşım deneyseldir ve yaygın bir şekilde desteklenmemektedir.)
Service Worker'ın giriş yapmış mevcut kullanıcı ile Google Arama web arayüzüne giriş yapmış gerçek kullanıcı görüşü arasındaki uyuşmazlık, arama sonuçlarının yanlış şekilde kişiselleştirilmesine veya metriklerin ve günlük kaydının yanlış şekilde ilişkilendirilmesine yol açabilir. Bu başarısız senaryolardan herhangi biri, Google Arama ekibi için ciddi bir sorundur.
Çözüm: postMessage kullanarak çerez gönderin
Google Arama ekibi, deneysel API'lerin başlatılmasını ve hizmet çalışanı içindeki tarayıcı çerezlerine doğrudan erişim sağlamasını beklemek yerine bir geçici çözüm geliştirdi: Service Worker tarafından kontrol edilen bir sayfa her yüklendiğinde, sayfa ilgili çerezleri okur ve bunları hizmet çalışanına göndermek için postMessage() özelliğini kullanır.
Ardından Service Worker, mevcut çerez değerini beklediği değere göre kontrol eder. Uyuşmazlık olması durumunda kullanıcıya özel verileri depolama alanından silmek için adımlar atar ve herhangi bir yanlış kişiselleştirme olmadan arama sonuçları sayfasını yeniden yükler.
Service Worker'ın işleri bir referans değere sıfırlamak için uyguladığı belirli adımlar, Google Arama'nın gereksinimlerine özgüdür, ancak aynı genel yaklaşım, tarayıcı çerezlerinden alınmış kişiselleştirilmiş verilerle çalışan diğer geliştiriciler için de yararlı olabilir.
Sorun: Denemeler ve dinamik
Daha önce bahsedildiği gibi, Google Arama ekibi büyük ölçüde üretim aşamasında denemeler yapmaya ve yeni kod ile özellikleri varsayılan olarak etkinleştirmeden önce bunların gerçek dünyadaki etkilerini test etmeye dayanıyor. Kullanıcıların denemeleri etkinleştirip devre dışı bırakmaları genellikle arka uç sunucusuyla iletişim kurulmasını gerektirdiğinden bu işlem, büyük ölçüde önbelleğe alınan verilere dayanan statik bir hizmet çalışanı için zor olabilir.
Çözüm: Dinamik olarak oluşturulmuş Service Worker komut dosyası
Ekibin çözümü, önceden oluşturulan tek bir statik hizmet çalışanı komut dosyası yerine, her bir kullanıcı için web sunucusu tarafından özelleştirilmiş, dinamik olarak oluşturulmuş bir hizmet çalışanı komut dosyası kullanmaktı. Hizmet çalışanının davranışını veya genel olarak ağ isteklerini etkileyebilecek denemelerle ilgili bilgiler, bu özelleştirilmiş hizmet çalışanı komut dosyalarına doğrudan dahil edilir. Bir kullanıcı için etkin deneyim gruplarının değiştirilmesi, tarayıcı çerezleri gibi geleneksel tekniklerin birleştirilmesiyle yapılır ve kayıtlı Service Worker URL'sinde güncellenmiş kod sunulur.
Dinamik olarak oluşturulmuş bir Service Worker komut dosyası kullanmak, bir Service Worker uygulamasında kaçınılması gereken kritik bir hatanın olması gibi pek olası olmayan durumlarda bir kaçış yolu sağlanmasını da kolaylaştırır. Dinamik sunucu çalışanı yanıtı, mevcut kullanıcıların bir kısmı veya tamamı için Service Worker'ın etkili şekilde devre dışı bırakılmasına yol açan işlemsiz uygulama olabilir.
Sorun: güncellemeleri koordine etme
Gerçek dünyada hizmet çalışanı dağıtımlarının karşı karşıya olduğu en büyük zorluklardan biri, ağdan önbelleğin lehine olması arasında makul bir denge belirlemektir. Aynı zamanda mevcut kullanıcıların, kritik güncellemeler ve değişiklikleri üretime dağıtıldıktan hemen sonra almasını sağlamak da bu kapsamdadır. Doğru denge, birçok etkene bağlıdır:
- Web uygulamanızın, kullanıcının yeni sayfalara gitmeden süresiz olarak açık tuttuğu uzun ömürlü tek sayfalık bir uygulama olup olmadığı.
- Arka uç web sunucunuzda yapılan güncellemeler için dağıtım sıklığı.
- Ortalama bir kullanıcının, web uygulamanızın biraz eski bir sürümünü kullanmaya müteşekkir mi yoksa en önemli önceliğin güncellik mi olduğu.
Google Arama ekibi, hizmet çalışanlarıyla denemeler yaparken metriklerin ve kullanıcı deneyiminin, geri gelen kullanıcıların gerçek dünyada görecekleriyle daha yakından eşleşmesini sağlamak için denemeleri bir dizi planlanmış arka uç güncellemesinde çalıştırmaya devam etti.
Çözüm: Yenilik ile önbellek kullanımını dengeleyin
Google Arama ekibi bir dizi farklı yapılandırma seçeneğini test ettikten sonra, aşağıdaki kurulumun güncellik ile önbellek kullanımı arasında doğru dengeyi sağladığını tespit etmiştir.
Service Worker komut dosyası URL'si, Cache-Control: private, max-age=1500 (1500 saniye veya 25 dakika) yanıt başlığıyla sunulur ve üst bilginin öncelikli olmasını sağlamak için updateViaCache 'all' değerine ayarlandığında kaydedilir. Google Arama web arka ucu, tahmin edebileceğiniz gibi, mümkün olduğunca% 100'e yakın çalışma süresi gerektiren, küresel olarak dağıtılmış büyük bir sunucu kümesidir. Service Worker komut dosyasının içeriğini etkileyecek bir değişikliğin dağıtımı, periyodik olarak yapılır.
Bir kullanıcı güncellenmiş bir arka uca dokunursa ve daha sonra, güncellenmiş hizmet çalışanını henüz almamış bir arka uca ulaşan başka bir sayfaya hızlı bir şekilde giderse, sürümler arasında birkaç kez geçiş yapar. Bu nedenle, tarayıcıya yalnızca son kontrolün üzerinden 25 dakika geçmişse güncellenmiş bir komut dosyasını kontrol etmesinin önemli bir olumsuz etkisi olmayacaktır. Bu davranışı etkinleştirmenin avantajı, Service Worker komut dosyasını dinamik olarak oluşturan uç noktanın aldığı trafiği önemli ölçüde azaltır.
Buna ek olarak, Service Worker komut dosyasının HTTP yanıtında bir ETag üst bilgisi ayarlanır. Böylece, 25 dakika geçtikten sonra bir güncelleme kontrolü yapıldığında, sunucu, o sırada dağıtılan hizmet çalışanı için herhangi bir güncelleme olmamışsa HTTP 304 yanıtıyla verimli bir şekilde yanıt verebilir.
Google Arama web uygulamasındaki bazı etkileşimlerde tek sayfalık uygulama tarzı gezinme (ör.History API üzerinden) kullanılır. Ancak Google Arama, çoğunlukla "gerçek" gezinmeleri kullanan geleneksel bir web uygulamasıdır. Ekip, hizmet çalışanı güncelleme yaşam döngüsünü hızlandıracak iki seçeneği kullanmanın etkili olacağına karar verdiğinde bu durum devreye girer: clients.claim() ve skipWaiting().
Google Arama arayüzünde herhangi bir yeri tıkladığınızda genellikle
yeni HTML dokümanlarına yönlendirilirsiniz. skipWaiting çağrıldığında, güncellenmiş bir hizmet çalışanı bu yeni gezinme isteklerini kurulumdan hemen sonra işleme fırsatı elde eder. Benzer şekilde, clients.claim() çağrıldığında güncellenen hizmet çalışanı, hizmet çalışanı etkinleştirmesinin ardından kontrolsüz açık Google Arama sayfalarını kontrol etmeye başlayabilir.
Google Arama'nın benimsediği yaklaşım herkes için işe yarayan bir çözüm olmayabilir. Bu, kendileri için en uygun seçeneği bulana kadar çeşitli sunum seçeneği kombinasyonlarının dikkatli bir şekilde A/B testi yapılmasının bir sonucuydu.
Arka uç altyapısı, güncellemeleri daha hızlı dağıtmalarına olanak tanıyan geliştiriciler, tarayıcının güncellenmiş hizmet çalışanı komut dosyasını mümkün olduğunca sık kontrol etmesini ve HTTP önbelleğini her zaman yok sayarak kontrol etmesini tercih edebilir.
Kullanıcıların uzun süre açık tutabileceği tek sayfalık bir uygulama oluşturuyorsanız skipWaiting() sizin için doğru seçim olmayabilir. Uzun süreli istemciler varken yeni Service Worker'ın etkinleşmesine izin verirseniz önbellek tutarsızlıklarıyla karşılaşma riskiyle karşılaşabilirsiniz.
Temel çıkarımlar
Varsayılan olarak Service Worker'lar performans açısından duyarsız değildir.
Web uygulamanıza Service Worker eklemek, web uygulamanızın isteklerine yanıt almadan önce yüklenmesi ve yürütülmesi gereken ek bir JavaScript parçası eklemek anlamına gelir. Bu yanıtlar ağ yerine yerel bir önbellekten geliyorsa önbellek öncelikli olmanın sağlayacağı performans kazancına kıyasla Service Worker'ı çalıştırmanın ek yükü genellikle göz ardı edilebilir. Ancak, hizmet çalışanınızın gezinme isteklerini ele alırken her zaman ağa danışması gerektiğini biliyorsanız gezinme önceden yükleme özelliğini kullanmak, önemli bir performans kazancıdır.
Service Worker'lar (hâlâ!) progresif bir gelişmedir
Service Worker'ın destek hikayesi bugün bir yıl öncesine göre çok daha canlı. Tüm modern tarayıcılarda artık en azından bir miktar Service Worker desteği vardır. Ancak ne yazık ki, arka plan senkronizasyonu ve gezinmeyi önceden yükleme gibi evrensel olarak sunulmayan bazı gelişmiş Service Worker özellikleri de mevcuttur. İhtiyaç duyduğunuzu bildiğiniz belirli bir özellik alt kümesi için özellik kontrolü yapmak ve bir Service Worker'ı yalnızca bu özellikler varken kaydetmek, yine de makul bir yaklaşımdır.
Benzer şekilde, herhangi bir ortamda denemeler yaptıysanız ve düşük donanımlı cihazların, bir hizmet çalışanının ek yükü nedeniyle düşük performans gösterdiğini biliyorsanız bu senaryolarda bir hizmet çalışanı kaydetmekten de kaçınabilirsiniz.
Service Worker'ları, tüm ön koşullar karşılandığında ve hizmet çalışanı kullanıcı deneyimi ile genel yükleme performansına olumlu bir şey kattığında web uygulamasına eklenen bir progresif geliştirme olarak değerlendirmeye devam etmelisiniz.
Her şeyi ölçün
Bir hizmet çalışanının gönderiminin kullanıcı deneyimlerinde olumlu veya olumsuz bir etkisinin olup olmadığını anlamanın tek yolu, denemeler yapıp sonuçları ölçmektir.
Anlamlı ölçümler oluşturmanın ayrıntıları, hangi analiz sağlayıcısını kullandığınıza ve normalde dağıtım kurulumunuzda denemeleri nasıl yaptığınıza bağlıdır. Metrik toplamak için Google Analytics'in kullanılmasıyla ilgili bir yaklaşım, Google I/O web uygulamasında Service Worker'ları kullanma deneyimi temel alınarak hazırlanan bu örnek olayda ayrıntılı olarak açıklanmıştır.
Hedef olmayanlar
Web geliştirme topluluk bünyesinde hizmet çalışanlarını Progresif Web Uygulamaları ile ilişkilendiren birçok kişi hizmet çalışanı olsa da "Google Arama PWA" oluşturmak ekibin başlangıçtaki hedeflerinden biri değildi. Google Arama web uygulaması şu anda bir web uygulaması manifesti aracılığıyla meta veri sağlamamakta ve kullanıcıları Ana Ekrana Ekle akışını gerçekleştirmeye teşvik etmemektedir. Arama ekibi şu anda web uygulamasına Google Arama'nın geleneksel giriş noktalarından gelen kullanıcılardan memnun.
Google Arama web deneyimini yüklü bir uygulamadan bekleyeceğinize eşdeğer hale getirmeye çalışmak yerine, ilk kullanıma sunma üzerinde odak noktamız mevcut web sitesini kademeli olarak geliştirmekti.
Teşekkür
Servis çalışanı uygulaması konusundaki çalışmaları ve bu makalenin hazırlanmasında kullanılan arka plan materyallerini paylaştıkları için tüm Google Arama web geliştirme ekibine teşekkür ederiz. Teşekkürler, Philippe Golle, Rajesh Jagannathan, R. Samuel Klatchko, Andy Martone, Leonardo Peña, Rachel Shearer, Greg Terrono ve Clay Woolam.
Güncelleme (Ekim 2021): Bu makale ilk kez yayınlandığından beri Google Arama Ekibi, mevcut Service Worker mimarisinin avantajlarını ve dengelerini yeniden değerlendirdi. Yukarıda açıklanan hizmet çalışanı kullanımdan kaldırılıyor. Google Arama'nın web altyapısı geliştikçe ekip, hizmet çalışanı tasarımını yeniden ziyaret edebilir.