Responda a las solicitudes de navegación sin esperar en la red utilizando un trabajador de servicio.
Confiabilidad de la red
Las solicitudes de navegación son solicitudes de documentos HTML realizadas por su navegador cada vez que ingresa una nueva URL en la barra de navegación o sigue un enlace en una página que lo lleva a una nueva URL. Aquí es donde los trabajadores del servicio tienen su mayor impacto en el rendimiento: si utiliza un trabajador del servicio para responder a las solicitudes de navegación sin esperar a la red, puede asegurarse de que las navegaciones sean rápidas y confiables, además de ser resistentes cuando la red no está disponible. Esta es la ganancia de rendimiento más grande que proviene de un trabajador de servicios, en comparación con lo que es posible con el almacenamiento en caché HTTP.
Como se detalla en la guía Identificar recursos cargados desde la red, una solicitud de navegación es la primera de muchas solicitudes potencialmente realizadas en el
«cascada»
del tráfico de la red. El HTML que carga a través de una solicitud de navegación inicia el flujo de todas las demás solicitudes de subrecursos como imágenes, scripts y estilos.
Dentro de un trabajador de servicios fetch controlador de eventos, puede determinar si una solicitud es una navegación marcando el request.mode propiedad en el FetchEvent. Si está configurado para 'navigate', entonces es una solicitud de navegación.
Como regla general, no use de larga duración Cache-Control headers para almacenar en caché la respuesta HTML para una solicitud de navegación. Normalmente deberían satisfacerse a través de la red, con
Cache-Control: no-cache, para garantizar que el HTML, junto con la cadena de solicitudes de red posteriores, sea (razonablemente) actualizado. Ir en contra de la red cada vez que el usuario navega a una nueva página, lamentablemente significa que cada navegación podría Sé lento. Como mínimo, significa que no será seguramente rápido.
Cache-Control: no-cache significa que el navegador debe verificar (o «revalidar») con el servidor antes de usar un recurso previamente almacenado en caché. Esto requiere que se complete una comunicación de red de ida y vuelta antes de que se pueda usar el recurso.
Diferentes enfoques para arquitecturas
Averiguar cómo responder a las solicitudes de navegación evitando la red puede resultar complicado. El enfoque correcto depende en gran medida de la arquitectura de su sitio web y de la cantidad de URL únicas a las que los usuarios pueden acceder.
Si bien no existe una solución única para todos, las siguientes pautas generales deberían ayudarlo a decidir qué enfoque es el más viable.
Pequeños sitios estáticos
Si su aplicación web consta de un número relativamente pequeño (piense: un par de docenas) de URL únicas, y cada una de esas URL corresponde a un archivo HTML estático diferente, entonces un enfoque viable es almacenar en caché todos esos archivos HTML y responder a las solicitudes de navegación con el HTML en caché apropiado.
Con el almacenamiento en caché, puede almacenar en caché el HTML por adelantado, tan pronto como se instale el trabajador del servicio, y actualizar el HTML almacenado en caché cada vez que reconstruya su sitio y vuelva a implementar su trabajador del servicio.
Alternativamente, si prefiere evitar el almacenamiento en caché de todo su HTML, tal vez porque los usuarios tienden a navegar solo a un subconjunto de URL en su sitio, puede utilizar una estrategia de almacenamiento en caché en tiempo de ejecución obsoleto mientras se revalida. Sin embargo, tenga cuidado con este enfoque, ya que cada documento HTML individual se almacena en caché y se actualiza por separado. El uso del almacenamiento en caché en tiempo de ejecución para HTML es más apropiado si tiene una pequeña cantidad de URL que se revisan frecuentemente por el mismo conjunto de usuarios, y si se siente cómodo con la revalidación de esas URL de forma independiente entre sí.
Aplicaciones de una sola página
Las aplicaciones web modernas utilizan con frecuencia una arquitectura de una sola página. En él, JavaScript del lado del cliente modifica el HTML en respuesta a las acciones del usuario. Este modelo utiliza el API de historial para modificar la URL actual a medida que el usuario interactúa con la aplicación web, lo que lleva a lo que efectivamente es una navegación «simulada». Si bien las navegaciones posteriores pueden ser «falsas», la navegación inicial es real y aún es importante asegurarse de que no esté bloqueada en la red.
Afortunadamente, si está utilizando la arquitectura de una sola página, hay un patrón sencillo a seguir para servir la navegación inicial desde el caché: el shell de la aplicación. En este modelo, su trabajador del servicio responde a las solicitudes de navegación devolviendo el mismo archivo HTML único que ya se ha almacenado en caché, independientemente de la URL solicitada. Este HTML debería ser básico y consistir, quizás, en un indicador de carga genérico o contenido esqueleto. Una vez que el navegador ha cargado este HTML desde la caché, su JavaScript existente del lado del cliente toma el control y muestra el contenido HTML correcto para la URL de la solicitud de navegación original.
Workbox proporciona las herramientas que necesita para implementar este enfoque; el navigateFallback
option
le permite especificar qué documento HTML usar como shell de su aplicación, junto con una lista opcional de permitir y denegar para limitar este comportamiento a un subconjunto de sus URL.
Aplicaciones de varias páginas
Si su servidor web genera el HTML de su sitio de forma dinámica, o si tiene más de unas pocas docenas de páginas únicas, entonces es mucho más difícil evitar la red al manejar las solicitudes de navegación. Es probable que los consejos de Todo lo demás se apliquen a usted.
Pero para un determinado subconjunto de aplicaciones de varias páginas, es posible que pueda implementar un trabajador de servicio que reproduzca completamente la lógica utilizada en su servidor web para generar HTML. Esto funciona mejor si puede compartir información de enrutamiento y plantillas entre el servidor y los entornos del trabajador del servicio y, en particular, si su servidor web usa JavaScript (sin depender de
Node.js-características específicas, como el acceso al sistema de archivos).
Si su servidor web entra en esa categoría y le gustaría explorar un enfoque para mover la generación de HTML fuera de la red a su trabajador de servicio, la guía en Más allá de los SPA: arquitecturas alternativas para su PWA puede ayudarte a empezar.
Todo lo demas
Si no puede responder a las solicitudes de navegación con HTML almacenado en caché, debe tomar medidas para asegurarse de que agregar un trabajador de servicio a su sitio (para manejar otras solicitudes que no sean HTML) no ralentice sus navegaciones. Iniciar el service worker sin usarlo para responder a una solicitud de navegación introducirá una pequeña cantidad de latencia (como se explica en Creación de aplicaciones más rápidas y resistentes con Service Worker). Puede mitigar esta sobrecarga habilitando una función llamada precarga de navegación, y entonces usando la respuesta de la red
que ha sido precargado dentro de tu fetch controlador de eventos.
Neceser de costura proporciona una biblioteca auxiliar esa función detecta si se admite la precarga de navegación y, de ser así, simplifica el proceso de decirle a su trabajador de servicio que use la respuesta de red.
Foto por Aaron Burden en Unsplash,
