Prácticas recomendadas para determinar el tiempo del registro de tu service worker.
Servicio trabajadores puede acelerar significativamente las visitas repetidas a su aplicación web, pero debe para garantizar que la instalación inicial de un service worker la primera visita del usuario.
En general, aplazar los service workers registro hasta que se cargue la página inicial proporcionará la mejor experiencia para en especial, aquellos que usan dispositivos móviles con conexiones de red más lentas.
Código estándar común de registro
Si ya leíste sobre los service workers, es probable que te hayas encontrado código estándar sustancialmente similar al siguiente:
if ('serviceWorker' in navigator) {
navigator.serviceWorker.register('/service-worker.js');
}
A veces, puede estar acompañado de algunas sentencias console.log().
código
que detecta una actualización en un registro de service worker anterior, como una forma de
informar a los usuarios que actualicen la página. Pero esas son solo pequeñas variaciones
las pocas líneas de código estándar.
¿navigator.serviceWorker.register tiene alguna diferencia? ¿Existe
las prácticas recomendadas que se deben seguir? No es de extrañar (dado que el artículo no termina
aquí), la respuesta a ambas preguntas es "¡sí!".
La primera visita de un usuario
Consideremos la primera visita del usuario a una aplicación web. Todavía no hay un service worker y el navegador no tiene forma de saber si habrá un servicio trabajador que finalmente se instala.
Como desarrollador, tu prioridad debe ser asegurarte de que el navegador obtiene el conjunto mínimo de recursos críticos necesarios para mostrar una . Cualquier elemento que ralentice la recuperación de esas respuestas es enemigo. una experiencia interactiva más rápida.
Ahora imagina que en el proceso de descarga de JavaScript o las imágenes que se debe renderizar la página, el navegador decide iniciar un subproceso en segundo plano o (para abreviar, supondremos que es un subproceso). Supongamos que No tienes una computadora de escritorio potente, sino un tipo de computadora poco potente. móvil que gran parte del mundo considera su dispositivo principal. Acelerando este subproceso adicional, agrega contención por el tiempo de CPU y la memoria que su navegador que, de otro modo, invertirían en renderizar una página web interactiva.
Es poco probable que un subproceso en segundo plano inactivo haga una diferencia significativa. Pero lo que si ese subproceso no está inactivo, pero decide que también va a empezar descargando recursos de la red? Cualquier inquietud sobre la CPU o la memoria la contención debería ocupar un segundo plano frente a las preocupaciones sobre el ancho de banda limitado disponibles para muchos dispositivos móviles. El ancho de banda es un bien preciado, así que no lo perjudiques recursos críticos mediante la descarga de recursos secundarios al mismo tiempo.
Esto quiere decir que se inicia un nuevo subproceso de service worker para descargar y los recursos almacenados en caché en segundo plano pueden ir en contra del objetivo de proporcionar la experiencia interactiva más breve la primera vez que un usuario visita su .
Mejorar el modelo
La solución es controlar el inicio del service worker eligiendo cuándo llamar
navigator.serviceWorker.register() Una regla general simple es retrasar
registro hasta después del load
event
se activa en window de la siguiente manera:
if ('serviceWorker' in navigator) {
window.addEventListener('load', function() {
navigator.serviceWorker.register('/service-worker.js');
});
}
Pero el momento adecuado para iniciar el registro del service worker también puede depender sobre lo que hace tu aplicación web inmediatamente después de que se carga. Por ejemplo, el Google I/O App web de 2016 muestra una breve animación antes de pasar a la pantalla principal. Nuestro equipo encontraste que lanzar el registro del service worker durante la animación podría generar bloqueos en dispositivos móviles de baja gama. En lugar de brindarles a los usuarios una mala experiencia, retrasado el registro del service worker hasta después de la animación, cuando el navegador tengan algunos segundos de inactividad.
Del mismo modo, si tu app web usa un framework que realiza configuraciones adicionales después de la página se cargó, busca un evento específico del framework que indique cuándo se el trabajo.
Visitas posteriores
Hasta ahora, nos enfocamos en la experiencia de la primera visita, pero ¿El registro de service worker tiene demoras en las visitas repetidas a tu sitio? Aunque podría sorprender a algunas personas, no debería haber ningún impacto en absoluto.
Cuando se registra un service worker, pasa por install y
Ciclo de vida de activate
eventos.
Una vez que se activa el service worker, puede controlar los eventos fetch de cualquier
las visitas posteriores a tu app web. El service worker se inicia antes de
para cualquier página dentro de su alcance, lo que tiene sentido cuando piensa
al respecto. Si el service worker existente no se ejecutaba antes
si visitas una página, no tendría la oportunidad de cumplir con los eventos fetch de
las solicitudes de navegación.
Una vez que hay un service worker activo, no importa cuándo llamas
navigator.serviceWorker.register() o, de hecho, si lo llamas en absoluto.
A menos que cambies la URL de la secuencia de comandos del service worker,
navigator.serviceWorker.register() es efectivamente un
no-op en las visitas posteriores. Cuando sea
a los que llamamos es irrelevante.
Motivos para registrarse con anticipación
¿Hay alguna situación en la que se registre el service worker tan pronto como
es posible? Uno que se me viene a la mente
es cuando tu service worker usa
clients.claim()
para controlar la página la primera visita, y el service worker
realiza un entorno de ejecución de forma agresiva
almacenamiento en caché
dentro de su controlador fetch. En ese caso, hay una
la ventaja de activar el service worker lo más rápido posible, para intentar
propagará sus cachés de tiempo de ejecución con recursos que podrían ser útiles más adelante. Si
tu aplicación web pertenece a esta categoría, vale la pena dar un paso atrás para asegurarte de que
asegúrate de que el controlador install de tu service worker no solicite
que luchan por el ancho de banda
con las solicitudes de la página principal.
Realizando pruebas
Una buena forma de simular una primera visita es abrir tu aplicación web en un navegador Chrome Incógnito ventana, y observar el tráfico de red en la red de Chrome Herramientas para desarrolladores. En la Web desarrollador, probablemente vuelvas a cargar una instancia local de tu app web decenas y decenas de veces al día. Pero si vuelve a visitar su sitio cuando ya hay una service worker y cachés completamente propagadas, no tendrás la misma experiencia que un usuario nuevo tendría. Es fácil pasar por alto problemas potenciales.
Este es un ejemplo con la diferencia que podría tener el horario de registro que quieres. Ambas capturas de pantalla se toman cuando se visita un ejemplo app en Modo Incógnito con limitación de red para simular una conexión lenta.
La captura de pantalla anterior refleja el tráfico de red cuando se modificó la muestra.
para realizar el registro de service worker lo antes posible. Puedes ver
las solicitudes de almacenamiento previo en caché (las entradas con el ícono de
ícono
a su lado, que se originan en el controlador install del service worker)
se intercalan con solicitudes de los otros recursos necesarios para mostrar la página.
En la captura de pantalla anterior, el registro del service worker se retrasó hasta después de
se había cargado la página. Puedes ver que las solicitudes de almacenamiento previo en caché
los recursos se recuperaron de la red, lo que elimina cualquier contención por
ancho de banda. Además, debido a que algunos de los elementos que almacenamos previamente en caché ya están
la caché HTTP del navegador: los elementos con (from disk cache) en el tamaño
podemos propagar la caché del service worker sin tener que ir al
red de nuevo.
Puntos adicionales si ejecutas este tipo de prueba desde un dispositivo real de gama baja en un red móvil real. Puedes aprovechar la depuración remota de Chrome capacidades para conectar un teléfono Android a tu computadora de escritorio mediante USB y asegúrate de que el las pruebas que estás ejecutando reflejan la experiencia real de muchos de tus usuarios.
Conclusión
En resumen, asegúrate de que los usuarios tengan la mejor experiencia durante la primera visita debe ser una prioridad. Retrasar el registro del service worker hasta después de durante la primera visita puede ayudar a garantizar eso. Obtendrás todos los beneficios de tener un service worker para las visitas repetidas.
Una forma directa de asegurarte de retrasar la ejecución hasta que la primera página se cargue es utilizar lo siguiente:
if ('serviceWorker' in navigator) {
window.addEventListener('load', function() {
navigator.serviceWorker.register('/service-worker.js');
});
}