Hizmet çalışanlarının (en azından performans açısından) en önemli avantajlarından biri, öğelerin önbelleğe alınmasını proaktif olarak kontrol edebilmeleridir. Gerekli tüm kaynaklarını önbelleğe alabilen bir web uygulaması, geri gelen ziyaretçiler için önemli ölçüde daha hızlı yüklenmelidir. Peki bu kazançlar gerçek kullanıcılara gerçekte nasıl görünüyor? Bunu nasıl ölçüyorsunuz?
Google I/O web uygulaması (kısaca IOWA), kullanıcılarına uygulama benzeri zengin bir deneyim sunmak için hizmet çalışanlarının sunduğu yeni özelliklerin çoğunu kullanan progresif web uygulamasıdır. Ayrıca, geniş ve çeşitli kullanıcı kitlesinden önemli performans verilerini ve kullanım kalıplarını toplamak için Google Analytics'i kullandı.
Bu örnek olay incelemesinde, IOWA'nın önemli performans sorularını yanıtlamak ve hizmet çalışanlarının gerçek dünyadaki etkisi hakkında rapor oluşturmak için Google Analytics'i nasıl kullandığı incelenmektedir.
Sorularla başlayın
Bir web sitesi veya uygulamaya her analiz ekleyişinizde, topladığınız verilerden yanıtlamaya çalıştığınız soruları belirleyerek işe başlamanız önemlidir.
Cevaplamak istediğimiz birkaç soru olsa da bu örnek olay incelemesi için daha ilginç olan iki tanesine odaklanalım.
1. Service Worker'ın önbelleğe alma işlemi, tüm tarayıcılarda mevcut olan HTTP önbelleğe alma mekanizmalarından daha mı yüksek?
Tarayıcılar istekleri önbelleğe alıp yinelenen ziyaretlerde anında sunabildiği için, geri gelen ziyaretçiler için sayfaların yeni ziyaretçilere göre daha hızlı yüklenmesini bekliyoruz.
Service Worker'lar, geliştiricilere önbelleğe alma işleminin tam olarak ne ve nasıl yapıldığı üzerinde ayrıntılı kontrol sağlayan alternatif önbelleğe alma özellikleri sunar. IOWA'da hizmet çalışanı uygulamamızı, her öğenin önbelleğe alınacağı ve geri gelen ziyaretçilerin uygulamayı tamamen çevrimdışı kullanabileceği şekilde optimize ettik.
Peki bu çaba, tarayıcının varsayılan olarak zaten yaptığından daha iyi olabilir mi? Varsa ne kadar daha iyi? 1
2. Service Worker, site yükleme deneyimini nasıl etkiler?
Başka bir deyişle, geleneksel sayfa yükleme metrikleriyle ölçülen gerçek yükleme sürelerinden bağımsız olarak, sitenin yükleniyormuş gibi hissettiği hız ne?
Bir deneyimin nasıl hissettireceğine ilişkin soruları yanıtlamak elbette kolay bir iş değildir ve hiçbir metrik bu kadar öznel bir duyguyu mükemmel şekilde temsil edemez. Bununla birlikte, kesinlikle diğerlerinden daha iyi olan bazı metrikler vardır, bu nedenle doğru metrikleri seçmek önemlidir.
Doğru metriği seçme
Google Analytics, varsayılan olarak, bir site ziyaretçilerinin% 1'i için sayfa yükleme sürelerini (Gezinme Zamanlaması API'si aracılığıyla) izler ve bu verileri Ort. Sayfa Yükleme Süresi gibi metrikler aracılığıyla kullanıma sunar.
Ort. Sayfa Yükleme Süresi ilk sorumuzu yanıtlamak için iyi bir metrik olsa da ikinci sorumuzu yanıtlamak için de iyi bir metrik değildir. Örneğin, load etkinliği kullanıcının gerçekten uygulamayla etkileşimde bulunabileceği ana karşılık gelmeyebilir. Ayrıca, tam olarak aynı yükleme süresine sahip iki uygulama çok farklı şekilde yüklenmiş gibi hissetebilir. Örneğin, başlangıç ekranı veya yükleme göstergesi olan bir site, birkaç saniye boyunca boş sayfa gösteren bir siteden çok daha hızlı yükleniyormuş gibi hissedebilir.
IOWA'da, uygulamanın geri kalanı arka planda yüklenirken kullanıcıyı eğlendirmek için (bence) oldukça başarılı bir şekilde sunulan bir başlangıç ekranı geri sayım animasyonu gösterdik. Bu nedenle, algılanan yük performansını ölçmenin bir yolu olarak, başlangıç ekranının ne kadar sürede gösterildiğini izlemek çok daha mantıklıdır. Bu değeri elde etmek için ilk boyama süresi metriğini seçtik.
Cevaplamak istediğimiz sorulara karar verip cevaplamamıza yardımcı olacak metrikleri belirledikten sonra, Google Analytics'i uygulayıp ölçüme başlamanın zamanı gelmişti.
Analytics'in uygulanması
Daha önce Google Analytics'i kullandıysanız önerilen JavaScript izleme snippet'ini büyük olasılıkla biliyorsunuzdur. Aşağıdaki gibi görünür:
<script>
window.ga=window.ga||function(){(ga.q=ga.q||[]).push(arguments)};ga.l=+new Date;
ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');
</script>
<script async src="https://www.google-analytics.com/analytics.js"></script>
Yukarıdaki kodun ilk satırı genel bir ga() işlevini başlatır (zaten yoksa) ve son satır eşzamansız olarak analytics.js kitaplığını indirir.
Orta kısımda şu iki satır bulunur:
ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');
Bu iki komut, sitenize giden kullanıcıların hangi sayfaları ziyaret ettiğini izler, ancak daha fazlasını izlemez. Diğer kullanıcı etkileşimlerini izlemek istiyorsanız bunu kendiniz yapmanız gerekir.
IOWA için iki öğeyi daha izlemek istedik:
- Sayfanın ilk yüklenmeye başlaması ile piksellerin ekranda görünmesi arasında geçen süre.
- Sayfayı bir Service Worker'ın kontrol edip etmediği. Bu bilgiler sayesinde raporlarımızı segmentlere ayırarak sonuçları Service Worker'lar ile birlikte ve bunlar olmadan karşılaştırabiliriz.
İlk boyama zamanı yakalanıyor
Bazı tarayıcılar, ilk pikselin ekrana boyandığı zamanı tam olarak kaydeder ve bu zamanı geliştiricilere sunar. Bu değer, Gezinme Zamanlaması API'sı aracılığıyla gösterilen navigationStart değeriyle karşılaştırıldığında, kullanıcının sayfayı ilk kez istediği an ile ilk kez bir şeyi gördüğü an arasında ne kadar sürenin geçtiğini bize oldukça doğru bir şekilde hesaplar.
Daha önce de belirttiğim gibi, ilk boyama süresi ölçülmesi gereken önemli bir metriktir çünkü kullanıcının sitenizin yükleme hızını ilk kez algıladığı noktadır. Kullanıcıların aldığı ilk izlenimdir. İyi bir ilk izlenim, kullanıcı deneyiminin geri kalanını olumlu yönde etkileyebilir.2
Bunu kullanıma sunan tarayıcılarda ilk boyama değerini elde etmek için getTimeToFirstPaintIfSupported yardımcı program işlevini oluşturduk:
function getTimeToFirstPaintIfSupported() {
// Ignores browsers that don't support the Performance Timing API.
if (window.performance && window.performance.timing) {
var navTiming = window.performance.timing;
var navStart = navTiming.navigationStart;
var fpTime;
// If chrome, get first paint time from `chrome.loadTimes`.
if (window.chrome && window.chrome.loadTimes) {
fpTime = window.chrome.loadTimes().firstPaintTime * 1000;
}
// If IE/Edge, use the prefixed `msFirstPaint` property.
// See http://msdn.microsoft.com/ff974719
else if (navTiming.msFirstPaint) {
fpTime = navTiming.msFirstPaint;
}
if (fpTime && navStart) {
return fpTime - navStart;
}
}
}
Bununla birlikte, non-interaction etkinliği gönderen başka bir işlev yazabiliriz. Bu etkinlik, değeri olarak ilk boyama zamanının belirtildiği bir zamanı belirtir:3
function sendTimeToFirstPaint() {
var timeToFirstPaint = getTimeToFirstPaintIfSupported();
if (timeToFirstPaint) {
ga('send', 'event', {
eventCategory: 'Performance',
eventAction: 'firstpaint',
// Rounds to the nearest millisecond since
// event values in Google Analytics must be integers.
eventValue: Math.round(timeToFirstPaint)
// Sends this as a non-interaction event,
// so it doesn't affect bounce rate.
nonInteraction: true
});
}
}
Bu fonksiyonların her ikisini de yazdıktan sonra izleme kodumuz aşağıdaki gibi görünür:
// Creates the tracker object.
ga('create', 'UA-XXXXX-Y', 'auto');
// Sends a pageview for the initial pageload.
ga('send', 'pageview');
// Sends an event with the time to first paint data.
sendTimeToFirstPaint();
Yukarıdaki kodun çalışma zamanına bağlı olarak, piksellerin ekrana boyanmış olup olmadığını unutmayın. İlk boyama işleminden sonra bu kodu çalıştırdığımızdan emin olmak için sendTimeToFirstPaint() çağrısını load etkinliğinden sonrasına erteledik. Aslında, bu isteklerin diğer kaynakların yüklenmesiyle rekabet etmediğinden emin olmak için tüm analiz verilerinin gönderimini sayfa yüklenene kadar ertelemeye karar verdik.
// Creates the tracker object.
ga('create', 'UA-XXXXX-Y', 'auto');
// Postpones sending any hits until after the page has fully loaded.
// This prevents analytics requests from delaying the loading of the page.
window.addEventListener('load', function() {
// Sends a pageview for the initial pageload.
ga('send', 'pageview');
// Sends an event with the time to first paint data.
sendTimeToFirstPaint();
});
Yukarıdaki kod, Google Analytics'e firstpaint kez bildirimde bulunur, ancak bu, hikayenin yalnızca yarısıdır. Service Worker'ın durumunu yine de izlememiz gerekiyordu. Aksi takdirde, Service Worker tarafından kontrol edilen bir sayfa ile kontrol edilmeyen bir sayfanın ilk boyama zamanlarını karşılaştıramayız.
Service Worker durumu belirleniyor
Service Worker'ın mevcut durumunu belirlemek için şu üç değerden birini döndüren bir yardımcı program işlevi oluşturduk:
- controlled: Sayfayı bir hizmet çalışanı kontrol eder. IOWA durumunda bu, aynı zamanda tüm öğelerin önbelleğe alındığı ve sayfanın çevrimdışı çalıştığı anlamına gelir.
- supported: Tarayıcı, Service Worker'ı destekler ancak Service Worker henüz sayfayı kontrol etmez. Bu, ilk kez gelen ziyaretçiler için beklenen durumdur.
- unsupported: Kullanıcının tarayıcısı Service Worker'ı desteklemez.
function getServiceWorkerStatus() {
if ('serviceWorker' in navigator) {
return navigator.serviceWorker.controller ? 'controlled' : 'supported';
} else {
return 'unsupported';
}
}
Bu işlev bizim için hizmet çalışanı durumunu aldı. Bir sonraki adım, bu durumu Google Analytics'e gönderdiğimiz verilerle ilişkilendirmekti.
Özel verileri özel boyutlarla izleme
Varsayılan olarak Google Analytics, toplam trafiğinizi kullanıcı, oturum veya etkileşim özelliklerine göre gruplara ayırmak için birçok yöntem sunar. Bu özellikler boyutlar olarak bilinir. Web geliştiricilerinin en çok önem verdiği boyutlar Tarayıcı, İşletim Sistemi veya Cihaz Kategorisi'dir.
Hizmet çalışanı durumu, Google Analytics'in varsayılan olarak sağladığı bir boyut değildir. Ancak Google Analytics, kendi özel boyutlarınızı oluşturmanıza ve istediğiniz gibi tanımlamanıza olanak tanır.
IOWA için Hizmet Çalışanı Durumu adlı bir özel boyut oluşturduk ve kapsamını isabet (yani etkileşim başına) olarak ayarladık.4 Google Analytics'te oluşturduğunuz her özel boyuta, ilgili mülk içinde benzersiz bir dizin verilir ve izleme kodunuzda, bu boyuta diziniyle referans verebilirsiniz. Örneğin, az önce oluşturduğumuz boyutun dizini 1 ise firstpaint etkinliğini, Service Worker durumunu içerecek şekilde göndermek için mantığımızı aşağıdaki gibi güncelleyebiliriz:
ga('send', 'event', {
eventCategory: 'Performance',
eventAction: 'firstpaint',
// Rounds to the nearest millisecond since
// event values in Google Analytics must be integers.
eventValue: Math.round(timeToFirstPaint)
// Sends this as a non-interaction event,
// so it doesn't affect bounce rate.
nonInteraction: true,
// Sets the current service worker status as the value of
// `dimension1` for this event.
dimension1: getServiceWorkerStatus()
});
Bu işlem işe yarar ancak hizmet çalışanının durumunu yalnızca bu belirli etkinlikle ilişkilendirir. Hizmet Çalışanı Durumu herhangi bir etkileşim için bilinmesi yararlı olabilecek bir bilgi olduğundan, bu durumu Google Analytics'e gönderilen tüm verilere eklemek en iyisidir.
Bu bilgileri tüm isabetlere (ör. tüm sayfa görüntülemeleri, etkinlikler vb.) eklemek için, herhangi bir veriyi Google Analytics'e göndermeden önce izleyici nesnesinin kendisinde özel boyut değerini ayarız.
ga('set', 'dimension1', getServiceWorkerStatus());
Bu değer ayarlandıktan sonra, geçerli sayfa yüklemesi için sonraki tüm isabetlerle birlikte gönderilir. Kullanıcı sayfayı daha sonra tekrar yüklerse büyük olasılıkla getServiceWorkerStatus() işlevinden yeni bir değer döndürülür ve bu değer izleyici nesnesinde ayarlanır.
Kodun anlaşılırlığı ve okunabilirliğiyle ilgili kısa bir not: Bu kodu inceleyen diğer kullanıcılar dimension1 teriminin ne anlama geldiğini bilmeyebilir. Bu nedenle, anlamlı boyut adlarını analytics.js'nin kullanacağı değerlerle eşleştiren bir değişken oluşturmak her zaman en iyi seçenektir.
// Creates a map between custom dimension names and their index.
// This is particularly useful if you define lots of custom dimensions.
var customDimensions = {
SERVICE_WORKER_STATUS: 'dimension1'
};
// Creates the tracker object.
ga('create', 'UA-XXXXX-Y', 'auto');
// Sets the service worker status on the tracker,
// so its value is included in all future hits.
ga('set', customDimensions.SERVICE_WORKER_STATUS, getServiceWorkerStatus());
// Postpones sending any hits until after the page has fully loaded.
// This prevents analytics requests from delaying the loading of the page.
window.addEventListener('load', function() {
// Sends a pageview for the initial pageload.
ga('send', 'pageview');
// Sends an event with the time to first paint data.
sendTimeToFirstPaint();
});
Daha önce belirttiğim gibi, her isabetle birlikte Hizmet Çalışanı Durumu boyutunu göndermek, herhangi bir metrik için rapor oluştururken bu boyutu kullanmamızı sağlar.
Görebileceğiniz gibi, IOWA için tüm sayfa görüntülemelerinin neredeyse% 85'i Service Worker'ı destekleyen tarayıcılardan gelir.
Sonuçlar: Sorularımızın yanıtlanması
Sorularımızı yanıtlamak üzere veri toplamaya başladıktan sonra sonuçları görmek için bu verilerle ilgili rapor oluşturabiliriz. (Not: Burada gösterilen tüm Google Analytics verileri, 16-22 Mayıs 2016 tarihleri arasında IOWA sitesine giden gerçek web trafiğini temsil eder).
İlk sorduğumuz soru şuydu: Service Worker önbelleğe alma işlemi, tüm tarayıcılarda mevcut olan HTTP önbelleğe alma mekanizmalarından daha mı yüksek?
Bu soruyu yanıtlamak için, çeşitli boyutlardaki Ort. Sayfa Yükleme Süreleri metriğini inceleyen özel rapor oluşturduk. load etkinliği yalnızca ilk kaynaklar indirildikten sonra etkinleştiğinden bu metrik, bu soruyu yanıtlamak için uygundur. Böylece, sitenin tüm kritik kaynakları için toplam yükleme süresini doğrudan yansıtır.5
Seçtiğimiz boyutlar:
- Özel Hizmet Çalışanı Durumu boyutumuz.
- Kullanıcı Türü, kullanıcının siteye yaptığı ilk ziyaret mi yoksa geri mi geldiğini gösterir. (Not: Yeni bir ziyaretçinin önbelleğe alınmış herhangi bir kaynağı olmaz; geri gelen bir ziyaretçi önbelleğe alabilir.)
- Mobil ve masaüstünde sonuçları karşılaştırmamızı sağlayan Cihaz Kategorisi.
Hizmet çalışanlarıyla ilgili olmayan faktörlerin yükleme süresi sonuçlarımızı çarpıtma olasılığını kontrol etmek için sorgumuzu yalnızca Service Worker'ları destekleyen tarayıcıları içerecek şekilde sınırlandırdık.
Gördüğünüz gibi, hizmet çalışanı tarafından kontrol edilen uygulamamıza yapılan ziyaretler, sayfa kaynaklarının çoğunu önbelleğe almış olan geri gelen kullanıcılar dahil olmak üzere, kontrol edilemeyen ziyaretlere göre oldukça hızlı yükleniyor. Ortalama olarak, bir hizmet çalışanı bulunan mobil cihaz kullanan ziyaretçilerin, masaüstü bilgisayarlarından yeni ziyaretçilere göre daha hızlı yükleme elde ettiklerini fark etmek de ilginçtir.
"...hizmet çalışanı tarafından kontrol edilen uygulamamıza yapılan ziyaretler, kontrolsüz ziyaretlere göre oldukça hızlı yükleniyor..."
Aşağıdaki iki tabloda daha fazla ayrıntı bulabilirsiniz:
| Ort. Sayfa Yükleme Süresi (Masaüstü) | |||
|---|---|---|---|
| Hizmet Çalışanı Durumu | Kullanıcı Türü | Ort. Sayfa Yükleme Süresi (ms) | Örnek Boyutu |
| Kontrol etti | Geri Gelen Ziyaretçi | 2568 | 30860 |
| Destekleniyor | Geri Gelen Ziyaretçi | 3612 | 1289 |
| Destekleniyor | Yeni Ziyaretçi | 4664 | 21991 |
| Ort. Sayfa Yükleme Süresi (Mobil) | |||
|---|---|---|---|
| Hizmet Çalışanı Durumu | Kullanıcı Türü | Ort. Sayfa Yükleme Süresi (ms) | Örnek Boyutu |
| Kontrol etti | Geri Gelen Ziyaretçi | 3760 | 8162 |
| Destekleniyor | Geri Gelen Ziyaretçi | 4843 | 676 |
| Destekleniyor | Yeni Ziyaretçi | 6158 | 5779 |
Tarayıcısı Service Worker'ı destekleyen bir geri gelen ziyaretçinin kontrolsüz bir durumda olmasının nasıl mümkün olduğunu merak ediyor olabilirsiniz. Bunun birkaç olası açıklaması vardır:
- Kullanıcı, hizmet çalışanı ilk kullanıma hazırlama işlemini tamamlamadan önce ilk ziyarette sayfadan ayrıldı.
- Kullanıcı, geliştirici araçları üzerinden Service Worker'ı kaldırdı.
Bu durumların ikisi de nadiren görülür. Verilerde bu durumu, dördüncü sütundaki Sayfa Yükleme Örneği değerlerine bakarak görebiliriz. Ortadaki satırların diğer iki satırdan çok daha küçük bir örneğe sahip olduğuna dikkat edin.
İkinci sorumuz şuydu: Hizmet çalışanı, site yükleme deneyimini nasıl etkiler?
Bu soruyu yanıtlamak amacıyla Ort. Etkinlik Değeri için başka bir özel rapor oluşturduk ve sonuçları yalnızca firstpaint etkinliklerimizi içerecek şekilde filtreledik. Cihaz Kategorisi boyutlarını ve özel Hizmet Çalışanı Durumu boyutunu kullandık.
Beklediğimin aksine, mobil cihazlarda hizmet çalışanının ilk boyama süresi üzerindeki etkisi, genel sayfa yüklemesinde olduğundan çok daha azdı.
"...mobil cihazlarda hizmet çalışanının ilk boyama süresi üzerindeki etkisi, genel sayfa yüklemesinde olduğundan çok daha az oldu."
Bunun nedenini anlamak için verileri daha ayrıntılı incelememiz gerekiyor. Ortalamalar, genel özetler ve geniş çizgiler için iyi olabilir, ancak bu sayıların bir kullanıcı yelpazesine göre nasıl bir dökümde olduğunu tam olarak anlayabilmek için firstpaint kez dağılıma bakmamız gerekir.
Google Analytics'te bir metriğin dağıtımını alma
firstpaint kez dağılımını elde etmek için her etkinliğe ait ayrı sonuçlara erişmemiz gerekir. Maalesef, Google Analytics bunu kolay hale getirmiyor.
Google Analytics, bir raporu istediğimiz boyuta göre ayırmamıza olanak tanır, ancak kullanıma bir raporun metriklere göre ayrılmasına izin vermez. Bu, bunun imkansız olduğu anlamına gelmez; istenen sonucu elde etmek için uygulamamızı biraz daha özelleştirmemiz gerektiği anlamına gelir.
Rapor sonuçları yalnızca boyutlara göre ayrılabileceğinden, metrik değerini (bu örnekte firstpaint kez) etkinlikte özel boyut olarak ayarlamamız gerekiyordu. Bunu yapmak için Metrik Değeri adında başka bir özel boyut oluşturduk ve firstpaint izleme mantığımızı aşağıdaki şekilde güncelledik:
var customDimensions = {
SERVICE_WORKER_STATUS: 'dimension1',
<strong>METRIC_VALUE: 'dimension2'</strong>
};
// ...
function sendTimeToFirstPaint() {
var timeToFirstPaint = getTimeToFirstPaintIfSupported();
if (timeToFirstPaint) {
var fields = {
eventCategory: 'Performance',
eventAction: 'firstpaint',
// Rounds to the nearest millisecond since
// event values in Google Analytics must be integers.
eventValue: Math.round(timeToFirstPaint)
// Sends this as a non-interaction event,
// so it doesn't affect bounce rate.
nonInteraction: true
}
<strong>// Sets the event value as a dimension to allow for breaking down the
// results by individual metric values at reporting time.
fields[customDimensions.METRIC_VALUE] = String(fields.eventValue);</strong>
ga('send', 'event', fields);
}
}
Google Analytics web arayüzü, şu anda rastgele metrik değerlerinin dağılımını görselleştirmek için bir yol sunmamaktadır. Ancak, Google Analytics Temel Raporlama API'sı ve Google Grafikler kitaplığı yardımıyla ham sonuçları sorgulayabiliyor ve ardından kendimiz bir histogram oluşturabiliyoruz.
Örneğin, kontrolsüz bir hizmet çalışanıyla masaüstünde firstpaint değerlerinin dağıtımını almak için aşağıdaki API isteği yapılandırması kullanılmıştır.
{
dateRanges: [{startDate: '2016-05-16', endDate: '2016-05-22'}],
metrics: [{expression: 'ga:totalEvents'}],
dimensions: [{name: 'ga:dimension2'}],
dimensionFilterClauses: [
{
operator: 'AND',
filters: [
{
dimensionName: 'ga:eventAction',
operator: 'EXACT',
expressions: ['firstpaint']
},
{
dimensionName: 'ga:dimension1',
operator: 'EXACT',
expressions: ['supported']
},
{
dimensionName: 'ga:deviceCategory',
operator: 'EXACT',
expressions: ['desktop']
}
],
}
],
orderBys: [
{
fieldName: 'ga:dimension2',
orderType: 'DIMENSION_AS_INTEGER'
}
]
}
Bu API isteği, aşağıdakine benzer bir değerler dizisi döndürür (Not: Bunlar yalnızca ilk beş sonuçtur). Sonuçlar en küçükten en büyüğe doğru sıralandığından bu satırlar en hızlı zamanları gösterir.
| API Yanıtı Sonuçları (ilk beş satır) | |
|---|---|
| ga:boyut2 | ga:totalEvents |
| 4 | 3 |
| 5 | 2 |
| 6 | 10 |
| 7 | 8 |
| 8 | 10 |
Bu sonuçların yalın bir İngilizcesi şu anlamlara gelir:
firstpaintdeğerinin 4 ms olduğu 3 etkinlik gerçekleştifirstpaintdeğerinin 5 ms olduğu 2 etkinlik vardıfirstpaintdeğerinin 6 ms olduğu 10 etkinlik gerçekleştifirstpaintdeğerinin 7 ms olduğu 8 etkinlik vardıfirstpaintvaluedeğerinin 8 ms olduğu 10 etkinlik gerçekleşti- vb.
Bu sonuçlardan yararlanarak her bir etkinlik için firstpaint değerini tahmin edebilir ve dağılımın histogramını oluşturabiliriz. Bu yaklaşımı, yaptığımız sorguların her biri için uyguladık.
Dağıtımın, kontrol edilmeyen (ancak desteklenen) bir hizmet çalışanıyla masaüstünde nasıl göründüğü aşağıda gösterilmiştir:
Yukarıdaki dağılım için ortanca firstpaint süresi 912 ms'dir.
Bu eğrinin şekli, yükleme süresi dağılımlarının oldukça tipik bir örneğidir. Bunu, sayfayı bir hizmet çalışanının kontrol ettiği ziyaretler için ilk boyama etkinliklerinin dağılımını gösteren aşağıdaki histogramdan karşılaştırın.
Sayfayı bir hizmet çalışanı kontrol ederken, birçok ziyaretçinin ortalama 583 ms ile neredeyse hemen ilk boyama deneyimi yaşadığına dikkat edin.
"...sayfayı bir hizmet çalışanı kontrol ederken birçok ziyaretçi neredeyse anında ilk boyama sorunuyla karşılaştı..."
Bu iki dağılımın birbiriyle karşılaştırmasını daha iyi anlayabilmeniz için bir sonraki grafikte bu iki dağılımın birleştirilmiş görünümü gösterilmektedir. Kontrollü olmayan hizmet çalışanı ziyaretlerini gösteren histogram, kontrollü ziyaretleri gösteren histogramın üzerine yerleştirilmiş ve her ikisi de her ikisini birlikte gösteren bir histogramın üzerine yerleştirilmiş.
Bu sonuçlarla ilgili ilginç bulduğum şeylerden biri, kontrollü bir hizmet çalışanı içeren dağılımın ilk ani artıştan sonra da çan şeklinde bir eğrinin devam etmesiydi. Başlangıçta büyük bir artış, ardından kademeli bir iz bırakma bekliyordum. Eğride ikinci bir tepe noktası görmeyi beklemiyordum.
Buna neyin neden olabileceğini araştırdığımda, bir hizmet çalışanı bir sayfayı kontrol ediyor olsa bile onun ileti dizisinin devre dışı olabileceğini öğrendim. Tarayıcı bunu kaynakları korumak için yapar. Doğal olarak, ziyaret ettiğiniz her site için her hizmet çalışanının etkin ve anında hazır olması gerekmez. Bu, dağılımın kuyruğunu açıklar. Bazı kullanıcılarda Service Worker iş parçacığı başlatılırken bir gecikme oluştu.
Yine de dağıtımdan görebileceğiniz gibi, bu ilk gecikmede bile, Service Worker'a sahip tarayıcılar içeriği ağ üzerinden geçen tarayıcılardan daha hızlı yayınladı.
Öğeler mobil cihazlarda şöyle göründü:
Neredeyse anında ilk boyama sürelerinde büyük bir artış yaşamış olsak da kuyruk biraz daha büyük ve daha uzundu. Bunun nedeni büyük olasılıkla mobil cihazlarda boşta bir hizmet çalışanı iş parçacığının başlatılmasının masaüstüne göre daha uzun sürmesidir. Ayrıca ortalama firstpaint süre arasındaki farkın neden beklediğim kadar büyük olmadığını da açıklıyor (yukarıda açıklanmıştır).
"Mobil cihazlarda boşta hizmet çalışanı iş parçacığının başlatılması masaüstünde olduğundan daha uzun sürer."
Mobil ve masaüstü cihazlarda ilk boyama sürelerinin bu ortanca değer varyasyonlarının hizmet çalışanı durumuna göre gruplandırılmış dökümü aşağıda verilmiştir:
| İlk Boyama için Ortanca Süre (ms) | ||
|---|---|---|
| Hizmet Çalışanı Durumu | Masaüstü | Mobil |
| Kontrol etti | 583 | 1634 |
| Destekleniyor (kontrolsüz) | 912 | 1933 |
Bu dağıtım görselleştirmelerini oluşturmak, Google Analytics'te özel bir rapor oluşturmaktan biraz daha fazla zaman ve çaba gerektirse de, hizmet çalışanlarının sitemizin performansını tek başına ortalamalara kıyasla nasıl etkilediğini daha iyi anlamamızı sağladı.
Hizmet çalışanlarının diğer etkileri
Performansa etkisine ek olarak Service Worker'lar, kullanıcı deneyimini Google Analytics ile ölçülebilen başka birçok yolla da etkiler.
Çevrimdışı erişim
Service Worker'lar, kullanıcıların çevrimdışıyken sitenizle etkileşimde bulunmalarına olanak tanır. Bir tür çevrimdışı destek, herhangi bir progresif web uygulaması için muhtemelen kritik öneme sahip olsa da sizin durumunuzda ne kadar kritik olduğunun belirlenmesi, büyük ölçüde çevrimdışı kullanımların ne kadar olduğuna bağlıdır. Peki bunu nasıl ölçüyoruz?
Google Analytics'e veri göndermek için internet bağlantısı gerekir, ancak verilerin tam olarak etkileşimin gerçekleştiği zamanda gönderilmesini gerektirmez. Google Analytics, zaman farkı belirterek (qt parametresi aracılığıyla) olayın ardından etkileşim verilerinin gönderilmesini destekler.
IOWA, son iki yıldır kullanıcı çevrimdışıyken Google Analytics'e yapılan başarısız isabetleri tespit eden ve bunları qt parametresiyle daha sonra tekrar oynatan bir Service Worker komut dosyası kullanıyor.
Kullanıcının çevrimiçi mi yoksa çevrimdışı mı olduğunu izlemek için Online adlı bir özel boyut oluşturduk ve bunu navigator.onLine değerine ayarladık. Ardından online ve offline etkinliklerini dikkate aldık ve boyutu buna göre güncelledik.
Bir kullanıcının IOWA kullanırken çevrimdışı olmasının ne kadar yaygın olduğunu anlamak için de en az bir çevrimdışı etkileşimde bulunan kullanıcıları hedefleyen bir segment oluşturduk. Bu kullanıcıların neredeyse% 5'inin ilgili olduğu ortaya çıktı.
Push bildirimleri
Service Worker'lar, kullanıcıların push bildirimleri almayı etkinleştirmesine olanak tanır. IOWA'da, programlarındaki bir oturum başlamak üzereyken kullanıcılara bildirim gönderildi.
Tüm bildirimlerde olduğu gibi, kullanıcıya değer sağlama ile onu rahatsız etme arasındaki dengeyi bulmak önemlidir. Hangi işlemin gerçekleştiğini daha iyi anlamak için, kullanıcıların bu bildirimleri almayı etkinleştirip etkinleştirmediklerini, bildirim geldiğinde bildirimle etkileşimde bulunup bulunmadığını ve daha önce e-posta almayı tercih eden kullanıcılardan herhangi birinin tercihini değiştirip devre dışı bırakmayı tercih edip etmediğini izlemek önemlidir.
IOWA'da, sadece kullanıcının kişiselleştirilmiş programıyla ilgili bildirimler gönderdik, sadece giriş yapmış olan kullanıcılar tarafından oluşturulabilecek bir şeydi. Bu durum, tarayıcıları push bildirimlerini destekleyen (Bildirim İzni adlı başka bir özel boyut aracılığıyla izlenir) oturum açmış (Oturum Açık adlı özel bir boyut aracılığıyla izlenen) kullanıcılara bildirim alabilecek kullanıcı grubunu sınırlandırmıştır.
Aşağıdaki rapor, Kullanıcılar metriği ile Bildirim İzni özel boyutumuzu temel alır. Bu metrik, bir noktada oturum açan ve tarayıcıları push bildirimleri destekleyen kullanıcılara göre segmentlere ayrılır.
Oturum açmış kullanıcılarımızın yarısından fazlasının push bildirimlerini almayı tercih etmesi harika.
Uygulama yükleme banner'ları
Bir İlerleme durumu web uygulaması ölçütleri karşılıyorsa ve kullanıcı tarafından sıklıkla kullanılıyorsa söz konusu kullanıcıya, uygulamayı ana ekranına eklemelerini isteyen bir uygulama yükleme banner'ı gösterilebilir.
IOWA'da, bu istemlerin kullanıcıya ne sıklıkta gösterildiğini (ve kabul edilip edilmediğini) aşağıdaki kodu kullanarak izledik:
window.addEventListener('beforeinstallprompt', function(event) {
// Tracks that the user saw a prompt.
ga('send', 'event', {
eventCategory: 'installprompt',
eventAction: 'fired'
});
event.userChoice.then(function(choiceResult) {
// Tracks the users choice.
ga('send', 'event', {
eventCategory: 'installprompt',
// `choiceResult.outcome` will be 'accepted' or 'dismissed'.
eventAction: choiceResult.outcome,
// `choiceResult.platform` will be 'web' or 'android' if the prompt was
// accepted, or '' if the prompt was dismissed.
eventLabel: choiceResult.platform
});
});
});
Uygulama yükleme banner'ını gören kullanıcıların yaklaşık% 10'u banner'ı ana ekranlarına eklemeyi tercih etti.
Takiple ilgili olası iyileştirmeler (bir dahaki sefer için)
Bu yıl IOWA'dan topladığımız analiz verileri paha biçilmezdi. Ancak arkadan bir şeyler her zaman bir sonraki sefer için bir şeyleri iyileştirme fırsatları ve ışık delikleri getirir. Bu yılın analizini bitirdikten sonra, benzer bir stratejiyi uygulamak isteyen okuyucuların göz önünde bulundurabileceği, farklı şekilde yapmamızı istediğim iki şey var:
1. Yükleme deneyimiyle ilgili daha fazla etkinliği izleyin
Bir teknik metriğe karşılık gelen birkaç etkinliği izledik (ör. HTMLImportsLoaded, WebComponentsReady vb.) ancak yükün çok büyük bir kısmı eşzamansız olarak yapıldığı için bu etkinliklerin tetiklendiği nokta, genel yükleme deneyiminde belirli bir ana denk gelmiyordu.
Yüklemeyle ilgili olarak izlemediğimiz (ancak keşke izleseydik) birincil etkinlik, başlangıç ekranının kaybolduğu ve kullanıcının sayfa içeriğini görebileceği noktadır.
2. Analytics istemci kimliğini IndexedDB'de depolayın
analytics.js, varsayılan olarak istemci kimliği alanını tarayıcının çerezlerinde depolar; ne yazık ki hizmet çalışanı komut dosyaları çerezlere erişemez.
Bu durum, bildirim izlemeyi uygulamaya çalışırken bizim için bir sorun teşkil etti. Kullanıcıya her bildirim gönderildiğinde hizmet çalışanından bir etkinlik göndermek (Measurement Protocol yoluyla) ve kullanıcı bildirimi tıklayıp uygulamaya geri döndüğünde söz konusu bildirimin yeniden etkileşim başarısını izlemek istedik.
utm_source kampanya parametresi aracılığıyla genel olarak bildirimlerin başarısını izleyebilsek de belirli bir yeniden etkileşim oturumunu belirli bir kullanıcıya bağlayamadık.
Bu sınırlamayı aşmak için yapabileceğimiz şey, istemci kimliğini IndexedDB aracılığıyla izleme kodumuzda saklamaktır; bu durumda Service Worker komut dosyası bu değere erişebilir.
3. Hizmet çalışanının çevrimiçi/çevrimdışı durumu bildirmesine izin verme
navigator.onLine hizmetinin denetlenmesi, tarayıcınızın yönlendiriciye veya yerel ağa bağlanıp bağlanamadığını size bildirir, ancak kullanıcının gerçek bağlantısı olup olmadığını kesin olarak anlamaz. Çevrimdışı analiz hizmeti çalışanı komut dosyamız, başarısız isabetleri tekrar oynattığından (bunları değiştirmeden veya başarısız olarak işaretlemeden) muhtemelen çevrimdışı kullanımımızı eksik raporluyorduk.
Gelecekte hem navigator.onLine durumunu hem de isabetin ilk ağ hatası nedeniyle hizmet çalışanı tarafından tekrar oynatılıp oynatılmadığını izlememiz gerekecek. Bu sayede gerçek çevrimdışı kullanımı daha doğru bir şekilde görebiliriz.
Özet
Bu örnek olay, Service Worker'ın çok çeşitli tarayıcı, ağ ve cihazlarda Google I/O web uygulamasının yük performansını gerçekten de iyileştirdiğini göstermiştir. Ayrıca, yük verilerinin çok çeşitli tarayıcılar, ağlar ve cihazlar genelindeki dağılımına baktığınızda, söz konusu teknolojinin gerçek hayat senaryolarını nasıl ele aldığıyla ilgili çok daha fazla fikir edindiğinizi ve beklemediğiniz performans özelliklerini keşfettiğinizi de göstermiştir.
IOWA araştırmasından çıkarılacak bazı önemli ana fikirler şunlardır:
- Bir hizmet çalışanının sayfayı kontrol ettiği durumlarda, hem yeni hem de geri gelen ziyaretçiler için sayfaların ortalama olarak Service Worker olmadan daha hızlı yüklendiği görülmüştür.
- Service Worker tarafından kontrol edilen sayfaların aldığı ziyaretler, birçok kullanıcı için neredeyse anında yükleniyor.
- Service Worker'ların devre dışı bırakılması biraz zaman aldı. Ancak etkin olmayan bir Service Worker, hiç hizmet çalışanı olmamasından daha iyi performans göstermiştir.
- Etkin olmayan bir Service Worker'ın başlatma süresi, mobil cihazlarda masaüstünden daha uzundu.
Belirli bir uygulamada gözlemlenen performans kazanımları genellikle daha büyük geliştirici topluluğuna raporlamada yararlı olsa da, bu sonuçların IOWA sitesinin türüne (bir etkinlik sitesi) ve IOWA kitlesinin türüne (çoğunlukla geliştiriciler) özel olduğunu unutmamak önemlidir.
Uygulamanızda Service Worker kullanıyorsanız kendi performansınızı değerlendirebilmeniz ve gelecekte yaşanabilecek gerilemelerin önüne geçebilmeniz için kendi ölçüm stratejinizi uygulamanız önemlidir. Kaydolduysanız herkesin yararlanabilmesi için lütfen sonuçlarınızı paylaşın.
Dipnotlar
- Service Worker önbellek uygulamamızın performansını, yalnızca HTTP önbelleği kullanıldığında sitemizin performansıyla karşılaştırmak pek adil olmaz. IOWA'yı Service Worker için optimize ettiğimizden HTTP önbelleğini optimize etmek için fazla zaman harcamadık. Kullansaydık sonuçlar muhtemelen farklı olurdu. Sitenizi HTTP önbelleği için optimize etme hakkında daha fazla bilgi edinmek üzere İçeriği Verimli Şekilde Optimize Etme başlıklı makaleyi okuyun.
- Sitenizin stillerini ve içeriğini nasıl yüklediğine bağlı olarak, tarayıcı içerik veya stiller kullanılabilir olmadan önce boyayabilir. Bu gibi durumlarda
firstpaint, boş beyaz bir ekrana karşılık gelebilir.firstpaintkullanıyorsanız bunun sitenizin kaynaklarının yüklenmesinde anlamlı bir noktaya karşılık geldiğinden emin olmanız önemlidir. - Teknik olarak, bu bilgiyi bir etkinlik yerine yakalamak için bir zamanlama isabeti (varsayılan olarak etkileşim özelliği değildir) gönderebiliriz. Aslında, zamanlama isabetleri Google Analytics'e özellikle bunun gibi yükleme metriklerini izlemek için eklenmiştir. Ancak, zamanlama isabetleri işleme sırasında yoğun bir şekilde örneklenir ve bunların değerleri segmentlerde kullanılamaz. Mevcut kısıtlamalar göz önünde bulundurulduğunda, etkileşim dışı etkinlikler daha uygun olmaya devam etmektedir.
- Google Analytics'te bir özel boyuta hangi kapsamın verileceğini daha iyi anlamak için Analytics yardım merkezinin Özel Boyut bölümüne bakın. Ayrıca kullanıcılar, oturumlar ve etkileşimlerden (isabetlerden) oluşan Google Analytics veri modelini anlamak da önemlidir. Daha fazla bilgi edinmek için Google Analytics Veri Modeli ile ilgili Analytics Akademisi dersini izleyin.
- Bu, yükleme etkinliğinden sonra geç yüklenen kaynakları dikkate almaz.