Tu primera Progressive Web App

1) Introducción

1.1) ¿Qué hace de una aplicación web, una Progressive Web Aplicación?

Las Progressive Web Aplicaciones dan un instalable, experiencia de aplicación como en ordenadores de escritorio y móviles que se crean y entregan de forma directa a través de la página web. Son aplicaciones web que son rápidas y fiables. Y lo más esencial, son aplicaciones web que funcionan en cualquier navegador. Si estás creando una aplicación web hoy, ya estás en el camino cara la creación de una Progressive Web App.

1.1.1) Rápida y Confiable

Toda experiencia web debe ser rápida, y esto es especialmente cierto para las Progressive Web Aplicaciones. Rápida se refiere al tiempo que se tarda en obtener contenido significativo en la pantalla y brinda una experiencia interactiva en menos de cinco segundos.

Y, ha de ser confiablemente rápido. Es difícil enfatizar lo bastante lo bueno que es el desempeño fiable. Piénsalo de esta manera: la primera carga de una aplicación nativa es frustrante. Está recluído por una tienda de aplicaciones y una descarga enorme, pero en el momento en que llegas al punto de instalar la aplicación, ese costo inicial se amortiza en todos los comienzos de la aplicación, y ninguno de esos principios tiene un retraso variable. Cada comienzo de aplicación es tan rápido como el último, sin variación. Una Progressive Web Aplicación debe ofrecer este desempeño fiable que los usuarios esperan de cualquier experiencia instalada.

1.1.2) Instalable

Las Progressive Web Aplicaciones pueden ejecutarse en una pestaña del navegador, pero también son instalables. Añadir a marcadores un sitio simplemente añade un acceso directo, pero una Progressive Web Aplicación instalada se ve y se comporta como todas y cada una de las demás aplicaciones instaladas. Se inicia desde exactamente el mismo lugar que se lanzan otras aplicaciones. Puedes supervisar la experiencia de lanzamiento, incluida una pantalla de comienzo personalizada, iconos y más. Se ejecuta como una aplicación, en una ventana de aplicación sin una barra de direcciones u otra interfaz de usuario del navegador. Y como todas y cada una de las demás aplicaciones instaladas, es una aplicación de nivel superior en el gestor de tareas.

Recuerda, es fundamental que una PWA instalable sea rápida y fiable. Los usuarios que instalan una PWA aguardan que sus aplicaciones funcionen, sin importar en qué género de conexión de red estén conectados. Es una expectativa de referencia que todas y cada una de las aplicaciones instaladas deben cumplir.

1.1.3) Móvil y Escritorio

Mediante el empleo de técnicas de diseño acomodable, las Progressive Web Apps funcionan en el móvil y escritorio, utilizando una base de código única entre plataformas. Si estás considerando escribir una aplicación nativa, eche una ojeada a las ventajas que ofrece una PWA.

1.2) Qué construirás

En este laboratorio de código, vas a edificar una aplicación web meteorológica utilizando las técnicas de una Progressive Web Aplicación. Tu aplicación:

• Usará diseño adaptable, por lo que marcha en escritorio o bien móvil.
• Será rápido, emplea un service worker para guardar en precache los recursos de la aplicación (HTML, CSS, JavaScript, imágenes) precisos para ejecutar y guardar en caché los datos meteorológicos en tiempo de ejecución para mejorar el desempeño.
• Será instalable, utilizando un manifiesto de aplicación web y el acontecimiento beforeinstallprompt para avisar al usuario que es instalable.

1.3) Lo que aprenderás

• Cómo crear y añadir un manifiesto de aplicación web.
• Cómo proporcionar una experiencia sin conexión simple
• Cómo administrar una experiencia sin conexión completa
• Como hacer instalable tu aplicación

Este laboratorio de código está enfocado en Progressive Web Aplicaciones. Los conceptos y los bloques de código no relevantes se pasan por alto y se proporcionan a fin de que usted sencillamente copie y pegue.

1.4) Lo que necesitarás

• Una versión reciente de Google Chrome (setenta y cuatro o bien siguiente) las PWAs son solo aplicaciones web y marchan en todos y cada uno de los navegadores, pero usaremos algunas funciones de Chrome DevTools para entender mejor lo que está sucediendo a el nivel de navegador y usarlo para probar la experiencia de instalación.
• Conocimiento de HTML, CSS, JavaScript y .

2) Preparación

2.1) Consigue una clave para la API de Dark Sky

Nuestros datos meteorológicos provienen de . Para poder usarlo, deberás solicitar una API key. Es fácil de utilizar y sin coste para proyectos no comerciales.

2.1.1) Verifica que tu API key funciona correctamente

Para demostrar que tu API key funciona apropiadamente, efectúa una solicitud HTTP a la API de DarkSky. Actualiza la URL a continuación para sustituir DARKSKY_API_KEY con tu API key. Si todo funciona, debería ver el último pronóstico del tiempo para la ciudad de Nueva York.

/forecast/DARKSKY_API_KEY/40. ,-73.

2.2) Obtén el código

Hemos puesto todo cuanto necesitas para este proyecto en un repositorio de Git. Para comenzar, deberás obtener el código y abrirlo en tu entorno de desarrollo preferido. Para este laboratorio de código, recomendamos emplear Glitch.

2.2.1) Muy recomendable: emplea Glitch para importar el repositorio

Usar Glitch es el método recomendado para trabajar a través de este código.

