Misurazione dell'impatto delle prestazioni reali dei lavoratori dei servizi

Philip Walton

Uno dei vantaggi più significativi dei service worker (almeno dal punto di vista delle prestazioni) è la loro capacità di controllare in modo proattivo la memorizzazione nella cache degli asset. Un'applicazione web che può memorizzare nella cache tutte le risorse necessarie dovrebbe caricarsi notevolmente più velocemente per i visitatori di ritorno. Ma come si presentano questi vantaggi per gli utenti reali? E come fai a misurarlo?

L'app web Google I/O (in breve IOWA) è un'app web progressiva che ha sfruttato la maggior parte delle nuove funzionalità offerte dai service worker per offrire agli utenti un'esperienza completa, simile a quella delle app. Inoltre, ha utilizzato Google Analytics per acquisire dati chiave sulle prestazioni e i modelli di utilizzo dal suo ampio e diversificato pubblico di utenti.

Questo caso di studio illustra in che modo l'IOWA ha utilizzato Google Analytics per rispondere a domande chiave sul rendimento e generare report sull'impatto reale dei worker di servizio.

Iniziamo dalle domande

Ogni volta che implementi dati e analisi in un sito web o in un'applicazione, è importante iniziare identificando le domande a cui stai cercando di rispondere in base ai dati che raccoglierai.

Avevamo diverse domande a cui volevamo rispondere, ma per gli scopi di questo caso studio, concentriamoci su due delle più interessanti.

1. La memorizzazione nella cache dei service worker è più efficace rispetto ai meccanismi di memorizzazione nella cache HTTP esistenti disponibili in tutti i browser?

Ci aspettiamo già che le pagine vengano caricate più velocemente per i visitatori di ritorno rispetto ai nuovi visitatori, poiché i browser possono memorizzare nella cache le richieste e servirle immediatamente in caso di visite ripetute.

I Service worker offrono funzionalità di memorizzazione nella cache alternative che offrono agli sviluppatori un controllo granulare su cosa esattamente e come viene eseguito il processo di memorizzazione nella cache. In IOWA, abbiamo ottimizzato l'implementazione del nostro service worker in modo che ogni asset venisse memorizzato nella cache, in modo che i visitatori di ritorno potessero utilizzare l'app completamente offline.

Ma questo sforzo sarebbe meglio di quello che già fa il browser per impostazione predefinita? Se sì, quanto è migliore? 1

2. In che modo il service worker influisce sull'esperienza di caricamento del sito?

In altre parole, quanto sembra veloce il caricamento del sito, indipendentemente dai tempi di caricamento effettivi misurati dalle metriche di caricamento pagina tradizionali?

Ovviamente, rispondere a domande sul modo in cui si vive un'esperienza non è un compito facile e nessuna metrica può rappresentare perfettamente un sentimento così soggettivo. Detto questo, ci sono sicuramente metriche migliori di altre, quindi è importante sceglierle correttamente.

Scegliere la metrica giusta

