Recursos y datos

Una app web progresiva es un sitio web. Todos sus recursos son los mismos que en la Web, pero con herramientas nuevas para que esos recursos se carguen rápido cuando estén en línea y estén disponibles sin conexión.

Componentes de la aplicación

Por lo general, el desarrollo de una aplicación implica varios elementos y recursos, desde la lógica y el código (compilados o no) hasta los elementos de la interfaz de usuario, como diseños de pantalla, imágenes, logotipos y fuentes.

Una aplicación web progresiva es un sitio web, por lo que todos sus recursos son los mismos que en la Web:

HTML para la renderización de contenido y página inicial.
JavaScript para lógica, incluida la capacidad de ejecutar módulos de WebAssembly (código compilado) y renderizar gráficos optimizados por hardware en 2D y 3D.
CSS para el diseño, el estilo y las animaciones
Imágenes en formatos web, como PNG, JPEG, WebP y SVG.
Videos en formatos web, como MPEG-4 y WebM
Fuentes web.
Son datos en JSON o en otros formatos.

De forma predeterminada, los sitios web descargan elementos en toda la red, comenzando por HTML y continúa con el resto de los recursos.

Administrar esos recursos para que se carguen rápido y estén disponibles sin conexión ha sido un desafío para la Web. Actualmente, las AWP usan funciones que antes se asociaban solo con apps específicas de la plataforma.

Aplicaciones específicas de la plataforma frente a AWP

Cuando instalas una app específica de una plataforma, en general se descarga un paquete que incluye todos los recursos de la app: código, imágenes, fuentes, videos, etcétera. Por lo tanto, todos estos recursos están disponibles en el almacenamiento de tu dispositivo, incluso cuando la app está sin conexión.

Por otro lado, un sitio web clásico necesita una conexión de red para descargar los recursos cuando sea necesario. Si no tienes conexión, verás un error del navegador, ya que no hay recursos del cliente.

El enfoque de AWP mejora la experiencia web tradicional, ya que permite que algunos o todos los recursos estén disponibles del lado del cliente, al igual que con las aplicaciones específicas de la plataforma. Por lo tanto, cuando abres una AWP, la renderización inicial puede ser tan instantánea como una app de plataforma, ya que los recursos están disponibles sin ir a la red.

Caché y almacenamiento

Desde el comienzo de la Web, los desarrolladores no han tenido el control total de cómo se almacena en caché un recurso. El navegador está a cargo de la caché HTTP y puede o no almacenar en caché y entregar recursos según las diferentes políticas. Otras opciones de almacenamiento, como Web Storage e IndexedDB, estaban destinadas a guardar datos y objetos simples.

Las AWP no necesitan basarse solos en esas políticas para su contenido. En cambio, hoy tenemos soluciones para obtener un mejor control sobre cuándo y cómo almacenar recursos en caché, y cuándo y cómo entregarlos de manera local: la API de Cache Storage. En la Web, existen algunas de las soluciones de almacenamiento del cliente disponibles:

Almacenamiento web: Incluye localStorage y sessionStorage. Estas APIs almacenan pares de cadenas simples clave-valor. El almacenamiento web es limitado y tiene una API síncrona, por lo que se debe evitar, siempre que sea posible.
IndexedDB: Es una base de datos basada en objetos (No-SQL) con una API asíncrona que es útil para el rendimiento web. IndexedDB puede almacenar datos binarios y estructurados del cliente. Por lo general, es lo que usarás para almacenar datos, por ejemplo, lo que obtendrías o enviarías como solicitud a la API. También es útil guardar datos de forma local de inmediato y, luego, sincronizarlos con el servidor. La API de IndexedDB se usa para interactuar con la base de datos.
Almacenamiento en caché: Es un conjunto de pares de solicitud y respuesta HTTP que puedes usar para almacenar y recuperar recursos (con sus encabezados HTTP) exactamente como se entregan desde el servidor. La API de Cache Storage te permite almacenar, recuperar, actualizar y borrar solicitudes de red, por ejemplo, para tus recursos, incluso sin conexión.

La necesidad de service workers

Una AWP puede almacenar sus elementos en el almacenamiento en caché y en IndexedDB, pero ¿cómo podemos usar esos recursos para brindar una experiencia rápida y sin conexión a tus usuarios? ¿Cuál es la respuesta? Trabajadores de servicio.

Con un service worker, puedes entregar recursos sin tener que ir a la red, enviar notificaciones a un usuario, agregar una insignia al ícono de la AWP, actualizar el contenido en segundo plano y hasta hacer que toda la AWP funcione sin conexión. Obtén más información sobre los service workers en el siguiente capítulo.