1. Abre una nueva pestaña del navegador y ve a .
2. Si no tienes una cuenta, deberás registrarte.
3. Haz clic en New Project, entonces Clone from Git Repo.
4. Clone /googlecodelabs/your-first-pwapp.git y Haz click en Accept.
5. Una vez que se haya cargado el repositorio, edita el fichero .env y actualízalo con tu API key DarkSky.
6. HAz clic en el botón Mostrar Live para ver la PWA en acción.

2.2.2) Alternativa: Descargar código y trabajar localmente

Si quieres descargar el código y trabajar de manera local, deberás tener una versión reciente de Node y la configuración del editor de códigos y listo para utilizar.

1. Desempaqueta el archivo zip descargado.
2. Ejecuta npm install para instalar las dependencias precisas para ejecutar el servidor.
3. Edita server.js y configura la API key de DarkSky.
4. Ejecuta node server.js para comenzar el servidor en el puerto ocho mil.
5. Abre una pestaña del navegador en

3) Establecer una línea de base

3.1) ¿Cuál es nuestro punto de partida?

Nuestro punto de partida es una aplicación meteorológica básica diseñada para este laboratorio de código. El código se ha simplificado demasiado para enseñar los conceptos en este laboratorio de código y tiene poco manejo de errores. Si eliges reutilizar algo de este código en una aplicación de producción, asegúrate de manejar cualquier fallo y probar completamente todo el código.

Algunas cosas para probar...

1. Agrega una nueva ciudad con el botón más azul en la esquina inferior derecha.
2. Actualiza los datos con el botón de actualización en la esquina superior derecha.
3. Borra una urbe utilizando la x en la parte superior derecha de cada tarjeta de ciudad.
4. Mira cómo funciona en el escritorio y en el móvil.
5. Mira lo que pasa cuando te desconectas.
6. Usando el panel de la Red de Chrome, mira qué sucede cuando la red se restringe a Slow 3G.
7. Agrega un retraso al servidor de pronóstico mudando FORECAST_DELAY en server.js

3.2) Auditoría con Lighthose

es una herramienta fácil de usar para ayudar a mejorar la calidad de tus sitios y páginas. Cuenta con auditorías de rendimiento, accesibilidad, Progressive Web Aplicaciones y más. Cada auditoría tiene un documento de referencia que explica por qué la auditoría es esencial, así como la forma de solucionarla.

Usaremos Lighthouse para auditar nuestra aplicación Weather y verificar los cambios que hemos realizado.

3.3) Vamos a ejecutar Lighthouse

1. Abre tu proyecto en una nueva pestaña.
2. Abre Chrome DevTools y cambia a la pestaña Audits, DevTools muestra una lista de categorías de auditoría, déjelas todas habilitadas.
3. Haz clic en Ejecutar auditorías, después de segundos, Lighthouse te da un informe en la página.

3.4) La auditoría Progressive Web App

Nos vamos a centrar en los resultados de la auditoría de la Progressive Web App.

Y hay mucho colorado en lo que centrarse:

• ❗FALLADO: La página actual no responde con un doscientos cuando está desconectado.
• ❗FALLADO: start_url no responde con un doscientos cuando está desconectado.
• ❗FALLADO: No registra un service worker que controle la página y start_url.
• ❗FALLADO: El manifiesto de la aplicación web no cumple con los requisitos de instalación.
• ❗FALLADO: No está configurado para una pantalla de inicio personalizada.
• ❗FALLADO: No establece un color de tema de la barra de direcciones.

¡Saltemos y comencemos a solventar ciertos de estos problemas!

4) Añadir un manifiesto de aplicación web

Al final de esta sección, nuestra aplicación meteorológica pasará las próximas auditorías:

• El manifiesto de la aplicación web no cumple con los requisitos de instalación.
• No está configurado para una pantalla de comienzo adaptada.
• No establece un color de tema de la barra de direcciones.

4.1) Crear el manifiesto de la aplicación web.

es un fichero JSON simple que permite que tú, el desarrollador, puedas controlar cómo se muestra tu aplicación al usuario.

Usando el manifiesto de la aplicación web, tu aplicación web puede:

• Indicar al navegador que quieres que se abre tu aplicación en una ventana independiente ( display ).
• Definir qué página se abre cuando la aplicación se inicia por primera vez ( start_url ).
• Definir cómo debería ser la aplicación en el dock o bien lanzador de apps ( short_name, icons ).
• Crear una pantalla de name ( name, icons, colors ).
• Indicar al navegador que abre la ventana en modo horizontal o bien retrato ( orientation ).
• Y .

Crea un fichero llamado public/manifest.json en tu proyecto y copia/pega los próximos contenidos:

public/manifest.json

El manifiesto admite una serie de iconos, destinados a diferentes tamaños de pantalla. Para este laboratorio de código, hemos incluido otros en tanto que los necesitábamos para nuestra integración con iOS.

4.2) Añadir un link al manifiesto de la aplicación web

A continuación, debemos informarle al navegador sobre nuestro manifiesto añadiendo <link rel="manifest"... a cada página de nuestra aplicación. Añade la siguiente línea al elemento <head> en tu archivo index.html.

4.2.1) DevTools, un pequeño desvío

DevTools da una forma rápida y fácil de comprobar tu fichero manifest.json. Abre el panel Manifest en el panel Aplication. Si has agregado la información del manifiesto apropiadamente, podrás verla analizada y mostrada en un formato entendible por los humanos en este panel.

