Lógica de detección de soporte sin conexión de la aplicación web progresiva para el navegador Chrome

Las aplicaciones web progresivas (PWA) son aplicaciones instalables creadas para dispositivos móviles y de escritorio que utilizan tecnología web (están diseñadas para funcionar en cualquier plataforma estándar). Los PWA son altamente confiables incluso en condiciones de red inestables.

Lo más interesante: ¡la aplicación web integrada en cualquier pila tecnológica se puede convertir en una aplicación web progresiva!

Las ventajas de la aplicación web progresiva incluyen:

• Aspecto, sensación y funciones similares a las de una aplicación (agregar a la pantalla de inicio, notificaciones automáticas)
• Accesibilidad sin conexión
• Sin problemas de actualización (actualización automática)
• Fácil instalación en cualquier dispositivo
• Motor de búsqueda optimizado
• Tiempo de carga corto
• Mejor presentación
• multiplataforma
• Bajo uso de datos
• Sensible

Las aplicaciones web que cumplen con todos los criterios básicos de la instalabilidad de la aplicación web progresiva, incluida la compatibilidad con un modo fuera de línea, se pueden instalar en el dispositivo desde el navegador.

En este artículo, hay una explicación justa sobre cómo funciona exactamente la detección fuera de línea en PWA.

• La aplicación debe continuar funcionando incluso en modo sin conexión simplemente significa que, incluso si el usuario pierde el acceso a la red de su dispositivo, no aparece Google Dino runner (T-Rex Game) en la pantalla. Incluso si no hay conexión de red, el usuario puede navegar a través de la aplicación y puede ver el contenido.
  

  Corredor de dinosaurios

• Para hacer que PWA sea instalable, primero se verifica si la aplicación web contiene un trabajador de servicio con un controlador de eventos de búsqueda . Cuando cargamos la aplicación web, se inicia una solicitud de búsqueda para obtener la página de índice y luego se procesa en el navegador. Aquí, tenemos un trabajador de servicio que actúa como un proxy entre la aplicación y el servidor. Service Worker es solo un archivo javascript que se ejecuta en segundo plano. También es conocido como el corazón de PWA. Se ejecuta por separado del hilo del navegador principal. Por lo tanto, no hay interacción entre la página web y el usuario con los trabajadores del servicio.
  
• Ahora, habilitaremos la capacidad de las aplicaciones web para cargar contenido sin conexión en lugar de cargar la página de error predeterminada.
• Para esto, estaríamos almacenando activos localmente en el almacenamiento en caché (después de inspeccionar la página, navegue a la sección Aplicación para ver el almacenamiento en caché), para que podamos acceder a ellos cuando los necesitemos, es decir, en modo fuera de línea.
• Hay diferentes tipos de cachés que controlan el almacenamiento de recursos y activos de una aplicación web, uno de ellos es el caché del navegador.
  • Caché del navegador (funciona automáticamente): acelera el sitio web al almacenar en caché recursos como archivos CSS, imágenes, etc. para que no tengamos que descargarlos cada vez que se carga la página web. El único problema aquí es que no podemos controlar qué almacenar y qué no almacenar en caché. Por lo tanto, sería mejor deshabilitar el caché del navegador.
• Estamos usando otro caché que podemos controlar usando Service Workers y Javascript regular. Podemos controlar y administrar qué recursos deben almacenarse en el caché para aumentar el rendimiento de la aplicación web. Más tarde podemos recuperarlos cuando sea necesario (es decir, fuera de línea).
• Inicialmente, la memoria caché está vacía. El primer trabajador de servicio se carga, solicita al servidor que obtenga algunos activos principales que solicita la aplicación web. Los activos incluyen imágenes, archivos de estilo CSS, archivos javascript, etc. El trabajador del servicio luego devuelve todos estos activos y los almacena en caché también, ¡ya que podrían ser útiles en el futuro! Esto se llama Pre-caching . Todos estos activos en caché se almacenan localmente.
• En caso de que perdamos la conexión de red, el trabajador del servicio aún realizará una solicitud al servidor para obtener recursos, pero nunca llegará al lado del servidor. Ahora, es posible obtener recursos sin conexión a la red utilizando activos almacenados previamente en caché.
• El trabajador del servicio interrumpirá estas requests de recuperación que se realizan al servidor (en palabras simples, los trabajadores del servicio le dicen a las requests de recuperación que no hay una conexión de red disponible, por lo tanto, ya no es necesario ir al servidor para obtener recursos). El propio trabajador del servicio busca en los activos almacenados previamente en caché y devuelve los recursos al navegador web.
• ¡Esto permite al usuario navegar a través de la aplicación incluso en modo fuera de línea y también puede ver el contenido/recursos!
  

Nota: ACTUALIZACIÓN EN DETECCIÓN SIN CONEXIÓN DESDE AGOSTO’21

• Esta fue la verificación de verificación seguida anteriormente (¡y se seguirá hasta agosto de 2021 solamente!). Si ha creado una aplicación web progresiva, ahora notará la advertencia en Chrome 89 después de auditar (generar un informe) a través de Lighthouse. se ha iniciado una advertencia desde marzo de 2021 .
• Se introducirán ciertos controles nuevos a partir de mediados de 2021 porque:
  • No es posible que Chrome verifique el comportamiento sin conexión correcto de las aplicaciones web, ya que no existe la posibilidad de verificar el estado de las requests HTTP a través del trabajador del servicio.
  • Cuando verificamos la compatibilidad del modo fuera de línea de la aplicación web, Chrome solo verifica si el trabajador del servicio tiene el controlador de eventos de búsqueda o no, pero ese no es el único caso.
  • Debe verificarse si el controlador de eventos de recuperación devuelve recursos válidos con HTTP 200 (código de estado de éxito) cuando está en modo fuera de línea.
• Si ya ha implementado el modo fuera de línea de manera correcta, no se deben volver a realizar cambios.
• O bien, si su controlador de recuperación no funciona correctamente y no devuelve un código de estado de respuesta de 200 a través de requests HTTP, entonces esa aplicación debe actualizarse con los últimos criterios requeridos.