Per impostazione predefinita, Google Analytics monitora i tempi di caricamento delle pagine (tramite l'API Navigation Timing) per l'1% dei visitatori di un sito e rende disponibili questi dati tramite metriche come Tempo di caricamento pagina medio.

Tempo di caricamento della pagina medio è una buona metrica per rispondere alla prima domanda, ma non è particolarmente utile per rispondere alla seconda. Innanzitutto, l'evento load non corrisponde necessariamente al momento in cui l'utente può effettivamente interagire con l'app. Inoltre, due app con lo stesso tempo di caricamento potrebbero sembrare caricarsi in modo molto diverso. Ad esempio, un sito con una schermata iniziale o un indicatore di caricamento sembra che venga caricato molto più velocemente di un sito che mostra soltanto una pagina vuota per alcuni secondi.

In IOWA, abbiamo mostrato un'animazione di conto alla rovescia nella schermata iniziale che (a mio avviso) ha intrattenuto molto bene l'utente mentre il resto dell'app si caricava in background. Per questo motivo, monitorare il tempo necessario per visualizzare la schermata iniziale ha molto più senso come metodo per misurare il rendimento del caricamento percepito. Per ottenere questo valore, abbiamo scelto la metrica Tempo di visualizzazione della prima pagina.

Una volta stabilite le domande a cui volevamo rispondere e identificate le metriche utili per rispondere, era giunto il momento di implementare Google Analytics e iniziare a misurare.

L'implementazione dell'analisi

Se hai già utilizzato Google Analytics, probabilmente conosci lo snippet di monitoraggio JavaScript consigliato. Ha questo aspetto:

<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>

La prima riga del codice riportato sopra inizializza una funzione ga() globale (se non esiste già) e l'ultima riga scarica in modo asincrono la libreria analytics.js.

La parte centrale contiene queste due righe:

ga('create', 'UA-XXXXX-Y', 'auto');
ga('send', 'pageview');

Questi due comandi monitorano le pagine visitate dagli utenti che accedono al tuo sito, ma non molto di più. Se vuoi monitorare altre interazioni utente, devi farlo autonomamente.

Per la campagna IOWA, volevamo monitorare altri due elementi:

• Il tempo trascorso tra l'inizio del caricamento della pagina e la visualizzazione dei pixel sullo schermo.
• Indica se la pagina è controllata o meno da un service worker. Con queste informazioni, potremmo segmentare i report per confrontare i risultati con e senza il servizio worker.

Acquisizione del tempo per il primo rendering

Alcuni browser registrano l'ora esatta in cui viene visualizzato il primo pixel sullo schermo e rendono questo dato disponibile per gli sviluppatori. Questo valore, rispetto al valore navigationStart esposto tramite l'API Navigation Timing, ci fornisce un conteggio molto preciso del tempo trascorso tra la richiesta iniziale della pagina da parte dell'utente e la prima visualizzazione di un elemento.

Come già accennato, il tempo alla prima visualizzazione è una metrica importante da misurare perché è il primo punto in cui un utente rileva la velocità di caricamento del tuo sito. È la prima impressione che gli utenti ricevono e una buona prima impressione può influire positivamente sul resto dell'esperienza utente.2

Per ottenere il primo valore di visualizzazione nei browser che lo espongono, abbiamo creato la funzione di utilità getTimeToFirstPaintIfSupported:

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;
    }
  }
}

Con questo, ora potremmo scrivere un'altra funzione che invia un evento di non interazione con il tempo di visualizzazione iniziale come valore: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
    });
  }
}

Dopo aver scritto entrambe le funzioni, il codice di monitoraggio sarà il seguente:

// 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();

Tieni presente che, a seconda di quando viene eseguito il codice riportato sopra, i pixel possono essere o meno già visualizzati sullo schermo. Per assicurarci di eseguire sempre questo codice dopo il primo rendering, abbiamo posticipato la chiamata a sendTimeToFirstPaint() fino al termine dell'evento load. Infatti, abbiamo deciso di posticipare l'invio di tutti i dati di analisi fino al termine del caricamento della pagina per garantire che queste richieste non fossero in concorrenza con il caricamento di altre risorse.

// 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();
});

Il codice riportato sopra genera firstpaint report in Google Analytics, ma non è tutto. Dovevamo comunque monitorare lo stato del service worker, altrimenti non avremmo potuto confrontare i tempi di primo rendering di una pagina controllata da un service worker e di una pagina non controllata.

Determinare lo stato del service worker

Per determinare lo stato attuale del service worker, abbiamo creato una funzione di utilità che restituisce uno di tre valori:

• controllato: un service worker sta controllando la pagina. Nel caso di IOWA, significa anche che tutti gli asset sono stati memorizzati nella cache e la pagina funziona offline.
• supportato: il browser supporta i service worker, ma il service worker non controlla ancora la pagina. Questo è lo stato previsto per i visitatori che accedono per la prima volta.
• unsupported: il browser dell'utente non supporta i worker di servizio.

function getServiceWorkerStatus() {
  if ('serviceWorker' in navigator) {
    return navigator.serviceWorker.controller ? 'controlled' : 'supported';
  } else {
    return 'unsupported';
  }
}

Questa funzione ha recuperato lo stato del worker del servizio. Il passaggio successivo è stato associare questo stato ai dati che inviavamo a Google Analytics.

Monitoraggio dei dati personalizzati con dimensioni personalizzate

Per impostazione predefinita, Google Analytics offre molti modi per suddividere il traffico totale in gruppi in base agli attributi dell'utente, della sessione o dell'interazione. Questi attributi sono noti come dimensioni. Le dimensioni comuni che interessano agli sviluppatori web sono, ad esempio, Browser, Sistema operativo o Categoria dispositivo.