Safari en iOS no acepta el manifiesto de aplicación web (), con lo que deberás agregar al <head> de tu fichero index.html :

4.3) Bonus: arreglos fáciles de Lighthouse

Nuestra auditoría de Lighthouse mencionó algunas otras cosas que son bastante fáciles de arreglar, así que cuidémoslas mientras que estamos aquí.

4.3.1) Establecer la descripción meta

Bajo la auditoría de posicionamiento web en buscadores, Lighthouse anotó que nuestro "". Las descripciones se pueden mostrar en los resultados de búsqueda de Google. Las descripciones únicas y de alta calidad pueden hacer que tus resultados de búsqueda sean más relevantes para los usuarios y pueden acrecentar tu tráfico de búsqueda.

Para agregar una descripción, añade la próxima etiqueta meta al <head> de tu documento:

4.3.2) Establecer el color del tema de la barra de direcciones

En la auditoría de PWA, Lighthouse observó que nuestra aplicación "". El hecho de que la barra de direcciones del navegador coincida con los tonos de su marca proporciona una experiencia de usuario más envolvente.

Para establecer el color del tema en el móvil, añade la próxima etiqueta meta al <head> de tu documento:

4.4) Verificar cambios con Lighthouse

Ejecuta Lighthouse nuevamente (haciendo clic en el signo + en la esquina superior izquierda del panel Audits) y verifica tus cambios.

Auditoría SEO

• ✅ PASADO: El documento tiene una meta descripción.

Auditoría de Progressive Web App

• ❗FALLADO: La página actual no responde con un 200 cuando está desconectado.
• ❗FALLADO: start_url no responde con un doscientos cuando está desconectado.
• ❗FALLADO: No registra un service worker que controla la página y start_url.
• ✅ PASADO: El manifiesto de la aplicación web cumple con los requisitos de instalación.
• ✅ PASADO: Configurado para una pantalla de comienzo adaptada.
• ✅ PASADO: Establece un color de tema de la barra de direcciones.

5) Proporciona una experiencia offline básica

Los usuarios aguardan que las aplicaciones instaladas siempre tengan una experiencia de referencia si están sin conexión. Por eso es fundamental que las aplicaciones web instalables jamás muestren el dinosaurio sin conexión de Google Chrome. La experiencia sin conexión puede abarcar desde una página sin conexión simple hasta una experiencia de solo lectura con datos guardados previamente en caché, hasta una experiencia sin conexión totalmente funcional que se sincroniza automáticamente cuando se restaura la conexión de red.

En esta sección, agregaremos una página sin conexión simple a nuestra aplicación meteorológica. Si el usuario procura cargar la aplicación mientras que está sin conexión, mostrará nuestra página personalizada, en vez de la página sin conexión típica que muestra el navegador. Al final de esta sección, nuestra aplicación meteorológica pasará las próximas auditorías:

• La página actual no responde con un 200 cuando está desconectado.
• start_url no responde con un 200 cuando está desconectado.
• No registra un service worker que controla la página y start_url.

En la próxima sección, reemplazaremos nuestra página sin conexión adaptada con una experiencia sin conexión completa. Esto mejorará la experiencia sin conexión, mas lo que es más esencial, mejorará significativamente nuestro desempeño, puesto que la mayoría de nuestros activos (HTML, CSS y JavaScript) se almacenarán y servirán localmente, eliminando la red como un posible cuello de botella.

Si no estás familiarizado con los service workers, leyendo puedes hacerte una idea básica sobre lo que pueden hacer, cómo marcha su ciclo de vida y más. Cuando hayas completado este laboratorio de código, asegúrate de repasar el para tener una visión más detallada de cómo trabajar con los service workers.

Las funciones proporcionadas a través de los service workers se deben considerar una mejora progresiva y se deben añadir solo si el navegador las admite. Por ejemplo, con los service workers puedes guardar en caché la y los datos de tu aplicación, de tal modo que esté libre incluso cuando la red no lo esté. Cuando los service workers no son compatibles, no tiene por nombre al código sin conexión y el usuario obtiene una experiencia básica. El uso de la detección de características para otorgar mejoras progresivas tiene poca sobrecarga y no se interrumpirá en los navegadores viejos que no son compatibles con esa característica.

5.1) Registrar el service worker

El primer paso es registrar al service worker. Añade el siguiente código a tu fichero index.html :

Este código comprueba si la API de service workers está libre y, si lo está, el service worker en /service-worker.js se registra una vez que la página es .

Ten en cuenta que el service worker se sirve desde el directorio raíz, no desde un directorio /scripts/. Esta es la forma más fácil de configurar el scope de tu service worker. El scope del service worker determina qué ficheros controla el service worker, esto es, desde qué ruta el service worker interceptará las solicitudes. El valor predeterminado de scope es la ubicación del archivo de service worker y se extiende a todos y cada uno de los directorios a continuación. Entonces, si service-worker.js se halla en el directorio raíz, el service worker controlará las solicitudes de todas las páginas web en este dominio.

5.2) Precache página sin conexión

Primero, debemos decirle al service worker qué almacenar en caché. Ya hemos creado una simple (public/offline.html) que se mostrará toda vez que no haya conexión de red.

En tu service-worker.js, agrega '/offline.html', al array de FILES_TO_CACHE, el resultado final debería verse así:

A continuación, debemos actualizar el evento install para señalar al service worker que precachee la página sin conexión:

