Hangi ürünlerin gönderildiği, etkinin nasıl ölçüldüğü ve yapılan fedakarlıklarla ilgili hikaye.
Yayınlanma tarihi: 20 Haziran 2019
Google'da neredeyse her konuyu aradığınızda anlamlı ve alakalı sonuçların yer aldığı, anında tanınabilir bir sayfa gösterilir. Muhtemelen fark etmediğiniz şey, bu arama sonuçları sayfasının belirli senaryolarda service worker adı verilen güçlü bir web teknolojisiyle sunulduğudur.
Google Arama'da hizmet çalışanı desteğini, performansı olumsuz etkilemeden kullanıma sunmak için birden fazla ekipte çalışan düzinelerce mühendis gerekti. Bu, hangi özelliklerin kullanıma sunulduğu, performansın nasıl ölçüldüğü ve hangi ödünlerin verildiği ile ilgili bir hikayedir.
Service worker'ları keşfetmenin temel nedenleri
Web uygulamasına hizmet çalışanı eklemek, sitenizde herhangi bir mimari değişiklik yapmak gibi, net bir hedef grubu göz önünde bulundurularak yapılmalıdır. Google Arama Ekibi için hizmet çalışanı eklemenin araştırılmaya değer olmasının birkaç temel nedeni vardı.
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 aramasının yaygın olduğunu tespit etti. Arama Ekibi, büyük olasılıkla aynı sonuçları elde etmek için yeni bir arka uç isteği tetiklemek yerine önbelleğe almadan yararlanmak ve bu tekrarlanan istekleri yerel olarak karşılamak istedi.
Güncelliğin önemi göz ardı edilemez. Kullanıcılar bazen gelişen bir konu olduğu için aynı terimleri tekrar tekrar arar ve güncel sonuçlar görmeyi bekler. Bir service worker kullanmak, Arama ekibinin yerel olarak önbelleğe alınmış arama sonuçlarının kullanım ömrünü kontrol etmek için ayrıntılı bir mantık uygulamasına ve kullanıcıların en iyi şekilde yararlanabileceği hız ile güncellik arasında tam olarak denge kurmasına olanak tanır.
Anlamlı çevrimdışı deneyim
Ayrıca Google Arama Ekibi, anlamlı bir çevrimdışı deneyim sunmak istiyordu. Bir konu hakkında bilgi edinmek isteyen kullanıcılar, etkin bir internet bağlantısı konusunda endişelenmeden doğrudan Google Arama sayfasına gidip aramaya başlamak ister.
Service worker olmadan, Google arama sayfasını çevrimdışıyken 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 geri dönüp tekrar denemeyi hatırlaması gerekir. Service worker ile özel bir çevrimdışı HTML yanıtı sunmak ve kullanıcıların arama sorgularını hemen girmesine izin vermek mümkündür.
Sonuçlar internet bağlantısı kurulana kadar kullanılamaz ancak hizmet çalışanı, aramanın ertelenmesine ve cihaz arka plan senkronizasyonu API'sini kullanarak tekrar çevrimiçi olduğunda Google'ın sunucularına gönderilmesine olanak tanır.
Daha akıllı JavaScript önbelleğe alma ve sunma
Bir diğer motivasyon ise arama sonuçları sayfasındaki çeşitli özelliklere güç veren modüler JavaScript kodunun önbelleğe alınmasını ve yüklenmesini optimize etmekti. JavaScript paketleme, hizmet çalışanı kullanılmadığında mantıklı olan bir dizi avantaj sunar. Bu nedenle, Arama Ekibi paketlemeyi tamamen durdurmak istemedi.
Arama Ekibi, bir hizmet çalışanının çalışma zamanında ayrıntılı JavaScript parçalarını sürüm oluşturma ve önbelleğe alma özelliğini kullanarak önbellek karmaşası miktarını azaltabileceklerini ve gelecekte yeniden kullanılan JavaScript'in verimli bir şekilde önbelleğe alınmasını sağlayabileceklerini düşünüyordu. Hizmet çalışanlarını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ü bir araya getirerek isteği karşılayabilir. Bu sayede, mümkün olduğunda etkili bir şekilde "paket açma" işlemi gerçekleştirilir. Bu sayede kullanıcı bant genişliği tasarrufu sağlanır ve genel yanıt verme durumu iyileştirilir.
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, bu JavaScript'in ayrıştırılmış, bayt kodu gösterimi depolanır ve yeniden kullanılır. Bu da sayfadaki JavaScript'in yürütülmesi için çalışma zamanında yapılması gereken işin azalmasını sağlar.
Zorluklar ve çözümler
Ekibin belirttiği hedeflere ulaşmak için aşılması gereken engellerden bazılarını aşağıda bulabilirsiniz. Bu zorluklardan bazıları Google Arama'ya özgü olsa da çoğu, hizmet çalışanı dağıtmayı düşünen çok çeşitli siteler için geçerlidir.
Sorun: Hizmet çalışanı ek yükü
Google Arama'da bir hizmet çalışanı başlatmanın önündeki en büyük engel, hizmet çalışanının 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ı popülasyonu için on milisaniyelik ek gecikmeye bile neden olan yeni işlevlerin kullanıma sunulmasını engellemiştir.
Ekip, ilk denemeleri sırasında performans verilerini toplamaya başladığında bir sorun olacağı açıkça görülüyordu. Arama sonuçları 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şir. Şu anda hizmet çalışanının bu mantığı kopyalayıp önbelleğe alınmış HTML'yi hemen döndürmesinin bir yolu yoktur. Yapabileceği en iyi şey, gezinme isteklerini arka uç web sunucularına iletmektir. Bu da bir ağ isteği gerektirir.
Service worker olmadan bu ağ isteği, kullanıcı gezinir gezinmez gerçekleşir. Bir hizmet çalışanı kaydedildiğinde, ağa gitmek dışında herhangi bir işlem yapma ihtimali olmasa bile her zaman başlatılması ve fetch etkinlik işleyicilerini yürütme fırsatı verilmesi gerekir. Service worker kodunun başlatılması ve çalıştırılması için gereken süre, her gezinmeye eklenen tamamen gereksiz bir yüktür:
Bu durum, hizmet çalışanı uygulamasının diğer avantajları haklı çıkaramayacak kadar fazla gecikme dezavantajına sahip olmasına neden olur. Ayrıca ekip, gerçek dünyadaki cihazlarda hizmet çalışanı başlatma sürelerini ölçerek, başlatma sürelerinin geniş bir dağılım gösterdiğini tespit etti. Bazı düşük seviyeli mobil cihazlarda hizmet çalışanını başlatmak, sonuç sayfasının HTML'si için ağ isteğinde bulunmak kadar uzun sürüyordu.
Çözüm: Navigasyon önceden yüklemesini kullanın
Google Arama Ekibi'nin hizmet çalışanı lansmanına devam etmesini sağlayan en önemli özellik gezinme önceden yüklemedir. Gezinme önceden yüklemesini kullanmak, gezinme isteklerini karşılamak için ağdan gelen bir yanıtı kullanması gereken tüm hizmet çalışanları için önemli bir performans avantajıdır. Tarayıcıya, gezinme isteğini Service Worker başlatılırken aynı anda hemen yapmaya başlaması için bir ipucu verir:
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'dan kaynaklanan herhangi bir gecikme olmaz.
Arama Ekibi, hizmet çalışanı başlatma süresinin gezinme isteğini aşabileceği düşük seviyeli mobil cihazlarda hizmet çalışanı kullanmaktan da kaçınmalıydı. "Düşük seviye " cihazların ne olduğuyla ilgili kesin bir kural olmadığından, cihazda yüklü olan toplam RAM'i kontrol etme sezgisel yöntemini geliştirdiler. 2 gigabaytın altındaki bellekler, hizmet çalışanı başlatma süresinin kabul edilemez olduğu düşük seviye cihaz kategorisine giriyordu.
Gelecekte kullanılmak üzere önbelleğe alınacak kaynakların tamamı birkaç megabayt yer kaplayabileceğ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 riski taşıyıp taşımadığını önceden belirlemesine olanak tanır.
Bu durum, Arama Ekibi'nin bir hizmet çalışanı kullanıp kullanmayacağını belirlemek için kullanabileceği birden fazla ölçütle sonuçlandı: Bir kullanıcı, Google Arama sayfasına gezinme ön yüklemesini destekleyen bir tarayıcı kullanarak gelirse ve en az 2 GB RAM'e ve yeterli boş depolama alanına sahipse hizmet çalışanı kaydedilir. Bu ölçütleri karşılamayan tarayıcılar veya cihazlarda hizmet çalışanı bulunmaz ancak bu tarayıcılar ve cihazlar, her zaman olduğu gibi aynı Google Arama deneyimini sunmaya devam eder.
Bu seçici kaydın bir avantajı da daha küçük ve daha verimli bir hizmet çalışanı gönderebilmektir. Hizmet çalışanı kodunu çalıştırmak için oldukça modern tarayıcıları hedeflemek, eski tarayıcılar için derleme ve çoklu doldurma ek yükünü ortadan kaldırır. Bu sayede, hizmet çalışanı 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 sayıda gecikme denemesi yaptıktan ve gezinme önceden yüklemenin, hizmet çalışanı kullanmak için gecikme açısından nötr ve uygulanabilir bir yol sunduğundan emin olduktan sonra bazı pratik sorunlar ön plana çıkmaya başladı. Bu sorunlardan biri, hizmet çalışanının kapsam kurallarıyla ilgilidir. Bir hizmet çalışanının kapsamı, hangi sayfaları kontrol edebileceğini belirler.
Kapsam belirleme, URL yolu önekine göre çalışır. Tek bir web uygulaması barındıran alanlarda bu bir sorun değildir. Çünkü normalde yalnızca / kapsamının en geniş olduğu bir hizmet çalışanı kullanırsınız. Bu hizmet çalışanı, alan altındaki herhangi bir sayfayı kontrol edebilir.
Ancak Google Arama'nın URL yapısı biraz daha karmaşıktır.
Hizmet çalışanı / maksimum kapsamına sahip olsaydı www.google.com (veya bölgesel eşdeğeri) altında barındırılan tüm sayfaların kontrolünü ele geçirebilirdi. Bu alan adında Google Arama ile ilgisi olmayan URL'ler de var. Daha makul ve kısıtlayıcı bir kapsam /search olabilir. Bu kapsam, arama sonuçlarıyla tamamen alakasız URL'leri en azından ortadan kaldırır.
Maalesef, /search URL yolu bile farklı Google Arama sonuçları arasında paylaşılıyor. Hangi arama sonucu türünün gösterileceğini ise URL sorgu parametreleri belirliyor. Bu sürümlerden bazıları, geleneksel web arama sonucu sayfasından tamamen farklı kod tabanları kullanır. Örneğin, Görsel Arama ve Alışveriş Arama, farklı sorgu parametreleriyle /search URL yolu altında sunulur ancak bu arayüzlerin hiçbiri kendi hizmet çalışanı deneyimini kullanıma sunmaya hazır değildir (henüz).
Çözüm: Gönderme ve yönlendirme çerçevesi oluşturun
Hizmet çalışanı kapsamlarını belirlemek için URL yolu öneklerinden daha güçlü bir yönteme 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 zorlanıyordu.
Google Arama ekibi bu sorunu çözmek için, istemci sayfasının sorgu parametreleri gibi ölçütleri kontrol edecek ve hangi belirli kod yolunun izleneceğini belirlemek için bunları kullanacak şekilde yapılandırılabilen özel bir gönderme ve yönlendirme çerçevesi oluşturdu. Sistem, kuralları sabit kodlamak yerine esnek olacak ve URL alanını paylaşan ekiplerin (ör. Görsel Arama ve Alışveriş Arama) kendi hizmet çalışanı mantıklarını daha sonra uygulamaya karar vermeleri durumunda eklemelerine olanak tanıyacak şekilde oluşturuldu.
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, hesap verilerine göre özelleştirilebilir. Oturum açmış kullanıcılar, köklü ve yaygın olarak desteklenen bir standart olan belirli tarayıcı çerezleriyle tanımlanır.
Ancak tarayıcı çerezlerinin kullanılmasının bir dezavantajı, hizmet çalışanının içinde kullanılamaması ve değerlerinin otomatik olarak incelenip kullanıcının oturumu kapatması veya hesap değiştirmesi nedeniyle değişmediğinden emin olmanın mümkün olmamasıdır. (Çerez erişimini hizmet çalışanlarına getirmek için çalışmalar devam etmektedir ancak bu yazı itibarıyla yaklaşım deneyseldir ve yaygın olarak desteklenmemektedir.)
Service worker'ın, oturum açmış mevcut kullanıcı görünümü ile Google Arama web arayüzünde oturum açmış gerçek kullanıcı arasında uyuşmazlık olması, arama sonuçlarının yanlış şekilde kişiselleştirilmesine veya metriklerin ve günlük kaydının yanlış ilişkilendirilmesine neden olabilir. Bu hata senaryolarından herhangi biri, Google Arama Ekibi için ciddi bir sorun teşkil eder.
Çözüm: Çerezleri postMessage kullanarak gönderin
Google Arama ekibi, deneysel API'lerin kullanıma sunulmasını ve hizmet çalışanı içindeki tarayıcı çerezlerine doğrudan erişim sağlamasını beklemek yerine geçici bir çözüm kullanmayı tercih etti: Hizmet çalışanı 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() kullanır.
Ardından hizmet çalışanı, mevcut çerez değerini beklediği değerle karşılaştırır ve bir uyuşmazlık varsa depolama alanındaki kullanıcıya özel verileri temizlemek için adımlar atar ve arama sonuçları sayfasını yanlış kişiselleştirme olmadan yeniden yükler.
Service worker'ın her şeyi temel duruma sıfırlamak için attığı adımlar Google Arama'nın şartlarına özeldir ancak aynı genel yaklaşım, tarayıcı çerezleriyle anahtarlanmış kişiselleştirilmiş verilerle uğraşan diğer geliştiriciler için de faydalı olabilir.
Sorun: Denemeler ve dinamizm
Belirtildiği gibi, Google Arama Ekibi, üretimde deneyler yapmaya ve yeni kod ile özelliklerin etkilerini varsayılan olarak etkinleştirmeden önce gerçek dünyada test etmeye büyük önem verir. Kullanıcıları denemelere dahil etmek ve denemelerden çıkarmak genellikle arka uç sunucuyla iletişimi gerektirdiğinden, önbelleğe alınmış verilere büyük ölçüde dayanan statik bir servis çalışanıyla bu durum biraz zor olabilir.
Çözüm: Dinamik olarak oluşturulmuş hizmet çalışanı komut dosyası
Ekibin tercih ettiği çö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şturulan bir hizmet çalışanı komut dosyası kullanmaktı. Service worker'ın davranışını veya genel olarak ağ isteklerini etkileyebilecek denemelerle ilgili bilgiler doğrudan bu özelleştirilmiş service worker komut dosyalarına dahil edilir. Bir kullanıcının etkin deneyim kümelerini değiştirmek için tarayıcı çerezleri gibi geleneksel tekniklerin yanı sıra kayıtlı hizmet çalışanı URL'sinde güncellenmiş kod sunma gibi yöntemler kullanılır.
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 nadir durumlarda çıkış yolu sağlamayı da kolaylaştırır. Dinamik hizmet çalışanı yanıtı, işlem yapmayan bir uygulama olabilir ve bu da hizmet çalışanını mevcut kullanıcıların bir kısmı veya tamamı için devre dışı bırakır.
Sorun: Güncellemeleri koordine etme
Gerçek dünyadaki herhangi bir hizmet çalışanı dağıtımının karşılaştığı en zorlu zorluklardan biri, ağdan kaçınarak önbelleği tercih etme ile mevcut kullanıcıların kritik güncellemeleri ve değişiklikleri üretime dağıtıldıktan kısa süre sonra almasını sağlama arasında makul bir denge kurmaktır. Doğru denge birçok faktöre bağlıdır:
- Web uygulamanız, kullanıcının yeni sayfalara gitmeden süresiz olarak açık tuttuğu uzun ömürlü bir tek sayfa uygulaması mı?
- Arka uç web sunucunuzdaki güncellemelerin dağıtım sıklığı.
- Ortalama kullanıcının web uygulamanızın biraz eski bir sürümünü kullanmaya tahammül edip etmeyeceği veya güncelliğin en önemli öncelik olup olmadığı.
Google Arama Ekibi, servis çalışanlarıyla ilgili 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 denemelerin bir dizi planlanmış arka uç güncellemesi boyunca çalışmaya devam etmesini sağladı.
Çözüm: Yenilik ile önbellek kullanımını dengeleyin
Google Arama ekibi, çeşitli yapılandırma seçeneklerini test ettikten sonra aşağıdaki kurulumun güncellik ve önbellek 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 üstbilgisiyle sunulur ve üstbilginin dikkate alınması 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 kümesidir. Hizmet çalışanı komut dosyasının içeriğini etkileyecek bir değişikliğin dağıtımı kademeli olarak yapılır.
Bir kullanıcı, güncellenmiş bir arka uca erişir ve ardından güncellenmiş hizmet çalışanını henüz almamış bir arka uca erişen başka bir sayfaya hızlıca giderse sürümler arasında birden çok kez geçiş yapar. Bu nedenle, tarayıcıya yalnızca son kontrolden bu yana 25 dakika geçtiyse güncellenmiş bir komut dosyası olup olmadığını kontrol etmesini söylemenin önemli bir dezavantajı yoktur. Bu davranışı etkinleştirmenin avantajı, hizmet çalışanı komut dosyasını dinamik olarak oluşturan uç nokta tarafından alınan trafiği önemli ölçüde azaltmaktır.
Ayrıca, hizmet çalışanı komut dosyasının HTTP yanıtına bir ETag başlığı ayarlanır. Bu sayede, 25 dakika geçtikten sonra güncelleme kontrolü yapıldığında, bu süre zarfında dağıtılan hizmet çalışanında herhangi bir güncelleme yapılmamışsa sunucu HTTP 304 yanıtıyla verimli bir şekilde yanıt verebilir.
Google Arama web uygulamasındaki bazı etkileşimlerde tek sayfalık uygulama tarzı gezinmeler (ör. History API aracılığıyla) kullanılsa da Google Arama, büyük ölçüde "gerçek" gezinmelerin kullanıldığı 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ği kullanmanın etkili olacağına karar verdiğinde devreye girer:
clients.claim()<0x0x0A>ve
skipWaiting().
Google Arama'nın arayüzünde gezinmek genellikle yeni HTML dokümanlarına yönlendirmeyle sonuçlanır. skipWaiting çağrısı, güncellenen bir hizmet çalışanının yüklemeden hemen sonra bu yeni gezinme isteklerini işleme şansı elde etmesini sağlar. Benzer şekilde, clients.claim() işlevinin çağrılması, güncellenen hizmet çalışanının, hizmet çalışanı etkinleştirildikten sonra denetlenmeyen açık Google Arama sayfalarını denetlemeye başlamasına olanak tanır.
Google Arama'nın kullandığı yaklaşım, herkes için geçerli bir çözüm olmayabilir. Bu yaklaşım, kendileri için en iyi sonucu veren yöntemi bulana kadar çeşitli yayınlama seçeneklerinin dikkatli bir şekilde A/B testine tabi tutulmasıyla elde edilmiştir.
Arka uç altyapısı, 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ı için 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 oluşturuyorsanız skipWaiting() kullanmak sizin için doğru seçim olmayabilir. Uzun süreli istemciler varken yeni hizmet çalışanının etkinleştirilmesine izin verirseniz önbellek tutarsızlıklarıyla karşılaşma riskiniz vardır.
Temel çıkarımlar
Varsayılan olarak, hizmet çalışanları performans açısından tarafsız değildir.
Web uygulamanıza bir 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 gelirse hizmet çalışanını çalıştırmanın ek yükü, genellikle önbellek öncelikli yaklaşımın performans açısından sağladığı avantajla karşılaştırıldığında ihmal edilebilir düzeydedir. Ancak hizmet çalışanınızın gezinme isteklerini işlerken her zaman ağa danışması gerektiğini biliyorsanız gezinme ön yüklemesini kullanmak önemli bir performans avantajı sağlar.
Service worker'lar (hâlâ!) aşamalı iyileştirme olarak kabul edilir.
Service worker desteği, bir yıl öncesine kıyasla çok daha iyi durumda. Tüm modern tarayıcılar artık en azından hizmet çalışanı desteği sunuyor ancak maalesef arka planda senkronizasyon ve önceden yükleme gibi bazı gelişmiş hizmet çalışanı özellikleri evrensel olarak kullanıma sunulmuyor. İhtiyacınız olduğunu bildiğiniz özelliklerin belirli bir alt kümesi için özellik kontrolü yapıp yalnızca bu özellikler mevcut olduğunda bir hizmet çalışanı kaydetmek hâlâ makul bir yaklaşımdır.
Benzer şekilde, gerçek hayatta denemeler yaptıysanız ve düşük seviyeli cihazların, bir service worker'ın ek yüküyle kötü performans gösterdiğini biliyorsanız bu senaryolarda service worker kaydetmekten de kaçınabilirsiniz.
Hizmet çalışanlarını, tüm ön koşullar karşılandığında web uygulamasına eklenen ve kullanıcı deneyimine ve genel yükleme performansına olumlu bir katkı sağlayan bir ilerleyici geliştirme olarak değerlendirmeye devam etmelisiniz.
Her şeyi ölçün
Bir hizmet çalışanı göndermenin kullanıcılarınızın deneyimleri üzerinde olumlu mu yoksa olumsuz mu bir etkisi olduğunu anlamanın tek yolu deneme yapmak ve sonuçları ölçmektir.
Anlamlı ölçümler ayarlamayla ilgili ayrıntılar, kullandığınız analiz sağlayıcıya ve dağıtım kurulumunuzda denemeleri normalde nasıl yürüttüğünüze bağlıdır. Google Analytics'i kullanarak metrik toplama yaklaşımı, Google I/O web uygulamasında hizmet çalışanlarının kullanımına dayalı 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 ekibin ilk hedefi "Google Arama PWA" oluşturmak değildi. Google Arama web uygulaması, web uygulaması manifestinde meta veri sağlamıyor ve kullanıcıları ana ekrana ekleme akışını kullanmaya teşvik etmiyor. Arama ekibi, kullanıcıların Google Arama'nın klasik giriş noktalarını kullanarak web uygulamalarına gelmesinden memnun.
Google Arama web deneyimini, yüklü bir uygulamadan bekleyeceğiniz deneyime dönüştürmeye çalışmak yerine, ilk sürümde mevcut web sitesini kademeli olarak iyileştirmeye odaklanıldı.
Teşekkür
Service worker uygulamasıyla ilgili çalışmaları ve bu yazının yazılmasında kullanılan arka plan materyallerini paylaştıkları için Google Arama'nın tüm web geliştirme ekibine teşekkür ederiz. 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 yayınlandığından beri 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'nın web altyapısı geliştikçe ekip, hizmet çalışanı tasarımını yeniden gözden geçirebilir.