Medir el rendimiento de un service worker

Aparte de que Jake Archibald se preocupa de que sus habilidades de desarrollador se pudren y decaen, afirmó firmemente que, si se usa de manera inteligente un service worker, se puede mejorar drásticamente el rendimiento de tu sitio o app. Mira el video para obtener una descripción general.

Si vas a aumentar el tiempo de carga de la página, como sugiere Jake, debes poder entender cómo los service workers afectan las solicitudes de la página.

Resource Timing y la API de User Timing son componentes fundamentales en la infraestructura de RUM (supervisión de usuarios reales) de muchos sitios, ya que te permiten comprender de manera integral cómo ven todos los usuarios el rendimiento del sitio (otro caso de uso es detectar la inserción de contenido). En pocas palabras, te permite comprender casi todos los aspectos de cada solicitud web que se hace desde tu sitio, a menos que tengas un service worker o un trabajador web.

A continuación, se muestra un ejemplo rápido de cómo se puede usar para obtener una lista de todas las solicitudes que se realizaron a un dominio que no es el actual.

var getThirdPartyRequests = function() {
    var thirdPartyRequests = [];
    var requests = window.performance.getEntriesByType("resource");
    
    var currentHost = window.location.host

    for(var requestIdx = 0; requestIdx < requests.length; requestIdx++) {
    var request = requests[requestIdx];
    var url = new URL(request.name);
    var host = url.host;

    if(host != currentHost) {
        thirdPartyRequests.push(request);
    }
    }
    
    return thirdPartyRequests;
};

Las APIs de Resource Timing y User Timing se crearon y se implementaron antes de que el service worker fuera un destello para un ingeniero y el código anterior no permitiría comprender el impacto que tenía el service worker.

Un conjunto reciente de cambios en Chrome 45 (versión beta en julio de 2015) te ayudará a introducir la capacidad de que todas las formas de trabajadores (Web y service worker) tengan acceso a las APIs de Resource Timing y User Timing y, por lo tanto, te permitirán mantenerte al tanto del rendimiento de la red de todos tus usuarios.

Accede a las métricas de rendimiento desde un Service Worker

El cambio más importante es la adición del objeto performance al contexto de trabajadores (Web y ServiceWorkers), que ahora te permitirá comprender los tiempos de rendimiento de todas las solicitudes que se realizan en el contexto del trabajador y también te permitirá establecer tus propias marcas para la medición de la ejecución de JS. Si solo puedes ver lo que sucede en el contexto de la ventana actual, te perderías la información importante sobre el tiempo:

  • Solicitudes fetch() realizadas dentro del evento oninstall del service worker
  • Ahora se puede hacer un seguimiento de las solicitudes fetch() que se realizan cuando se almacenan datos en caché en un evento onpush para comprender el rendimiento que ven los usuarios.
  • Por último, la solicitud fetch() que realiza y, luego, intercepta el controlador onfetch.

El último punto es importante. Un service worker es como un proxy ubicado entre la IU web y la red. El objeto performance de window solo ve los tiempos y la información de la parte de la solicitud que invoca; no tiene conocimiento del service worker que se encuentra entre el cliente y la red, por lo que no puede comprender el impacto del service worker.

¿Cómo se usa?

Un service worker típico que primero admite el uso sin conexión tendría un paso de instalación en el que descargará y guardará todos los recursos para usarlos más tarde

Un ejemplo de dónde se podría usar esto es registrar y registrar los datos de tiempo del paso de instalación para que puedas tomar decisiones medidas sobre cómo mejorar el rendimiento de la instalación en función del uso real del usuario.

self.addEventListener("install", function() {
    var urls = [
    '/',
    '/images/chrome-touch-icon-192x192.png',
    '/images/ic_add_24px.svg',
    '/images/side-nav-bg@2x.jpg',
    '/images/superfail.svg',
    '/scripts/voicememo-core.js',
    '/styles/voicememo-core.css',
    '/third_party/Recorderjs/recorder.js',
    '/third_party/Recorderjs/recorderWorker.js',
    '/third_party/Recorderjs/wavepcm.js',
    '/third_party/moment.min.js',
    '/favicon.ico',
    '/manifest.json'
    ];

    urls = urls.map(function(url) {
    return new Request(url, {credentials: 'include'});
    });

    event.waitUntil(
    caches
        .open(CACHE_NAME + '-v' + CACHE_VERSION)
        .then(function(cache) {
        // Fetch all the URL's and store in the cache
        return cache.addAll(urls);
        })
        .then(function () {
        // Analyze all the requests
        var requests = self.performance.getEntriesByType("resource");
        
        // Loop across all the requests and save the timing data.
        return;
        })
    );
});

En la actualidad, muchos sitios usan RUM para comprender cómo es la experiencia de la mayoría de los usuarios. Las herramientas como Google Analytics ya informan los datos de velocidad del sitio con la API de Navigation Timing, pero se deberán actualizar para incluir el análisis de rendimiento proveniente de un contexto de trabajador.

¿Llegará la API de Navigation Timing a los service workers?

En este momento, no hay planes para agregar la API de Navigation Timing al contexto del service worker, ya que no hay navegaciones tradicionales en un service worker. Lo interesante es que para el service worker, cada navegación en el conjunto controlado de páginas del service worker parece una recuperación de recursos. Por sí solo, esto hace que los service workers sean una forma increíblemente atractiva de centralizar la mayoría de la lógica de rendimiento en tu app web.

¿Puedo ver lo que cambió?

Estoy interesado en la conversación y las especificaciones