Nuestro evento install ahora abre la caché con caches.open() y da un nombre de caché. Proporcionar un nombre de caché nos permite versionar ficheros, o bien datos separados de los recursos guardados en caché para que podamos actualizar fácilmente uno pero no afecte al otro.

Una vez que la caché esté abierta, podemos llamar a cache.addAll(), que consigue una lista de URLs, las obtiene del servidor y añade la contestación a la caché. Ten en cuenta que cache.addAll() se rechazará si falla alguna de las peticiones individuales. Eso significa que tienes la garantía de que, si el paso de instalación se efectúa correctamente, tu caché estará en un estado consistente. Mas, si falla por alguna razón, lo intentará nuevamente automáticamente la próxima vez que se empiece el service worker.

5.2.1) DevTools, un pequeño desvío

Veamos cómo puedes usar DevTools para entender y depurar los service workers. Antes de regresar a cargar tu página, abre DevTools, ve al panel Service Workers en el panel Aplication. Debe tener un aspecto como este:

Cuando ves una página en blanco como esta, significa que la página actualmente abierta no tiene ningún service worker registrado.

Ahora, recarga tu página. El panel service workers ahora debería tener este aspecto:

Cuando veas información como esta, significa que la página tiene un service worker en ejecución.

Junto a la etiqueta de estado, hay un número (34251 en este caso), observa ese número mientras trabaja con los service workers. Es una forma fácil de saber si tu service worker ha sido actualizado.

5.3) Limpieza de páginas sin conexión antiguas

Usaremos el evento activate para adecentar los datos antiguos en nuestro caché. Este código garantiza que tu service worker actualiza nuestra caché cada vez que cambie alguno de los ficheros de la shell de la aplicación. Para que esto funcione, necesitarías acrecentar la variable CACHE_NAME en la parte superior de tu archivo de service worker.

Agrega el próximo código a tu acontecimiento activate :

5.3.1) DevTools, un pequeño desvío

Con el panel service workers abierto, actualiza la página, verá el nuevo service worker instalado y el aumento del número de estado.

El service worker actualizado toma el control de manera inmediata porque nuestro acontecimiento install concluye con self.skipWaiting() y el evento activate finaliza con self.clients.claim(). Sin esos, el service worker anterior continuaría controlando la página siempre que haya una pestaña abierta en la página.

5.4) Solicitudes de red fallidas

Y finalmente, precisamos manejar los eventos de fetch. Vamos a usar una . El service worker primero intentará recobrar el recurso de la red, si eso falla, devolverá la página sin conexión de la caché.

El supervisor fetch solo precisa manejar las navegaciones de la página, por lo que otras solicitudes pueden ser eliminadas del controlador y serán tratadas en general por el navegador. Mas, si la petición .mode es navigate, emplea fetch para intentar conseguir el factor de la red. Si falla, el manejador de catch abre la caché con caches.open(CACHE_NAME) y emplea cache.match('offline.html') para obtener la página sin conexión predefinida. El resultado se devuelve al navegador a través de evt.respondWith().

5.4.1) DevTools, un pequeño desvío

Revisemos para asegurarnos de que todo marcha como lo esperamos. Con el panel service workers abierto, actualiza la página, verás el nuevo service worker instalado y el aumento del número de estado.

También podemos verificar qué ha sido guardado en caché. Ve al panel Cache Storage en el panel Application de DevTools. Haz click con el botón derecho en Cache Storage, selecciona Refresh Caches, expande la sección y deberías ver el nombre de su caché estática en el lado izquierdo. Al hacer clic en el nombre de la memoria caché se muestran todos los archivos que están en caché.

Ahora, vamos a probar el modo perfecto sin conexión. Vuelve al panel Service Workers de DevTools y marca la casilla Offline. Después de cambiarlo, deberías ver un pequeño icono de advertencia amarillo al lado de la pestaña del panel Network. Esto señala que estás desconectado.

Recarga tu página y... ¡funciona! ¡Obtenemos nuestro panda desconectado, en vez del dino desconectado de Google Chrome!

5.5) Consejos para probar los service workers

Depurar a los service workers puede ser un desafío, y cuando se trata de almacenaje en caché, las cosas pueden convertirse en una pesadilla aún más si la caché no se actualiza cuando se espera. Entre el ciclo vital típico de un service worker y un error en su código, puedes frustrarte rápidamente. Pero no .

5.5.1) Usar DevTools

En el panel service workers del panel Application, existen algunas casillas de verificación que harán tu vida mucho más fácil.

• Offline - Cuando se marca, simula una experiencia sin conexión y evita que cualquier solicitud vaya a la red.
• Actualización en la recarga - Cuando se marca, se obtendrá el service worker más reciente, se instalará y se activará de inmediato.
• Bypass para red - Cuando se marca, las solicitudes pasan por alto al service worker y se envían directamente a la red.

5.5.2) Borrón y cuenta nueva

En algunos casos, es posible que esté cargando datos en caché o bien que las cosas no se actualizan como esperas. Para borrar todos los datos guardados (localStorage, indexedDB data, cached archivos) y suprimir cualquier service worker, utiliza el panel Clear storage en la pestaña Application. Alternativamente, también puedes trabajar en una ventana de incógnito.

Consejos adicionales:

• Una vez que un service worker no ha sido registrado, puede permanecer en la lista hasta el momento en que se cierre la ventana que contiene el navegador.
• Si hay múltiples ventanas abiertas de tu aplicación, un nuevo service worker no entrará en vigencia hasta el momento en que todas las ventanas hayan sido recargadas y actualizadas al último service worker.
• ¡Desregistrar un service worker no borra la caché!
• Si existe un service worker y un nuevo service worker está registrado, el nuevo service worker no tomará el control hasta que la página es recargada, salvo que .

5.6) Verificar cambios con Lighthouse

Ejecuta Lighthouse de nuevo y contrasta tus cambios. ¡No olvides desactivar la opción Offline ya antes de verificar tus cambios!

Auditoría SEO

• ✅ PASADO: El documento tiene una meta descripción.

Auditoría de Progressive Web App

• ✅ PASADO: La página actual responde con un doscientos cuando está sin conexión.
• ✅ PASADO: start_url responde con un doscientos cuando está desconectado.
• ✅ PASADO: Registra un service worker que controla la página y start_url.
• ✅ PASADO: El manifiesto de la aplicación web cumple con los requisitos de instalación.
• ✅ PASADO: Configurado para una pantalla de inicio personalizada.
• ✅ PASADO: Establece un color de tema de la barra de direcciones.

6) Brindar una experiencia sin conexión completa

Tómate un momento, pon tu teléfono en modo avión e intenta ejecutar algunas de sus aplicaciones favoritas. En casi todos los casos, proporcionan una experiencia sin conexión bastante robusta. Los usuarios esperan un experiencia robusta de sus aplicaciones. Y la web no debería ser diferente. Las Progressive Web Apps deben diseñarse para unas condiciones sin conexión como escenario principal.

6.1) Ciclo de vida del service worker

El ciclo vital del service worker es la parte más difícil. Si no sabes qué es lo que está tratando de hacer y cuáles son los beneficios, puedes sentir que está combatiendo contra ti. Pero en el momento en que sepas cómo marcha, puedes ofrecer actualizaciones integrales y reservadas a los usuarios, mezclando lo mejor de la web y los patrones nativos.

6.1.1) install

El primer acontecimiento que recibe un service worker es install. Se activa tan pronto como el worker se ejecuta, y solo se llama una vez por service worker. Si modificas la secuencia de comandos de tu service worker, el navegador lo considerará un service worker diferente, y obtendrá su propio acontecimiento install.

Normalmente, el acontecimiento install se emplea para guardar en caché todo lo que necesita para que tu aplicación se ejecute.

6.1.2) activate

El service worker recibirá un acontecimiento activate cada vez que se comience. El objetivo principal del evento activate es configurar el comportamiento del service worker, adecentar los recursos que quedan de las ejecuciones precedentes (por servirnos de un ejemplo, cachés antiguas) y preparar al service worker para manejar las solicitudes de red (por poner un ejemplo, el acontecimiento fetch que se describe a continuación).

6.1.3) fetch

El acontecimiento fetch deja que el service worker intercepte cualquier petición de red y maneje las solicitudes. Puede ir a la red para conseguir el recurso, puede extraerlo de su propia caché, producir una respuesta adaptada o bien cualquiera de las múltiples opciones. Echa un vistazo a para ver las diferentes estrategias que puedes usar.

6.1.4) Actualizando un service worker

El navegador verifica si hay una nueva versión de tu service worker en todos y cada carga de página. Si halla una nueva versión, la nueva versión se descarga y también instala en segundo plano, pero no está activada. Se encuentra en estado de espera, hasta que ya no queda ninguna página abierta que utilice el antiguo service worker. En el momento en que se cierran todas y cada una de las ventanas que utilizan el viejo service worker, el nuevo service worker se activa y puede tomar el control. Consulte la sección del documento del ciclo vital del service worker para conseguir más detalles.

6.2) Elegir la estrategia de almacenaje en caché correcta

Elegir la adecuada depende del género de recurso que procures guardar en caché y de cómo podría precisarlo más adelante. Para nuestra aplicación meteorológica, vamos a dividir los recursos que necesitamos para almacenar en caché en dos categorías: los recursos que queremos incluir en caché y los datos que almacenaremos en caché en tiempo de ejecución.

6.2.1) Almacenamiento en caché de recursos estáticos

Precachear tus recursos es un concepto similar a lo que sucede en el momento en que un usuario instala una aplicación de escritorio o móvil. Los recursos clave necesarios a fin de que la aplicación se ejecute se instalan o se guardan en la memoria caché del dispositivo a fin de que puedan cargarse más tarde, si hay conexión de red o bien no.

Para nuestra aplicación, almacenaremos anteriormente todos nuestros recursos estáticos cuando nuestro service worker esté instalado, de tal modo que todo cuanto necesitamos para ejecutar nuestra aplicación se almacene en el dispositivo del usuario. Para garantizar que nuestra aplicación se cargue a la velocidad de la luz, usaremos la estrategia ; en lugar de ir a la red para obtener los recursos, se extraen de la caché local; Sólo si no está disponible, intentaremos conseguirlo de la red.

Extraer de la memoria caché local elimina cualquier variabilidad de la red. No importa en qué tipo de red esté el usuario (WiFi, 5G, 3G o bien aun 2G), los recursos clave que precisamos para ejecutar están disponibles casi de inmediato.

6.2.2) Los datos de la aplicación

La es ideal para ciertos tipos de datos y funciona bien para nuestra aplicación. Consigue los datos en la pantalla lo más rápido posible, después los actualiza una vez que la red ha devuelto los datos más recientes. Stale-while-revalidate quiere decir que debemos iniciar dos solicitudes asíncronas, una para la memoria caché y otra para la red.