Listo sin conexión

Los usuarios esperan que tu aplicación ofrezca una experiencia rápida y siempre lista. Esto significa que tu app debería funcionar sin conexión.

Estar listo para usar sin conexión no significa que todo el contenido o los servicios deban estar disponibles sin una conexión de red. Sin embargo, tener al menos una experiencia básica cuando el usuario está sin conexión, como una página que te pide que te conectes a Internet para continuar, brindará una mejor experiencia del usuario y mantendrá al usuario dentro de la experiencia de tu app en lugar de un error genérico del navegador. En algunos navegadores, esta es una función imprescindible para aprobar los criterios de instalación de la AWP. Es mejor mostrar la interfaz de usuario de tu AWP, junto con el contenido almacenado en caché. Permitir que los usuarios sigan usando toda tu AWP y sincronizar los cambios del servidor cuando vuelven a estar en línea es el estándar de referencia para trabajar sin conexión.

Para que tu app esté disponible sin conexión, deberás almacenar en caché los recursos necesarios para tu experiencia sin conexión y hacer que tu service worker los entregue más tarde. Asegúrate de agregar los recursos sin conexión a tu caché antes de necesitarlos. Este es un caso particular en el que no puedes almacenarlos en caché cuando se solicitan.

Enfoques de caché usados con frecuencia

En tu AWP, estás a cargo de todas las decisiones. Puedes elegir el mejor enfoque para almacenar en caché o instalar recursos según tus necesidades. Estas son algunas decisiones que debes tomar:

Almacenamiento en caché: Selecciona los recursos que deseas instalar en la primera carga. Estos deben incluir el código HTML y los recursos mínimos para procesar la app. Cuando uses el almacenamiento previo en caché, ten en cuenta que usas el espacio y la red del dispositivo. Sé consciente y responsable a la hora de descargar recursos y almacenarlos en caché.
Almacenamiento en caché según sea necesario: Se usa para agregar elementos a la caché cuando se solicitan. Por lo general, son recursos que, como imágenes o contenido, pueden cambiar independientemente de la versión de la app. Consulta la sección Almacenamiento en caché para ver diferentes estrategias de almacenamiento en caché según sea necesario.
APIs y servicios web: Las llamadas a la API se pueden almacenar en caché. O bien, en lugar de almacenar en caché las respuestas de la API, puedes almacenar sus datos en IndexedDB.

Actualizando elementos

En el modelo estándar de apps instaladas del catálogo de apps, cuando los desarrolladores necesitan actualizar su app, publican un paquete nuevo. Los usuarios deben volver a descargar todo el paquete, incluso si la mayoría de los recursos no cambiaron. En el caso de las AWP, utilizando los enfoques de la sección anterior, tú decides cómo y cuándo actualizar los recursos. Aquí te presentamos distintas opciones para actualizar activos:

Actualización completa: En este caso, cada vez que realices un cambio en la app, incluso uno menor, tu código volverá a descargar todos los recursos en la caché.
Actualización parcial: En este enfoque, creas un método para definir qué elementos se actualizaron y solo actualizas esos elementos, con o sin la intervención del usuario.
Actualización continua: Con esta técnica, se verificarán y actualizarán tus recursos automáticamente en cada uso de la AWP de manera individual.

Tamaño y esperanza de vida

Por lo general, las apps específicas de la plataforma no tienen límites de tamaño. Durante la instalación, las apps pueden tener un tamaño de gigabytes o más. Se permitirá la instalación siempre que el dispositivo tenga la capacidad necesaria. Además, mientras la app esté instalada, utilizará esa cantidad total de almacenamiento independientemente de si la usas o no. El almacenamiento se maneja de manera diferente para las AWP. El navegador almacenará tus recursos según las políticas que definas en la lógica de tu AWP.

Los límites de tamaño dependen del navegador. No es tan flexible como las apps específicas de una plataforma, pero suele ser lo suficientemente bueno para la mayoría de las apps web. Puedes consultar las limitaciones específicas por navegador en este artículo.

Los navegadores pueden expulsar activos en función de la presión de almacenamiento o, después de algunas semanas de inactividad, si el usuario usa tu AWP en el navegador. En algunas plataformas, si el usuario instala tu AWP, no se producirá la expulsión. Cuando está disponible, el código puede solicitar almacenamiento continuo a través de una API para evitar esa expulsión.