Lo stato del service worker non è una dimensione fornita da Google Analytics per impostazione predefinita. Tuttavia, Google Analytics ti consente di creare le tue dimensioni personalizzate e definirle come preferisci.

Per IOWA, abbiamo creato una dimensione personalizzata denominata Stato del service worker e impostato l'ambito su hit (ovvero per interazione).4 A ogni dimensione personalizzata creata in Google Analytics viene assegnato un indice univoco all'interno della proprietà e nel codice di monitoraggio puoi fare riferimento a questa dimensione tramite il relativo indice. Ad esempio, se l'indice della dimensione che abbiamo appena creato fosse 1, potremmo aggiornare la nostra logica come segue per inviare l'evento firstpaint in modo da includere lo stato del servizio worker:

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()
});

Funziona, ma associa lo stato del service worker solo a questo evento specifico. Poiché lo stato del servizio worker è un dato potenzialmente utile per qualsiasi interazione, è meglio includerlo in tutti i dati inviati a Google Analytics.

Per includere queste informazioni in tutti gli hit (ad es. tutte le visualizzazioni di pagina, gli eventi e così via), impostiamo il valore della dimensione personalizzata sull'oggetto tracker stesso, prima di inviare qualsiasi dato a Google Analytics.

ga('set', 'dimension1', getServiceWorkerStatus());

Una volta impostato, questo valore viene inviato con tutti gli hit successivi per il caricamento della pagina corrente. Se l'utente carica di nuovo la pagina in un secondo momento, è probabile che la funzione getServiceWorkerStatus() restituisca un nuovo valore, che verrà impostato sull'oggetto tracker.

Una breve nota sulla chiarezza e sulla leggibilità del codice: poiché altre persone che osservano questo codice potrebbero non sapere a cosa si riferisce dimension1, è sempre meglio creare una variabile che mappa nomi di dimensioni significativi ai valori utilizzati da analytics.js.

// 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();
});

Come ho accennato, l'invio della dimensione Stato del servizio worker con ogni hit ci consente di utilizzarla per generare report su qualsiasi metrica.

Come puoi vedere, quasi l'85% di tutte le visualizzazioni di pagina per l'Iowa proveniva da browser che supportano i worker di servizio.

Risultati: risposte alle nostre domande

Dopo aver iniziato a raccogliere dati per rispondere alle nostre domande, potremmo creare un report su questi dati per vedere i risultati. (Nota: tutti i dati di Google Analytics mostrati qui rappresentano il traffico web effettivo sul sito IOWA dal 16 al 22 maggio 2016).

La prima domanda è stata: La memorizzazione nella cache dei service worker è più efficace rispetto ai meccanismi di memorizzazione nella cache HTTP esistenti disponibili in tutti i browser?

Per rispondere a questa domanda, abbiamo creato un report personalizzato che esaminava la metrica Tempi di caricamento medi della pagina in varie dimensioni. Questa metrica è adatta a rispondere a questa domanda perché l'evento load viene attivato solo dopo aver scaricato tutte le risorse iniziali. Quindi riflette direttamente il tempo di caricamento totale per tutte le risorse critiche del sito.5

Le dimensioni che abbiamo scelto sono:

• La nostra dimensione personalizzata Stato del service worker.
• Tipo di utente, che indica se si tratta della prima visita dell'utente al sito o se è di ritorno. Nota: un nuovo visitatore non avrà risorse memorizzate nella cache, mentre un visitatore di ritorno potrebbe averne.
• Categoria dispositivo, che ci consente di confrontare i risultati su dispositivi mobili e computer.

Per verificare la possibilità che fattori non correlati ai worker di servizio stessero alterando i risultati relativi ai tempi di caricamento, abbiamo limitato la query in modo da includere solo i browser che supportano i worker di servizio.

Come puoi vedere, le visite alla nostra app quando controllate da un service worker vengono caricate molto più velocemente rispetto alle visite non controllate, anche quelle provenienti da utenti di ritorno che probabilmente avevano la maggior parte delle risorse della pagina memorizzata nella cache. È anche interessante notare che, in media, i visitatori su dispositivi mobili con un service worker hanno registrato un caricamento più rapido rispetto ai nuovi visitatori su computer.

