Gönderilenler, etkinin nasıl ölçüldüğü ve yapılan ödünler hakkında bilgi verin.
Arka plan
Google'da hemen hemen her konuyu aradığınızda anlamlı ve alakalı sonuçlar içeren, hemen tanıyabileceğiniz bir sayfayla karşılaşırsınız. Bu arama sonuçları sayfasının, belirli senaryolarda hizmet çalışanı adı verilen güçlü bir web teknolojisi tarafından sunulduğu muhtemelen farkında değildiniz.
Google Arama için hizmet çalışanı desteğini performansı olumsuz etkilemeden kullanıma sunmak, birden fazla ekipte çalışan düzinelerce mühendisin çalışmasını gerektirdi. Bu makalede, hangi özelliklerin kullanıma sunulduğu, performansın nasıl ölçüldüğü ve hangi ödünlerin verildiği anlatılmaktadır.
Hizmet işçilerini keşfetmenin temel nedenleri
Bir web uygulamasına hizmet çalışanı eklemek, tıpkı sitenizde mimari bir değişiklik yapmak gibi, net bir hedef kümesi göz önünde bulundurularak yapılmalıdır. Google Arama Ekibi, bir hizmet çalışanı eklemenin incelenmeye değer olmasının birkaç önemli nedeni olduğunu düşünüyordu.
Sınırlı arama sonucu önbelleğe alma
Google Arama ekibi, kullanıcıların kısa süre içinde aynı terimleri birden fazla kez aradığını tespit etti. Arama ekibi, aynı sonuçlara ulaşmak için yeni bir arka uç isteği tetiklemek yerine önbelleğe alma özelliğinden yararlanmak ve bu tekrarlanan istekleri yerel olarak yerine getirmek istedi.
Güncelliğin önemi göz ardı edilemez. Bazen kullanıcılar, gelişen bir konu olduğu için aynı terimleri tekrar tekrar arar ve güncel sonuçlar görmeyi bekler. Hizmet çalışanı kullanmak, Arama Ekibi'nin yerel olarak önbelleğe alınan arama sonuçlarının ömrünü kontrol etmek için ayrıntılı mantık uygulamasına ve kullanıcılara en iyi hizmeti verdiğini düşündükleri hız ile tazelik dengesini tam olarak yakalamasına olanak tanır.
Anlamlı çevrimdışı deneyim
Ayrıca Google Arama ekibi, anlamlı bir çevrimdışı deneyim sunmak istiyordu. Kullanıcılar bir konu hakkında bilgi edinmek istediklerinde doğrudan Google Arama sayfasına gidip etkin bir internet bağlantısı olup olmadığından endişelenmeden aramaya başlamak ister.
Hizmet çalışanı olmadan, çevrimdışıyken Google arama sayfasını ziyaret etmek yalnızca tarayıcının standart ağ hatası sayfasına yönlendirir ve kullanıcıların bağlantıları geri geldiğinde tekrar denemek için geri gelmeyi hatırlamaları gerekir. Hizmet işçisi sayesinde özel bir çevrimdışı HTML yanıtı sunabilir ve kullanıcıların arama sorgularını hemen girmelerine izin verebilirsiniz.
Sonuçlar, internet bağlantısı sağlanana kadar kullanılamaz ancak hizmet çalışanı, arka plan senkronizasyon API'sini kullanarak cihaz tekrar internete bağlanır bağlanmaz aramanın ertelenmesine ve Google'ın sunucularına gönderilmesine olanak tanır.
Daha akıllı JavaScript önbelleğe alma ve sunma
Diğer bir neden de, arama sonuçları sayfasındaki çeşitli özellik türlerini destekleyen modülerleştirilmiş JavaScript kodunun önbelleğe alınması ve yüklenmesi işlemlerini optimize etmekti. JavaScript paketlemenin, hizmet çalışanı kullanılmadığında anlamlı olan çeşitli avantajları vardır. Bu nedenle Arama ekibi, paketlemeyi tamamen durdurmak istememiştir.
Arama ekibi, hizmet çalışanının çalışma zamanında JavaScript'in ayrıntılı parçalarını sürümlendirme ve önbelleğe alma özelliğini kullanarak önbelleğe alma değişikliği miktarını azaltabileceğini ve gelecekte yeniden kullanılan JavaScript'in verimli bir şekilde önbelleğe alınabileceğinden emin olabileceğini düşündü. Hizmet işçisinin içindeki mantık, birden fazla JavaScript modülü içeren bir paket için giden bir HTTP isteğini analiz edebilir ve mümkün olduğunda "paketi çözerek" birden fazla yerel olarak önbelleğe alınmış modülü bir araya getirerek isteği yerine getirebilir. Bu sayede kullanıcı bant genişliği tasarrufu sağlanır ve genel yanıt verme durumu iyileşir.
Bir hizmet çalışanı tarafından sunulan önbelleğe alınmış JavaScript'i kullanmanın performans açısından da avantajları vardır: Chrome'da, söz konusu JavaScript'in ayrıştırılmış, bayt kodu temsili depolanır ve yeniden kullanılır. Bu sayede, sayfadaki JavaScript'i çalıştırmak için çalışma zamanında yapılması gereken iş azalır.
Zorluklar ve çözümler
Ekibin belirttiği hedeflere ulaşmak için aşılması gereken engellerden birkaçını aşağıda bulabilirsiniz. Bu zorlukların bazıları Google Arama'ya özgü olsa da çoğu, hizmet çalışanı dağıtımı düşünen çok çeşitli siteler için geçerlidir.
Sorun: Hizmet çalışanı yükü
Google Arama'da bir hizmet çalışanını kullanıma sunmanın en büyük zorluğu ve tek gerçek engelleyicisi, kullanıcı tarafından algılanan gecikmeyi artırabilecek herhangi bir işlem yapmamasını sağlamaktı. Google Arama, performansı çok ciddiye alır ve geçmişte, belirli bir kullanıcı kitlesi için on milisaniye bile ek gecikme süresine neden olan yeni işlevlerin kullanıma sunulmasını engellemiştir.
Ekip, ilk denemelerinde performans verileri toplamaya başladığında bir sorun yaşanacağı 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ıştırılması gereken mantığa bağlı olarak büyük ölçüde değişiklik gösterir. Hizmet çalışanının şu anda bu mantığı kopyalayıp ö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. Bu da bir ağ isteği gerektirir.
Hizmet çalışanı olmadan bu ağ isteği, kullanıcı gezinme işlemini gerçekleştirdiğinde hemen gerçekleşir. Bir hizmet çalışanı kaydedildiğinde, bu getirme işleyicilerinin ağa gitmekten başka bir şey yapma şansı olmadığında bile her zaman başlatılması ve fetch etkinlik işleyicilerini yürütmesi için bir fırsat verilmesi gerekir. Hizmet işleyici kodunu başlatmak ve çalıştırmak için gereken süre, her gezinmenin üzerine eklenen saf ek yüktür:
Bu durum, hizmet çalışanı uygulamasını diğer avantajları haklı çıkarmayacak kadar fazla gecikmeye maruz bırakır. Ayrıca ekip, gerçek cihazlardaki hizmet çalışanı önyükleme sürelerini ölçerek, başlangıç sürelerinin geniş bir aralıkta olduğunu tespit etti. Bazı düşük kaliteli mobil cihazlarda, hizmet çalışanını başlatmak için gereken süre, sonuç sayfasının HTML'si için ağ isteği gönderme süresine neredeyse eşitti.
Çözüm: Navigasyon ön yükleme özelliğini kullanın
Google Arama ekibinin hizmet çalışanı lansmanıyla ilerlemesine olanak tanıyan en önemli özellik gezinme ön yüklemesidir. Gezinme ön yükleme özelliğini kullanmak, gezinme isteklerini karşılamak için ağdan yanıt kullanması gereken tüm hizmet çalışanları için önemli bir performans kazancı sağlar. Tarayıcıya, servis çalışanı başlatılırken aynı anda gezinme isteğini hemen göndermesi için bir ipucu sağlar:
Servis çalışanının başlatılması için gereken süre, ağdan yanıt alınması için gereken süreden kısa olduğu sürece servis çalışanı tarafından gecikme yükü oluşturulmaz.
Arama ekibinin, hizmet çalışanının önyükleme süresinin gezinme isteğini aşabileceği düşük kaliteli mobil cihazlarda hizmet çalışanı kullanmaktan da kaçınması gerekiyordu. "Düşük kaliteli " cihazı tanımlayan kesin bir kural olmadığından, cihaza yüklenen toplam RAM'i kontrol etme heuristiği geliştirildi. 2 gigabayttan az belleğe sahip cihazlar, servis çalışanı başlatma süresinin kabul edilemeyeceği düşük kaliteli cihaz kategorisine giriyordu.
Gelecekte kullanılmak üzere önbelleğe alınacak tüm kaynak grubu birkaç megabayta kadar çıkabileceğinden, kullanılabilir depolama alanı da dikkate alınması gereken bir faktördür. navigator.storage arayüzü, Google Arama sayfasının verileri önbelleğe alma girişimlerinin depolama alanı kotası hataları nedeniyle başarısız olma riskini önceden belirlemesine olanak tanır.
Bu sayede Arama Ekibi, bir hizmet çalışanının kullanılıp kullanılmayacağını belirlemek için kullanabileceği birden fazla ölçüt elde etti: Bir kullanıcı, gezinme ön yüklemeyi destekleyen bir tarayıcı kullanarak Google Arama sayfasına gelirse ve en az 2 gigabayt RAM'e ve yeterli boş depolama alanına sahipse bir hizmet çalışanı kaydedilir. Bu ölçütleri karşılamayan tarayıcılar veya cihazlar bir hizmet çalışanı kullanmaz ancak her zamanki gibi aynı Google Arama deneyimini görür.
Bu seçmeli kayıt işleminin bir avantajı, daha küçük ve daha verimli bir hizmet çalışanı gönderme olanağıdır. Hizmet çalışanı kodunu çalıştırmak için oldukça modern tarayıcıları hedeflemek, eski tarayıcılar için kod dönüştürme ve çoklu doldurma işlemlerinin ek yükünü ortadan kaldırır. Bu sayede, hizmet çalışanının uygulamasının toplam boyutundan yaklaşık 8 kilobayt sıkıştırılmamış JavaScript kodu çıkarıldı.
Sorun: hizmet çalışanı kapsamları
Arama ekibi yeterli gecikme denemesi yaptıktan ve gezinme ön yükleme özelliğinin, hizmet çalışanı kullanmak için gecikme açısından nötr ve uygun bir yol sunduğunu anladıktan sonra bazı pratik sorunlar ön plana çıkmaya başladı. Bu sorunlardan biri, hizmet çalışanının kapsama kuralları ile ilgilidir. Hizmet çalışanının kapsamı, hangi sayfaların kontrolünü alabileceğini belirler.
Kapsam belirleme, URL yolu ön ekine göre çalışır. Tek bir web uygulaması barındıran alanlar için bu sorun teşkil etmez. Normalde, alanın altındaki tüm sayfaların kontrolünü ele alabilecek / maksimum kapsamına sahip bir hizmet çalışanı kullanırsınız.
Ancak Google Arama'nın URL yapısı biraz daha karmaşıktır.
Hizmet çalışanına / için maksimum kapsam verilirse www.google.com altında barındırılan (veya bölgesel eşdeğeri) herhangi bir sayfanın kontrolünü ele alabilir. Bu alan altında Google Arama ile hiçbir ilgisi olmayan URL'ler vardır. Daha makul ve kısıtlayıcı bir kapsam /search olur. Bu kapsam, en azından arama sonuçlarıyla tamamen alakasız URL'leri ortadan kaldırır.
Maalesef bu /search URL yolu bile farklı Google Arama sonuçları arasında paylaşılır. URL sorgu parametreleri, hangi arama sonucu türünün gösterileceğini belirler. Bu varyantlardan bazıları, geleneksel web arama sonucu sayfasından tamamen farklı kod tabanlarını kullanır. Örneğin, Resim Arama ve Alışveriş Arama'nın ikisi de farklı sorgu parametreleriyle /search URL yolunda yayınlanır ancak bu arayüzlerin hiçbiri henüz kendi hizmet çalışanı deneyimini sunmaya hazır değildir.
Çözüm: Dağıtım ve yönlendirme çerçevesi oluşturun
Hizmet çalışanı kapsamlarını belirlemek için URL yolu ön eklerinden daha güçlü bir şeye izin veren bazı öneriler olsa da Google Arama ekibi, kontrol ettiği sayfaların bir alt kümesi için hiçbir şey yapmayan bir hizmet çalışanı dağıtmakta zorlandı.
Bu sorunun üstesinden gelmek için Google Arama ekibi, istemci sayfasının sorgu parametreleri gibi ölçütleri kontrol edecek ve hangi kod yolunun kullanılacağını belirlemek için bunları kullanacak şekilde yapılandırılabilir özel bir dağıtım ve yönlendirme çerçevesi oluşturdu. Sistem, kuralları sabit kodlamak yerine esnek olacak şekilde tasarlandı. Böylece, URL alanını paylaşan ekipler (ör. Görsel Arama ve Alışveriş Arama) uygulamaya karar verirlerse kendi hizmet çalışanı mantıklarını daha sonra ekleyebilirler.
Sorun: kişiselleştirilmiş sonuçlar ve metrikler
Kullanıcılar Google Hesaplarını kullanarak Google Arama'da oturum açabilir. Arama sonuçları deneyimleri, hesap verilerine göre özelleştirilebilir. Oturum açmış kullanıcılar, saygın ve yaygın olarak desteklenen bir standart olan belirli tarayıcı çerezleriyle tanımlanır.
Ancak tarayıcı çerezlerinin bir dezavantajı, hizmet çalışanının içinde gösterilmemeleridir. Bu nedenle, değerlerini otomatik olarak inceleyip kullanıcının oturumunu kapatması veya hesap değiştirmesi nedeniyle değişmediğinden emin olmanın bir yolu yoktur. (Çerez erişimini hizmet işçilerine sunma çalışmaları devam etmektedir ancak bu makalenin yazıldığı tarih itibarıyla bu yaklaşım deneysel olup yaygın olarak desteklenmemektedir.)
Hizmet çalışanının, giriş yapan mevcut kullanıcıyla Google Arama web arayüzüne giriş yapan gerçek kullanıcı arasında bir uyuşmazlık olması, yanlış kişiselleştirilmiş arama sonuçlarına veya yanlış ilişkilendirilmiş metriklere ve günlük kayıtlarına neden olabilir. Bu başarısızlık senaryolarından herhangi biri Google Arama Ekibi için ciddi bir sorundur.
Çözüm: postMessage kullanarak çerez gönderin
Google Arama ekibi, deneysel API'lerin kullanıma sunulmasını ve bir hizmet çalışanı içinde tarayıcının çerezlerine doğrudan erişim sağlamasını beklemek yerine geçici bir çözüme başvurdu: Hizmet çalışanı tarafından kontrol edilen bir sayfa her yüklendiğinde, sayfa ilgili çerezleri okur ve postMessage() kullanarak hizmet çalışanına gönderir.
Ardından hizmet çalışanı, mevcut çerez değerini beklediği değerle karşılaştırır ve bir uyuşmazlık varsa kullanıcıya özgü tüm verileri depolama alanından temizlemek için adımlar atar ve arama sonuçları sayfasını yanlış kişiselleştirme olmadan yeniden yükler.
Hizmet çalışanının, her şeyi bir taban çizgiye sıfırlamak için uyguladığı belirli adımlar Google Arama'nın koşullarına özeldir ancak aynı genel yaklaşım, tarayıcıların çerezlerine dayalı olarak kişiselleştirilmiş verilerle uğraşan diğer geliştiriciler için yararlı olabilir.
Sorun: denemeler ve dinamizm
Daha önce de belirtildiği gibi Google Arama ekibi, yeni kod ve özelliklerin varsayılan olarak etkinleştirilmeden önce üretimde denemeler yapmayı ve gerçek dünyadaki etkilerini test etmeyi önemser. Kullanıcıları denemelere dahil etmek ve denemelerden çıkarmak genellikle arka uç sunucusuyla iletişim kurmayı gerektirdiğinden, büyük ölçüde önbelleğe alınmış verilere dayanan statik bir hizmet çalışanı için bu biraz zor olabilir.
Çözüm: dinamik olarak oluşturulmuş hizmet çalışanı komut dosyası
Ekip, önceden oluşturulmuş tek bir statik hizmet çalışanı komut dosyası yerine, web sunucusu tarafından her kullanıcı için özelleştirilen dinamik olarak oluşturulmuş bir hizmet çalışanı komut dosyası kullanmaya karar verdi. Hizmet çalışanının davranışını veya genel olarak ağ isteklerini etkileyebilecek denemeler hakkındaki bilgiler doğrudan bu özelleştirilmiş hizmet çalışanı komut dosyalarına dahil edilir. Bir kullanıcının etkin deneyim grupları, tarayıcı çerezleri gibi geleneksel tekniklerin bir kombinasyonu ve kayıtlı hizmet çalışanı URL'sinde güncellenmiş kodun sunulması yoluyla değiştirilir.
Dinamik olarak oluşturulmuş bir hizmet çalışanı komut dosyası kullanmak, hizmet çalışanı uygulamasında kaçınılması gereken ölümcül bir hata olması gibi olası bir durumda bir kaçış kapısı sağlamanızı da kolaylaştırır. Dinamik sunucu işleyici yanıtı, iş yapmayan bir uygulama olabilir. Bu durumda, hizmet işleyici mevcut kullanıcıların bir kısmı veya tamamı için etkinleştirilmez.
Sorun: Güncellemeleri koordine etme
Gerçek dünyadaki hizmet çalışanı dağıtımlarında karşılaşılan en zorlu zorluklardan biri, ağ yerine önbelleği kullanmaktan kaçınırken aynı zamanda mevcut kullanıcıların kritik güncellemeleri ve değişiklikleri üretime dağıtıldıktan kısa bir süre sonra almasını sağlamaktır. Doğru denge birçok faktöre 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ü bir tek sayfalık uygulama olup olmadığı.
- Arka uç web sunucunuzdaki güncellemelerin dağıtım ritmi.
- Ortalama bir kullanıcının, web uygulamanızın biraz eski bir sürümünü kullanmasına izin verip vermeyeceği veya güncelliğin birinci öncelik olup olmadığı.
Google Arama ekibi, hizmet işçileriyle deneme yaparken metrikleri ve kullanıcı deneyimini, geri gelen kullanıcıların gerçek dünyada göreceği deneyimle daha uyumlu hale getirmek için denemelerin bir dizi planlanmış arka uç güncellemesinde çalışmaya devam etmesini sağladı.
Çözüm: Güncelliği ve önbelleği kullanmayı dengele
Google Arama ekibi, çeşitli yapılandırma seçeneklerini test ettikten sonra aşağıdaki kurulumun tazelik ve önbelleğe alma kullanımı arasında doğru dengeyi sağladığını tespit etti.
Hizmet çalışanı komut dosyası URL'si, Cache-Control: private, max-age=1500 (1.500 saniye veya 25 dakika) yanıt üst bilgisiyle birlikte yayınlanır ve üst bilginin dikkate alınmasını sağlamak için updateViaCache özelliği "all" olarak ayarlanarak kaydedilir. Google Arama web arka ucu, tahmin edebileceğiniz gibi, mümkün olduğunca% 100'e yakın çalışma süresi gerektiren, dünya genelinde dağıtılmış büyük bir sunucu grubudur. Hizmet çalışanı komut dosyasının içeriğini etkileyecek bir değişikliğin dağıtımı, aşamalı olarak yapılır.
Kullanıcı güncellenmiş bir arka uca ulaşır ve ardından hızlıca başka bir sayfaya giderse bu sayfa henüz güncellenmiş hizmet işçisini almamış bir arka uca ulaşır. Sonuç olarak kullanıcı, sürümler arasında birden fazla kez geçiş yapar. Bu nedenle, tarayıcıya güncellenmiş bir komut dosyası olup olmadığını yalnızca son kontrolden 25 dakika geçtiğinde kontrol etmesini söylemekte önemli bir sakınca yoktur. Bu davranışı etkinleştirmenin avantajı, hizmet çalışanı komut dosyasını dinamik olarak oluşturan uç noktanın aldığı trafiği önemli ölçüde azaltmasıdır.
Ayrıca, hizmet çalışanı komut dosyasının HTTP yanıtında bir ETag başlığı ayarlanır. Bu, 25 dakika geçtikten sonra bir güncelleme kontrolü yapıldığında, bu süre zarfında hizmet çalışanında herhangi bir güncelleme yapılmadıysa sunucunun HTTP 304 yanıtıyla verimli bir şekilde yanıt vermesini sağlar.
Google Arama web uygulamasındaki bazı etkileşimler tek sayfalık uygulama tarzı gezinme menüleri (ör. History API aracılığıyla) kullansa da Google Arama, çoğunlukla "gerçek" gezinme menüleri kullanan geleneksel bir web uygulamasıdır. Bu, ekip hizmet çalışanı güncelleme yaşam döngüsünü hızlandıran iki seçeneğin kullanılmasının etkili olacağına karar verdiğinde devreye girer:
clients.claim()
ve
skipWaiting().
Google Arama arayüzünde tıklama işlemi genellikle yeni HTML dokümanlarına yönlendirir. skipWaiting çağrısı, güncellenmiş bir hizmet çalışanının yükleme işleminden hemen sonra bu yeni gezinme isteklerini işleme şansı elde etmesini sağlar. Benzer şekilde, clients.claim() çağrısı, güncellenen hizmet çalışanının hizmet çalışanı etkinleştirildikten sonra kontrol edilmeyen tüm açık Google Arama sayfalarını kontrol etmeye başlama şansı elde ettiği anlamına gelir.
Google Arama'nın benimsediği yaklaşım, herkes için işe yarayan bir çözüm değildir. Bu yaklaşım, kendileri için en iyi sonucu verene kadar çeşitli yayın seçenekleri kombinasyonlarını dikkatlice A/B test etmenin sonucudur.
Arka uç altyapıları güncellemeleri daha hızlı dağıtmalarına olanak tanıyan geliştiriciler, HTTP önbelleğini her zaman yok sayarak tarayıcının güncellenmiş bir hizmet çalışanı komut dosyasını mümkün olduğunca sık kontrol etmesini tercih edebilir.
Kullanıcıların uzun süre açık tutabileceği tek sayfalık bir uygulama geliştiriyorsanız skipWaiting() kullanmak muhtemelen sizin için doğru seçim değildir. Uzun ömürlü istemciler varken yeni hizmet çalışanının etkinleşmesine izin verirseniz önbelleğe alma tutarsızlıklarıyla karşılaşma riskiniz vardır.
Temel çıkarımlar
Hizmet çalışanları varsayılan olarak performans açısından nötr değildir.
Web uygulamanıza hizmet çalışanı eklemek, web uygulamanız 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ğdan değil de yerel bir önbellekten geliyorsa hizmet çalışanını çalıştırmanın yükü, önbelleğe öncelik vermeden elde edilen performans kazancıyla karşılaştırıldığında genellikle önemsizdir. Ancak servis çalışanınızın, gezinme isteklerini işlerken her zaman ağa danışması gerektiğini biliyorsanız gezinme ön yükleme özelliğini kullanmak önemli bir performans kazancı sağlar.
Hizmet çalışanları (hala!) aşamalı bir geliştirmedir
Hizmet çalışanı desteğiyle ilgili durum, bir yıl öncesine kıyasla çok daha iyi. Tüm modern tarayıcılar artık hizmet çalışanları için en azından bir miktar destek sunuyor ancak maalesef arka plan senkronizasyonu ve gezinme ön yükleme gibi bazı gelişmiş hizmet çalışanı özellikleri evrensel olarak kullanıma sunulmuyor. İhtiyacınız olduğunu bildiğiniz belirli bir özellik alt kümesi için özellik kontrolü yapmak ve yalnızca bu özellikler mevcut olduğunda bir hizmet çalışanı kaydetmek yine de makul bir yaklaşımdır.
Benzer şekilde, gerçek ortamda denemeler yaptıysanız ve düşük kaliteli cihazların, hizmet işçisinin ek yükü nedeniyle kötü performans gösterdiğini biliyorsanız bu senaryolarda da hizmet işçisi kaydetmekten kaçınabilirsiniz.
Hizmet işçilerini, tüm ön koşullar karşılandığında ve hizmet işçisi kullanıcı deneyimine ve genel yükleme performansına olumlu bir katkı sağladığında bir web uygulamasına eklenen aşamalı bir geliştirme olarak değerlendirmeye devam etmelisiniz.
Her şeyi ölçün
Bir hizmet işçisinin yayınlanmasının kullanıcılarınızın deneyimleri üzerinde olumlu veya olumsuz bir etkisi olup olmadığını öğrenmenin tek yolu deneme yapmak ve sonuçları ölçmektir.
Anlamlı ölçümler oluşturmayla ilgili ayrıntılar, hangi analiz sağlayıcıyı kullandığınıza ve dağıtım kurulumunuzda normalde denemeleri nasıl yürüttüğünüze bağlıdır. Metrikleri toplamak için Google Analytics'i kullanmaya yönelik bir yaklaşım, Google I/O web uygulamasında hizmet işçilerinin kullanıldığı deneyime dayalı olarak bu örnek olayda ayrıntılı olarak açıklanmıştır.
Hedef olmayanlar
Web geliştirme topluluğundaki birçok kişi hizmet çalışanlarını Progresif Web Uygulamaları ile ilişkilendirse de "Google Arama PWA" oluşturmak ekibin ilk hedefi değildi. Google Arama web uygulaması şu anda web uygulaması manifesti aracılığıyla meta veri sağlamaz veya kullanıcıları Ana ekrana ekleme akışında ilerlemeye teşvik etmez. Arama ekibi şu anda web uygulamasına Google Arama'nın geleneksel giriş noktaları üzerinden gelen kullanıcılardan memnun.
Google Arama web deneyimini, yüklü bir uygulamadan beklediğinize eşdeğer hale getirmeye çalışmak yerine, ilk kullanıma sunma sürecinde mevcut web sitesini aşamalı olarak iyileştirmeye odaklanıldı.
Teşekkür ederiz
Hizmet çalışanı uygulama konusundaki çalışmaları ve bu makalenin yazılmasında kullanılan arka plan materyallerini paylaşmalarından dolayı Google Arama web geliştirme ekibinin tamamına teşekkür ederiz. Özellikle Philippe Golle, Rajesh Jagannathan, R. Samuel Klatchko, Andy Martone, Leonardo Peña, Rachel Shearer, Greg Terrono ve Clay Woolam.
Güncelleme (Ekim 2021): Bu makalenin ilk yayınlanmasından bu yana Google Arama Ekibi, mevcut hizmet çalışanı mimarisinin avantajlarını ve dezavantajlarını yeniden değerlendirdi. Yukarıda açıklanan hizmet çalışanı kullanımdan kaldırılıyor. Google Arama web altyapısı geliştikçe ekip, hizmet çalışanı tasarımını yeniden gözden geçirebilir.