En circunstancias normales, los datos almacenados en la memoria caché se devolverán prácticamente de manera inmediata dando la aplicación con datos recientes que puede usar. Entonces, cuando vuelva la petición de red, la aplicación se actualizará utilizando los datos más recientes de la red.

Para nuestra aplicación, esto proporciona una mejor experiencia que la red, recurriendo a la estrategia de caché pues el usuario no tiene que aguardar hasta el momento en que la solicitud de la red caduque para ver algo en la pantalla. Posiblemente inicialmente vean datos más viejos, mas cuando se devuelva la solicitud de red, la aplicación se actualizará con los datos más recientes.

6.3) Actualizar la lógica de la aplicación

Como se mencionó previamente, la aplicación debe empezar 2 peticiones asíncronas, una para la caché y otra para la red. La aplicación usa el objeto caches libre en window para acceder a la memoria caché y recobrar los últimos datos. Este es un excelente ejemplo de mejora progresiva ya que el objeto caches puede no estar disponible en todos y cada uno de los navegadores, y si no es así, la petición de red debería funcionar.

Actualiza la función getForecastFromCache() para contrastar si el objeto caches está disponible en el objeto global window y, si lo está, solicita los datos de la memoria caché.

Después, debemos alterar a fin de que haga 2 llamadas, una a getForecastFromNetwork() para obtener el pronóstico de la red y otra a getForecastFromCache() para conseguir el último pronóstico almacenado en caché:

Nuestra aplicación meteorológica ahora efectúa 2 peticiones asíncronas de datos, una desde la caché y otra a través de un fetch. Si hay datos en la caché, serán devueltos y procesados extremadamente rápido (decenas de milisegundos). Entonces, cuando responda fetch, la tarjeta se actualizará con los datos más recientes de manera directa de la API meteorológica.

Observe cómo la solicitud de caché y la solicitud fetch terminan con una llamada para actualizar la tarjeta de pronóstico. ¿Cómo sabe la aplicación si muestra los últimos datos? Esto se maneja en el próximo código de renderForecast() :

Cada vez que se actualiza una tarjeta, la aplicación almacena la marca de tiempo de los datos en un atributo oculto en la tarjeta. La aplicación simplemente comprueba si la marca de tiempo que existe en la tarjeta es más reciente que los datos que se pasaron a la función.

6.4) Pre-cachear nuestros recursos de la aplicación

En el service worker, añadimos un DATA_CACHE_NAME para poder separar los datos de nuestras aplicaciones del shell de la aplicación. Cuando se actualiza el shell de la aplicación y se eliminan los cachés más viejas, nuestros datos permanecerán intactos, listos para una carga súper rápida. Ten en cuenta que si su formato de datos cambia en el futuro, necesitará una forma de manejar eso y asegurar que el shell y el contenido de la aplicación estén acompasados.

No olvides actualizar también CACHE_NAME; Estaremos mudando todos nuestros recursos estáticos también.

Para que nuestra aplicación funcione sin conexión, debemos almacenar previamente todos y cada uno de los recursos que precisa. Esto también ayudará a nuestro rendimiento. En lugar de tener que obtener todos los recursos de la red, la aplicación podrá cargarlos todos desde la caché local, eliminando la inestabilidad de la red.

Actualiza el array FILES_TO_CACHE con la lista de archivos:

Ya que estamos produciendo manualmente la lista de archivos a cachear, toda vez que actualizamos un archivo, debemos actualizar CACHE_NAME. Pudimos suprimir offline.html de nuestra lista de archivos en caché pues nuestra aplicación ahora cuenta con todos los recursos precisos para trabajar sin conexión y nunca volverá a enseñar la página sin conexión.

6.4.1) Actualizar el controlador de acontecimientos activate

Para asegurar que nuestro evento activate no suprime accidentariamente nuestros datos, en el evento activate de service-worker.js, sustituye if (key !== CACHE_NAME) con:

6.4.2) public / service-worker.js

6.4.3) Actualizar el controlador de acontecimientos fetch

Necesitamos modificar el service worker para detener las solicitudes a la API metereológica y almacenar sus respuestas en la caché, para que podamos acceder a ellas fácilmente más adelante. En la estrategia stale-while-revalidate, aguardamos que la respuesta de la red sea la "fuente de la verdad", siempre y en todo momento nos proporciona la información más reciente. Si no puede, está bien fallar por el hecho de que ya hemos recuperado los últimos datos guardados en caché en nuestra aplicación.

Actualiza el manejador de acontecimiento fetch para manejar las peticiones a la API de datos por separado de otras peticiones.

El código intercepta la petición y comprueba si es para un pronóstico del tiempo. Si es así, utiliza fetch para efectuar la solicitud. Una vez que se devuelve la respuesta, abre la memoria caché, clona la contestación, la almacena en la memoria caché y devuelve la respuesta al solicitante original.

Necesitamos suprimir la comprobación evt.request.mode !== 'navigate' por el hecho de que deseamos que nuestro service worker maneje todas y cada una de las peticiones (incluidas imágenes, scripts, ficheros CSS, etc.), no solamente las navegaciones. Si dejamos ese registro, solo se entregará el HTML desde la memoria caché del service worker, todo lo demás se solicitará desde la red.

6.5) Pruébalo