"…le visite alla nostra app controllate da un service worker si caricano molto più velocemente rispetto alle visite non controllate…"

Puoi trovare ulteriori dettagli nelle due tabelle seguenti:

Potresti chiederti come sia possibile che un visitatore di ritorno il cui browser supporta i service worker si trovi mai in uno stato non controllato. Ecco alcune spiegazioni possibili:

• L'utente ha abbandonato la pagina durante la visita iniziale prima che il service worker avesse la possibilità di completare l'inizializzazione.
• L'utente ha disinstallato il service worker tramite gli strumenti per sviluppatori.

Entrambe queste situazioni sono relativamente rare. Possiamo vederlo nei dati esaminando i valori di Sample di caricamento pagina nella quarta colonna. Tieni presente che le righe centrali hanno un campione molto più piccolo rispetto alle altre due.

La seconda domanda era: In che modo il service worker influisce sull'esperienza di caricamento del sito?

Per rispondere a questa domanda, abbiamo creato un altro report personalizzato per la metrica Valore evento medio e abbiamo filtrato i risultati in modo da includere solo i nostri eventi firstpaint. Abbiamo utilizzato le dimensioni Categoria del dispositivo e la nostra dimensione personalizzata Stato del servizio in background.

Contrariamente a quanto mi aspettassi, il service worker sui dispositivi mobili ha avuto un impatto molto minore sul tempo di visualizzazione della prima pagina rispetto al caricamento complessivo della pagina.

"...il service worker su dispositivo mobile ha avuto un impatto sui tempi di visualizzazione della prima visualizzazione molto inferiore rispetto al caricamento complessivo della pagina."

Per capire perché, dobbiamo esaminare più in dettaglio i dati. Le medie possono essere utili per panoramiche generali e approssimazioni, ma per avere un'idea precisa di come questi numeri si suddividono in un range di utenti, dobbiamo esaminare una distribuzione di firstpaint volte.

Ottenere la distribuzione di una metrica in Google Analytics

Per ottenere la distribuzione di firstpaint volte, abbiamo bisogno di accedere ai singoli risultati per ogni evento. Purtroppo, Google Analytics non semplifica queste operazioni.

Google Analytics ci consente di suddividere un report in base a qualsiasi dimensione, ma non ci consente di suddividere un report in base alle metriche. Ciò non significa che sia impossibile, ma solo che abbiamo dovuto personalizzare un po' di più la nostra implementazione per ottenere il risultato desiderato.

Poiché i risultati dei report possono essere suddivisi solo per dimensioni, abbiamo dovuto impostare il valore della metrica (in questo caso firstpaint volta) come dimensione personalizzata per l'evento. Per farlo, abbiamo creato un'altra dimensione personalizzata denominata Valore metrica e abbiamo aggiornato la logica di monitoraggio firstpaint come segue:

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);
  }
}

Al momento l'interfaccia web di Google Analytics non consente di visualizzare la distribuzione dei valori arbitrari delle metriche, ma con l'aiuto dell'API Core Reporting di Google Analytics e della libreria dei grafici di Google abbiamo potuto eseguire query sui risultati non elaborati e poi creare personalmente un istogramma.

Ad esempio, è stata utilizzata la seguente configurazione delle richieste API per ottenere una distribuzione di valori firstpaint su computer con un service worker non controllato.

{
  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'
    }
  ]
}

Questa richiesta API restituisce un array di valori simile al seguente (nota: questi sono solo i primi cinque risultati). I risultati sono ordinati dal più piccolo al più grande, quindi queste righe rappresentano i tempi più rapidi.

Ecco cosa significano questi risultati in termini semplici:

• Sono stati registrati 3 eventi in cui il valore firstpaint era 4 ms
• Sono stati registrati 2 eventi in cui il valore di firstpaint era 5 ms
• Sono stati registrati 10 eventi in cui il valore di firstpaint era 6 ms
• Sono stati registrati 8 eventi in cui il valore di firstpaint era 7 ms
• Sono stati registrati 10 eventi in cui firstpaint value era pari a 8 ms
• e così via

Da questi risultati possiamo estrapolare il valore firstpaint per ogni singolo evento e creare un'istogramma della distribuzione. Lo abbiamo fatto per ogni query eseguita.

Ecco come appariva la distribuzione su computer con un service worker non controllato (ma supportato):

