Además de que Jake Archibald se preocupa por que sus habilidades de desarrollador se debiliten y desaparezcan, hizo un argumento sólido de que, si usas el trabajador de servicio de forma inteligente, puedes mejorar de forma drástica el rendimiento de tu sitio o aplicación. Mira el video para obtener una descripción general.
Si quieres mejorar el tiempo de carga de tu página como sugiere Jake, debes comprender cómo los trabajadores del servicio afectan las solicitudes de tu página.
La API de Resource Timing y User Timing son componentes fundamentales en la infraestructura de RUM (supervisión real del usuario) de muchos sitios, ya que te permiten comprender de forma integral cómo todos tus usuarios ven el rendimiento de tu sitio (otro caso de uso es detectar la inserción de contenido). En resumen, te permite comprender casi todos los aspectos de cada solicitud web que se realiza desde tu sitio, a menos que tengas un trabajador de servicio o un trabajador web.
Este es 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 dominio 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 e implementaron antes de que el trabajador de servicio fuera un destello en el ojo de un ingeniero, y el código anterior no podría comprender cómo lo afectó el trabajador de servicio.
Un conjunto reciente de cambios en Chrome 45 (beta en julio de 2015) te ayudará, ya que presenta 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, de esta manera, te permitirá mantenerte al tanto del rendimiento de la red para todos tus usuarios.
Cómo acceder a las métricas de rendimiento desde un trabajador de servicio
El mayor cambio es la adición del objeto performance a un 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 desde el contexto de la ventana actual, te perderás información de sincronización crítica de lo siguiente:
- Solicitudes de
fetch()realizadas dentro del eventooninstalldel trabajador de servicio - Ahora se puede hacer un seguimiento de las solicitudes de
fetch()que se realizan cuando se almacenan en caché datos en un eventoonpushpara comprender el rendimiento que ven tus usuarios. - Por último, la solicitud
fetch()que realiza y intercepta el controladoronfetch.
El último punto es importante. Una forma de pensar en un service worker es como un proxy que se encuentra entre la IU web y la red. El objeto performance en window solo ve los tiempos y la información de la parte de la solicitud que invoca. No tiene conocimiento del trabajador de servicio que se encuentra entre el cliente y la red, por lo que no puede comprender el impacto del trabajador de servicio.
¿Cómo puedo usar esto?
Un trabajador de servicio típico que admita primero sin conexión tendría un paso de instalación en el que descargará y guardará todos los recursos para usarlos más adelante.
Un ejemplo de dónde se podría usar esto es para registrar y registrar los datos de tiempo del paso de instalación, de modo que puedas tomar algunas decisiones medidas sobre cómo mejorar el rendimiento de la instalación en función del uso real de los usuarios.
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;
})
);
});
Actualmente, muchos sitios usan el RUM para comprender cómo la mayoría de los usuarios experimentan su sitio. Herramientas como Google Analytics ya informan datos de velocidad del sitio con la API de Navigation Timing, pero deberán actualizarse para incluir el análisis de rendimiento desde 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 servicio de trabajo, ya que no hay navegaciones tradicionales en un servicio de trabajo. Lo interesante es que, para el service worker, cada navegación en el conjunto controlado de páginas del service worker se ve como una recuperación de recursos. Esto por sí solo hace que los service workers sean una forma increíblemente atractiva de centralizar la mayoría de tu lógica de rendimiento en tu app web.