La aplicación, sin conexión, ha de estar absolutamente funcional ahora. Actualiza la página para asegurarte de que tienes instalado el service worker más reciente, luego guarda un par de ciudades y presiona el botón de actualización en la aplicación para obtener información actualizada sobre el clima.

Luego ve al panel Cache Storage en el panel Application de DevTools. Expande la sección y verás el nombre de su caché estático y la caché de datos en el lado izquierdo. Al abrir la caché de datos se deben mostrar los datos almacenados para cada ciudad.

Luego, abre DevTools y cambia al panel service workers, y marca la casilla de verificación Offline, entonces procura regresar a cargar la página, después desconecta y vuelve a cargar la página.

Si estás en una red rápida y quiere ver cómo se actualiza datos de previsión del tiempo en una conexión lenta, ajusta el FORECAST_DELAY propiedad en server.js a 5000. Todas y cada una de las solicitudes a la API de pronóstico se retrasarán 5000ms.

6.6) Verificar cambios con Lighthouse

También es una buena idea volver a ejecutar Lighthouse.

Auditoría SEO

• ✅ PASADO: El documento tiene una meta descripción.

Auditoría de Progressive Web App

• ✅ PASADO: La página actual responde con un 200 cuando está sin conexión.
• ✅ PASADO: start_url responde con un doscientos cuando está desconectado.
• ✅ PASADO: Registra un service worker que controla la página y start_url.
• ✅ PASADO: El manifiesto de la aplicación web cumple con los requisitos de instalación.
• ✅ PASADO: Configurado para una pantalla de comienzo personalizada.
• ✅ PASADO: Establece un color de tema de la barra de direcciones.

7) Añadir experiencia de instalación

Cuando se instala una Progressive Web App, se ve y se comporta como todas y cada una de las demás aplicaciones instaladas. Se inicia desde exactamente el mismo sitio que se lanzan otras aplicaciones. Se ejecuta en una aplicación sin una barra de direcciones o bien otra interfaz de usuario del navegador. Y como todas las demás aplicaciones instaladas, es una aplicación de nivel superior en el conmutador de labores.

En Chrome, una Progressive Web App puede instalarse a través del menú contextual de 3 puntos, o puede administrar un botón o bien otro componente de UI al usuario que le pedirá que instale tu aplicación.

7.1) Auditoría con Lighthouse

Para que un usuario pueda instalar tu Progressive Web App, debe cumplir con . La forma más fácil de contrastar es usar Lighthouse y asegurarse de que cumpla con los criterios instalables.

Si has trabajado con este código, tu PWA ya debería cumplir con estos criterios.

7.2) Agrega install.js a index.html

Primero, agregamos el install.js a nuestro archivo index.html.

7.3) Escucha el acontecimiento beforeinstallprompt

Si se cumple la función de agregar a la pantalla de inicio , Google Chrome activará un evento de beforeinstallprompt, que puede utilizar para señalar que tu aplicación se puede "instalar" y luego solicitar al usuario que la instale. Añade el siguiente código para escuchar el acontecimiento beforeinstallprompt :

7.4) Evento guardar y mostrar el botón de instalación

En nuestra función saveBeforeInstallPromptEvent, saveBeforeInstallPromptEvent una referencia al acontecimiento beforeinstallprompt para poder llamar a prompt() más adelante y actualizar nuestra interfaz de usuario para mostrar el botón de instalación.

7.5) Mostrar el prompt / ocultar el botón

Cuando el usuario hace click en el botón de instalación, debemos llamar a .prompt() en el acontecimiento beforeinstallprompt guardado. También necesitamos ocultar el botón de instalación, pues solo se puede llamar a .prompt() una vez en todos y cada evento guardado.

Al llamar a .prompt() se mostrará un diálogo modal al usuario y se te pedirá que agregues tu aplicación a la pantalla de inicio.

7.6) Registrar los resultados

Puedes verificar qué respondió el usuario al cuadro de diálogo de instalación escuchando la promesa que devuelve la propiedad userChoice del acontecimiento beforeinstallprompt salvado. La promesa devuelve un objeto con una propiedad outcome después de que se haya mostrado la solicitud y el usuario haya contestado a ella.

Un comentario sobre userChoice, , no es una función como podría aguardarse.

7.6.1) Registrar todos y cada uno de los acontecimientos de instalación

Adicionalmente a cualquier UI que añadadas para instalar tu aplicación, los usuarios también pueden instalar tu PWA a través de otros métodos, por servirnos de un ejemplo, el menú de 3 puntos de Google Chrome. Para rastrear estos eventos, escuche el evento instalado.

Después, necesitaremos actualizar la función logAppInstalled, para este laboratorio de código, solo usaremos console.log, pero en una aplicación de producción, seguramente desearás registrar esto como un acontecimiento en tu software de analíticas.

7.7) Actualizar el service worker

No olvides actualizar CACHE_NAME en tu fichero service-worker.js, en tanto que has realizado cambios en los ficheros que ya están en caché. Habilitar la casilla de verificación Bypass for network en el panel service workers del panel de aplicaciones en DevTools funcionará en el desarrollo, mas no ayudará en el planeta real.

7.8) Pruébalo

Vamos a ver cómo fue nuestro paso de instalación. Para estar seguro, usa el botón Clear site data en el panel de aplicaciones de DevTools para suprimir todo y cerciorarte de que estamos comenzando nuevamente. Si ya instalaste la aplicación, asegúrate de desinstalarla, en caso contrario, el icono de instalación no volverá a aparecer.