Il tempo mediano di firstpaint per la distribuzione sopra indicata è di 912 ms.

La forma di questa curva è piuttosto tipica delle distribuzioni del tempo di caricamento. Sono messi a confronto con l'istogramma riportato di seguito, che mostra la distribuzione degli eventi First Paint per le visite in cui un service worker controllava la pagina.

Tieni presente che quando un service worker controllava la pagina, molti visitatori hanno riscontrato un primo rendering quasi immediato, con una media di 583 ms.

"…quando un service worker controllava la pagina, molti visitatori hanno riscontrato un primo rendering quasi immediato…"

Per comprendere meglio il confronto tra queste due distribuzioni, il grafico seguente mostra una vista combinata delle due. L'istogramma che mostra le visite dei worker di servizio non controllate è sovrapposto all'istogramma che mostra le visite controllate e entrambi sono sovrapposti a un istogramma che mostra entrambe le visite combinate.

Una cosa che ho trovato interessante di questi risultati è che la distribuzione con un service worker controllato presentava ancora una curva a forma di campana dopo il picco iniziale. Mi aspettavo un grande picco iniziale e poi un sentiero graduale in discesa, non mi aspettavo un secondo picco nella curva.

Esaminando la causa, ho scoperto che anche se un service worker può controllare una pagina, il suo thread può essere inattivo. Il browser esegue questa operazione per risparmiare risorse: ovviamente non è necessario che tutti i worker di servizio per tutti i siti che hai visitato siano attivi e pronti in qualsiasi momento. Questo spiega la coda della distribuzione. Per alcuni utenti si è verificato un ritardo durante l'avvio del thread del worker di servizio.

Tuttavia, come puoi vedere dalla distribuzione, anche con questo ritardo iniziale, i browser con il servizio worker hanno caricato i contenuti più velocemente rispetto ai browser che passano attraverso la rete.

Ecco come apparivano le cose sui dispositivi mobili:

Anche se abbiamo avuto un notevole aumento nei tempi di prima verniciatura quasi immediati, la coda era molto più grande e più lunga. Questo è probabilmente dovuto al fatto che, sui dispositivi mobili, l'avvio di un thread di worker di servizio inattivo richiede più tempo che su computer. Spiega anche perché la differenza tra il tempo firstpaint medio non era così grande come mi aspettavo (discussa sopra).

"...sui dispositivi mobili, l'avvio di un thread del service worker inattivo richiede più tempo rispetto a quando avviene su desktop."

Ecco la suddivisione di queste variazioni dei tempi medi della prima pittura su dispositivi mobili e computer raggruppati in base allo stato del worker di servizio:

Sebbene la creazione di queste visualizzazioni di distribuzione abbia richiesto un po' più di tempo e impegno rispetto alla creazione di un report personalizzato in Google Analytics, ci offrono una comprensione molto più approfondita di come i worker del servizio influiscono sul rendimento del nostro sito rispetto alle sole medie.

Altro impatto dei service worker

Oltre all'impatto sul rendimento, i worker dei servizi influiscono anche sull'esperienza utente in diversi altri modi misurabili con Google Analytics.

Accesso offline

I service worker consentono agli utenti di interagire con il sito in modalità offline e, sebbene un qualche tipo di supporto offline sia probabilmente fondamentale per qualsiasi app web progressiva, determinare quanto sia fondamentale nel tuo caso dipende in gran parte da quanto utilizzo offline. Ma come possiamo misurarlo?

L'invio di dati a Google Analytics richiede una connessione a internet, ma non richiede che i dati vengano inviati nel momento esatto in cui si è verificata l'interazione. Google Analytics supporta l'invio dei dati sulle interazioni in un secondo momento specificando un offset di tempo (tramite il parametro qt).

Negli ultimi due anni, IOWA utilizza uno script di worker di servizio che rileva gli hit non riusciti in Google Analytics quando l'utente è offline e li riproduce in un secondo momento con il parametro qt.

Per monitorare se l'utente era online o offline, abbiamo creato una dimensione personalizzata denominata Online e l'abbiamo impostata sul valore navigator.onLine, quindi abbiamo ascoltato gli eventi online e offline e abbiamo aggiornato la dimensione di conseguenza.