7.8.1) Verifica que el botón de instalación esté visible

Primero, verificamos que nuestro ícono de instalación se muestre apropiadamente, asegúrate de probar esto tanto en el escritorio como en el móvil.

1. Abre la URL en una nueva pestaña de Chrome.
2. Abre el menú de tres puntos de Google Chrome (junto a la barra de direcciones). ▢ Comprueba que vea "Instalar Clima..." en el menú.
3. Actualiza los datos metereológicos con el botón de actualización en la esquina superior derecha para asegurarnos de que cumplimos con las . ▢ Comprueba que el icono de instalación esté visible en el encabezado de la aplicación.

7.8.2) Verifica que el botón de instalación funcione

A continuación, nos aseguramos de que todo se instala correctamente y de que nuestros acontecimientos se activan apropiadamente. Puedes hacerlo tanto en tu escritorio como en tu móvil. Si quieres probar esto en el móvil, asegúrate de que estás empleando la depuración recóndita para ver lo que se está registrado en la consola.

1. Abre Google Chrome y, en una nueva pestaña del navegador, navega a tu PWA Tiempo.
2. Abre DevTools y cambia al panel de la consola.
3. Haz click en el botón de instalación en la esquina superior derecha. ▢ Comprueba que el botón de instalación desaparezca ▢ Verifica que se muestra el cuadro de diálogo modal de instalación.
4. Haz click en Cancelar. ▢ Verifica que "El usuario rechazó la solicitud A2HS" se muestra en la salida de la consola. ▢ Verifica que el botón de instalación vuelva a aparecer.
5. Haz clic en el botón Instalar nuevamente, entonces haz click en el botón Instalar en el diálogo modal. ▢ Verifica que "El usuario aceptó la petición A2HS" se muestra en la salida de la consola. ▢ Comprueba que "aplicación meteorológica se haya instalado" se muestre en la salida de la consola. ▢ Verifica que la aplicación meteorológica se añade al lugar donde normalmente encontrará las aplicaciones.
6. Inicia la PWA Tiempo. ▢ Verifica que la aplicación se abre como una aplicación independiente, así sea en una ventana de la aplicación en el escritorio o bien en pantalla completa en el móvil.

Ten en cuenta que si está ejecutando en el escritorio desde localhost, tu PWA instalada puede mostrar una pancarta de dirección pues localhost no se considera un host seguro.

7.8.3) Verifica que la instalación de iOS funcione correctamente

Veamos también el comportamiento en iOS. Si tienes un dispositivo iOS, puedes usarlo, o si estás usando un Mac, prueba el simulador de iOS libre con Xcode.

1. Abre Safari y en una nueva pestaña del navegador, navega a tu PWA Tiempo.
2. Haz click en el botón Compartir! .
3. Desplázate hacia la derecha y Haz click en el botón Agregar a la pantalla de inicio. ▢ Verifica que el título, la URL y el icono sean adecuados.
4. Haz click en Agregar. ▢ Comprueba que el icono de la aplicación se añade a la pantalla de inicio.
5. Inicia la PWA Tiempo desde la pantalla de comienzo. ▢ Verifica que la aplicación se inicia en pantalla completa.

7.9) Bonus: ### si tu aplicación se inicia desde la pantalla de inicio

La media query display-mode permite aplicar estilos dependiendo de cómo se lanzó la aplicación, o determinar cómo se lanzó con JavaScript.

También puedes comprobar la media query display-mode con .

7.10) Bonus: Desinstalando tu PWA

Recuerda, beforeinstallevent no se dispara si la aplicación ya está instalada, por lo que durante el desarrollo seguramente querrás instalarla y desinstalarla múltiples veces para cerciorarte de que todo marcha como se aguardaba.

7.10.1) Android

En Android se desinstalan de igual modo que otras aplicaciones instaladas.

• Abre el cajón de aplicaciones.
• Desplázate hacia abajo para hallar el icono del tiempo.
• Arrastra el ícono de la aplicación a la parte superior de la pantalla.
• Elige Desinstalar.

7.10.2) ChromeOS

En ChromeOS, las PWA se desinstalan fácilmente desde el cuadro de búsqueda del iniciador.

• Abre el lanzador.
• Escribe "Clima" en el cuadro de búsqueda, tu PWA Tiempo debería aparecer en los resultados.
• Haz clic derecho (alt-click) en la PWA Clima.
• Haz click en Eliminar de Chrome...

7.10.3) macOS y Windows

En Mac y Windows se deben desinstalar a través de Google Chrome.

• En una nueva pestaña del navegador, abre chrome://apps.
• Haz click derecho (alt-click) en la PWA Clima.
• Haz click en Eliminar de Chrome...

8) Felicitaciones

¡Enhorabuena, has construido con éxito tu primera Progressive Web Aplicación!

Agregaste un manifiesto de aplicación web para dejar que se instalase, y añadiste un service worker para asegurar que tu PWA sea siempre rápida y confiable. Has aprendido cómo usar DevTools para auditar una aplicación y cómo esto puede prosperar la experiencia de usuario.

Ahora conoce los pasos clave precisos para convertir cualquier aplicación web en una Progressive Web Aplicación.

8.1) Lectura adicional

8.2) referencia

9) Encontró un inconveniente o bien tiene comentarios?

Ayúdanos a prosperar nuestros laboratorios de códigos mandando una hoy. ¡Y gracias!