Per capire quanto fosse comune per un utente essere offline durante l'utilizzo di IOWA, abbiamo creato un segmento che aveva come target gli utenti con almeno un'interazione offline. Si è scoperto che si trattava del 5% degli utenti.

Notifiche push

I worker di servizio consentono agli utenti di attivare la ricezione di notifiche push. In Iowa, gli utenti ricevevano una notifica quando stava per iniziare una sessione nel loro programma.

Come per qualsiasi forma di notifica, è importante trovare il giusto equilibrio tra offrire valore all'utente e non infastidirlo. Per capire meglio cosa succede, è importante monitorare se gli utenti attivano la ricezione di queste notifiche, se interagiscono con loro quando arrivano e se gli utenti che le hanno attivate in precedenza cambiano la loro preferenza e le disattivano.

In Iowa abbiamo inviato solo notifiche relative alla programmazione personalizzata dell'utente, che solo gli utenti che hanno eseguito l'accesso potevano creare. Ciò ha limitato l'insieme di utenti che potevano ricevere notifiche agli utenti che avevano eseguito l'accesso (monitorati tramite una dimensione personalizzata denominata Accesso) i cui browser supportavano le notifiche push (monitorati tramite un'altra dimensione personalizzata denominata Autorizzazione di notifica).

Il seguente report si basa sulla metrica Utenti e sulla nostra dimensione personalizzata Autorizzazione di notifica, segmentata in base agli utenti che hanno eseguito l'accesso a un certo punto e i cui browser supportano le notifiche push.

È fantastico vedere che più della metà degli utenti che hanno effettuato l'accesso ha scelto di ricevere notifiche push.

Banner per l'installazione di app

Se un'app web di avanzamento soddisfa i criteri e viene utilizzata di frequente da un utente, quest'ultimo potrebbe visualizzare un banner di installazione dell'app, che invita l'utente ad aggiungere l'app alla schermata Home.

In Iowa, abbiamo monitorato la frequenza con cui questi prompt sono stati mostrati all'utente (e se sono stati accettati) con il seguente codice:

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
    });
  });
});

Tra gli utenti che hanno visto un banner per l'installazione di app, circa il 10% ha scelto di aggiungerlo alla schermata Home.

Possibili miglioramenti del tracciamento (per la prossima volta)

I dati di analisi che abbiamo raccolto da IOWA quest'anno sono stati inestimabili. Ma il senno di poi mette sempre in luce lacune e opportunità di miglioramento per la prossima volta. Dopo aver concluso l'analisi di quest'anno, ecco due cose che vorrei fare in modo diverso e che i lettori che vogliono implementare una strategia simile potrebbero prendere in considerazione:

1. Monitorare altri eventi correlati all'esperienza di caricamento

Abbiamo monitorato diversi eventi che corrispondono a una metrica tecnica (ad es. HTMLImportsLoaded, WebComponentsReady e così via), ma poiché gran parte del caricamento è stato eseguito in modo asincrono, il punto in cui sono stati attivati questi eventi non corrispondeva necessariamente a un determinato momento nell'esperienza di caricamento complessiva.

L'evento principale relativo al caricamento che non abbiamo monitorato (ma ci sarebbe piaciuto farlo) è il punto in cui la schermata di benvenuto è scomparsa e l'utente ha potuto vedere i contenuti della pagina.

2. Memorizzare l'ID client di Analytics in IndexedDB

Per impostazione predefinita, analytics.js memorizza il campo ID cliente nei cookie del browser. Purtroppo, gli script di service worker non possono accedere ai cookie.

Questo ha causato un problema durante il tentativo di implementare il monitoraggio delle notifiche. Volevamo inviare un evento dal service worker (tramite Measurement Protocol) ogni volta che veniva inviata una notifica a un utente e poi monitorare il successo del ricoinvolgimento della notifica se l'utente ci faceva clic sopra e tornava nell'app.

Sebbene sia stato possibile monitorare il successo delle notifiche in generale tramite il utm_source parametro della campagna, non è stato possibile associare una determinata sessione di ricoinvolgimento a un determinato utente.

Per aggirare questa limitazione, avremmo potuto archiviare l'ID client tramite IndexedDB nel nostro codice di monitoraggio e quel valore sarebbe stato accessibile allo script del service worker.

3. Consenti al service worker di segnalare lo stato online/offline

L'ispezione di navigator.onLine ti consente di sapere se il browser è in grado di connettersi al router o alla rete locale, ma non indica necessariamente se l'utente dispone di una connettività reale. Inoltre, poiché il nostro script worker del servizio di analisi offline riproduceva semplicemente gli hit non riusciti (senza modificarli o contrassegnarli come non riusciti), probabilmente sottostimavamo il nostro utilizzo offline.

In futuro dovremmo tenere traccia sia dello stato di navigator.onLine sia del fatto che l'hit sia stato ripetuto dal service worker a causa di un errore di rete iniziale. In questo modo, avremo un quadro più preciso del vero utilizzo offline.

In sintesi

Questo caso di studio ha dimostrato che l'utilizzo di service worker ha effettivamente migliorato le prestazioni di caricamento della web app Google I/O su una vasta gamma di browser, reti e dispositivi. È emerso inoltre che, quando esamini una distribuzione dei dati di caricamento su una vasta gamma di browser, reti e dispositivi, ottieni molte più informazioni su come questa tecnologia gestisce gli scenari reali e scopri caratteristiche di prestazioni che potresti non aver previsto.

Ecco alcuni dei concetti chiave emersi dallo studio IOWA:

• In media, le pagine si caricavano molto più velocemente quando erano controllate da un service worker rispetto a quando non lo erano, sia per i visitatori nuovi che di ritorno.
• Le visite alle pagine controllate da un service worker si caricavano quasi istantaneamente per molti utenti.
• Quando non sono attivi, i worker di servizio richiedono un po' di tempo per l'avvio. Tuttavia, un service worker inattivo ha comunque registrato un rendimento migliore rispetto a un servizio senza service worker.
• Il tempo di avvio di un service worker inattivo era più lungo sui dispositivi mobili rispetto ai computer.

Sebbene i miglioramenti delle prestazioni osservati in una particolare applicazione siano generalmente utili da segnalare alla più ampia community di sviluppatori, è importante ricordare che questi risultati sono specifici per il tipo di sito che IOWA è (un sito di eventi) e il tipo di pubblico di IOWA (principalmente sviluppatori).

Se stai implementando il servizio worker nella tua applicazione, è importante che implementi la tua strategia di misurazione per poter valutare il tuo rendimento ed evitare una futura regressione. In questo caso, condividi i risultati in modo che tutti possano trarne vantaggio.

Note a piè di pagina

1. Non è del tutto corretto confrontare le prestazioni dell'implementazione della cache del nostro service worker con quelle del nostro sito con solo la cache HTTP. Poiché stavamo ottimizzando IOWA per i worker di servizio, non abbiamo dedicato molto tempo all'ottimizzazione per la cache HTTP. Se l'avessimo fatto, i risultati probabilmente sarebbero stati diversi. Per scoprire di più sull'ottimizzazione del sito per la cache HTTP, leggi l'articolo Ottimizzare i contenuti in modo efficiente.
2. A seconda di come il tuo sito carica gli stili e i contenuti, è possibile che il browser sia in grado di eseguire la pittura prima che i contenuti o gli stili siano disponibili. In questi casi, firstpaint potrebbe corrispondere a una schermata bianca vuota. Se utilizzi firstpaint, è importante assicurarti che corrisponda a un punto significativo nel caricamento delle risorse del tuo sito.
3. Tecnicamente, potremmo inviare un hit timing (che per impostazione predefinita non è un'interazione) per acquisire queste informazioni anziché un evento. Infatti, i hit relativi ai tempi sono stati aggiunti a Google Analytics appositamente per monitorare le metriche di caricamento come questa. Tuttavia, i hit relativi ai tempi vengono sottoposti a un campionamento elevato al momento dell'elaborazione e i relativi valori non possono essere utilizzati nei segmenti. Date queste limitazioni attuali, gli eventi non di interazione rimangono più adatti.
4. Per capire meglio quale ambito assegnare a una dimensione personalizzata in Google Analytics, consulta la sezione Dimensione personalizzata del Centro assistenza Analytics. È inoltre importante comprendere il modello di dati di Google Analytics, composto da utenti, sessioni e interazioni (hit). Per ulteriori informazioni, guarda la lezione di Analytics Academy sul modello di dati di Google Analytics.
5. Non vengono prese in considerazione le risorse caricate tramite caricamento lento dopo l'evento di caricamento.