shortsheaven0

Introducción

¿Qué hace de una aplicación web, una Progressive Web App?

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 confiables. Y lo más importante, son aplicaciones web que marchan 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 Aplicación.

Rápida y Confiable

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

Y, debe ser confiablemente rápido. Es difícil enfatizar lo suficiente lo bueno que es el rendimiento fiable. diseño web Granada é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, mas en el momento en que llegas al punto de instalar la aplicación, ese coste inicial se amortiza en todos los principios de la aplicación, y ninguno de esos principios tiene un retraso variable. Cada inicio de aplicación es tan rápido como el último, sin variación. Una Progressive Web Aplicación debe ofrecer este rendimiento fiable que los usuarios esperan de cualquier experiencia instalada.

Instalable

Las Progressive Web Apps pueden ejecutarse en una pestaña del navegador, mas también son instalables. Añadir a marcadores un lugar simplemente agrega un acceso directo, mas una Progressive Web Aplicación instalada se ve y se comporta como todas las demás aplicaciones instaladas. Se comienza desde el mismo sitio que se lanzan otras aplicaciones. Puedes controlar la experiencia de lanzamiento, incluyendo 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 labores.

Recuerda, es esencial que una PWA instalable sea rápida y confiable. Los usuarios que instalan una PWA aguardan que sus aplicaciones funcionen, sin importar un mínimo en qué tipo de conexión de red estén conectados. Es una expectativa de referencia que todas y cada una de las aplicaciones instaladas deben cumplir.

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 redactar una aplicación nativa, eche una ojeada a los beneficios que ofrece una PWA.

Qué construirás

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

• Usará diseño amoldable, por lo que marcha en escritorio o móvil.
• Será rápido, utiliza un service worker para guardar en precache los recursos de la aplicación (HTML, CSS, JavaScript, imágenes) precisos para ejecutar y almacenar en caché los datos meteorológicos en tiempo de ejecución para progresar el rendimiento.
• Será instalable, usando un manifiesto de aplicación web y el evento beforeinstallprompt para notificar al usuario que es instalable.

Lo que aprenderás

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

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

Lo que necesitarás

• Una versión reciente de Chrome (setenta y cuatro o bien siguiente) las PWAs son solo aplicaciones web y funcionan en todos los navegadores, pero usaremos algunas funciones de Google Chrome DevTools para comprender 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 .

Preparación

Consigue una clave para la API de Dark Sky

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

Verifica que tu API key funciona correctamente

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

/forecast/DARKSKY_API_KEY/40. ,-setenta y tres.

Obtén el código

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

Muy recomendable: utiliza 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 click en New Project, luego Clone from Git Repo.
4. Clone /googlecodelabs/your-first-pwapp.git y Haz clic 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 click en el botón Mostrar Live para ver la PWA en acción.

Alternativa: Descargar código y trabajar localmente

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

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 iniciar el servidor en el puerto ocho mil.
5. Abre una pestaña del navegador en

Establecer una línea de base

¿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 mostrar los conceptos en este laboratorio de código y tiene poco manejo de errores. Si escoges 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 urbe 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 usando 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 sucede en el momento en que te desconectas.
6. Usando el panel de la Red de Google Chrome, mira qué sucede cuando la red se restringe a Slow 3G.
7. Agrega un retraso al servidor de pronóstico cambiando FORECAST_DELAY en server.js

Auditoría con Lighthose

es una herramienta fácil de emplear para ayudar a progresar 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 importante, así como la forma de solucionarla.

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

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.

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 rojo 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 comienzo adaptada.
• ❗FALLADO: No establece un color de tema de la barra de direcciones.

¡Saltemos y empecemos a solucionar algunos de estos problemas!

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 personalizada.
• No establece un color de tema de la barra de direcciones.

Crear el manifiesto de la aplicación web.

es un fichero JSON simple que deja que tú, el desarrollador, puedas supervisar 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 deseas 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 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 archivo 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 ya que los necesitábamos para nuestra integración con iOS.

Añadir un enlace 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 fichero index.html.

DevTools, un pequeño desvío

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

Safari en iOS no acepta el manifiesto de aplicación web (), por lo que deberás añadir al <head> de tu archivo index.html :

Bonus: arreglos fáciles de Lighthouse

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

Establecer la descripción meta

Bajo la auditoría de posicionamiento 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 añadir una descripción, agrega la próxima etiqueta meta al <head> de tu documento:

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 colores de su marca proporciona una experiencia de usuario más envolvente.

Para establecer el tono del tema en el móvil, agrega la siguiente etiqueta meta al <head> de tu documento:

Verificar cambios con Lighthouse

Ejecuta Lighthouse nuevamente (haciendo click en el signo + en el rincón 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 200 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 inicio adaptada.
• ✅ PASADO: Establece un color de tema de la barra de direcciones.

Proporciona una experiencia offline básica

Los usuarios esperan que las aplicaciones instaladas siempre y en toda circunstancia tengan una experiencia de referencia si están sin conexión. De ahí que es fundamental que las aplicaciones web instalables nunca muestren el dinosaurio sin conexión de Google Chrome. La experiencia sin conexión puede englobar desde una página sin conexión simple hasta una experiencia de solo lectura con datos almacenados previamente en caché, hasta una experiencia sin conexión plenamente funcional que se sincroniza automáticamente cuando se restaura la conexión de red.

En esta sección, añadiremos una página sin conexión simple a nuestra aplicación meteorológica. Si el usuario intenta cargar la aplicación mientras que está sin conexión, mostrará nuestra página adaptada, 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 doscientos 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 importante, 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 funciona su ciclo vital y más. Cuando hayas completado este laboratorio de código, asegúrate de revisar 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 acepta. Por ejemplo, con los service workers puedes guardar en caché la y los datos de tu aplicación, de tal modo que esté disponible aun cuando la red no lo esté. Cuando los service workers no son compatibles, no lleva por nombre al código sin conexión y el usuario obtiene una experiencia básica. El empleo 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.

Registrar el service worker

El primer paso es registrar al service worker. Añade el próximo 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 cuando 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é archivos controla el service worker, es decir, desde qué ruta el service worker interceptará las peticiones. El valor predeterminado de scope es la ubicación del archivo de service worker y se extiende a todos los directorios a continuación. Entonces, si service-worker.js se halla en el directorio raíz, el service worker controlará las peticiones de todas las páginas web en este dominio.

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á cada vez que no haya conexión de red.

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

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

Nuestro acontecimiento install ahora abre la caché con caches.open() y proporciona un nombre de caché. Suministrar un nombre de caché nos permite versionar archivos, o bien datos separados de los recursos guardados en caché a fin de que podamos actualizar fácilmente uno mas no afecte al otro.

Una vez que la caché esté abierta, podemos llamar a cache.addAll(), que obtiene una lista de URLs, las obtiene del servidor y añade la contestación a la caché. Ten presente que cache.addAll() se rechazará si falla ciertas solicitudes 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. Pero, si falla por alguna razón, lo intentará nuevamente automáticamente la próxima vez que se inicie el service worker.

DevTools, un pequeño desvío

Veamos cómo puedes usar DevTools para entender y depurar los service workers. Antes de volver 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, quiere decir que la página hoy día 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, quiere decir que la página tiene un service worker en ejecución.

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

Limpieza de páginas sin conexión antiguas

Usaremos el evento activate para limpiar los datos viejos en nuestro caché. Este código garantiza que tu service worker actualiza nuestra caché toda vez que cambie ciertos archivos de la shell de la aplicación. A fin de que esto funcione, necesitarías incrementar la variable CACHE_NAME en la parte superior de tu archivo de service worker.

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

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 forma inmediata porque nuestro acontecimiento install finaliza con self.skipWaiting() y el evento activate finaliza con self.clients.claim(). Sin esos, el service worker precedente continuaría controlando la página siempre y cuando haya una pestaña abierta en la página.

Solicitudes de red fallidas

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

El controlador fetch solo necesita manejar las navegaciones de la página, por lo que otras peticiones pueden ser eliminadas del controlador y serán tratadas en general por el navegador. Pero, si la petición .mode es navigate, utiliza fetch para procurar conseguir el elemento de la red. Si falla, el manejador de catch abre la caché con caches.open(CACHE_NAME) y usa 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().

DevTools, un pequeño desvío

Revisemos para asegurarnos de que todo marcha como lo aguardamos. Con el panel service workers abierto, actualiza la página, verás el nuevo service worker instalado y el incremento 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, escoge 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 ficheros 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 junto a la pestaña del panel Network. Esto señala que estás desconectado.

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

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 transformarse 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 .

Usar DevTools

En el panel service workers del panel Application, hay 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 peticiones pasan por alto al service worker y se envían directamente a la red.

Borrón y cuenta nueva

En algunos casos, es posible que esté cargando datos en caché o que las cosas no se actualizan como esperas. Para borrar todos y cada uno de los datos guardados (localStorage, indexedDB data, cached files) y eliminar cualquier service worker, usa el panel Clear storage en la pestaña Application. De forma alternativa, 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 y cada una de 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 el momento en que la página es recargada, a menos que .

Verificar cambios con Lighthouse

Ejecuta Lighthouse nuevamente 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 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.

Brindar una experiencia sin conexión completa

Tómate un instante, pon tu teléfono en modo avión e procura ejecutar algunas de sus aplicaciones favoritas. En casi todos los casos, dan 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 Aplicaciones deben diseñarse para unas condiciones sin conexión como escenario primordial.

Ciclo de vida del service worker

El ciclo vital del service worker es la parte más complicada. Si no sabes qué es lo que está tratando de hacer y cuáles son las ventajas, puedes sentir que está luchando contra ti. Pero una vez que sepas cómo marcha, puedes ofrecer actualizaciones integrales y prudentes a los usuarios, mezclando lo mejor de la página web y los patrones nativos.

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 evento install.

Normalmente, el evento install se emplea para almacenar en caché todo cuanto necesita a fin de que tu aplicación se ejecute.

activate

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

fetch

El evento fetch permite que el service worker intercepte cualquier petición de red y maneje las peticiones. Puede ir a la red para conseguir el recurso, puede extraerlo de su propia caché, generar una contestación adaptada o cualquiera de las múltiples opciones. Echa un vistazo a para ver las distintas estrategias que puedes usar.

Actualizando un service worker

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

Elegir la estrategia de almacenaje en caché correcta

Elegir la adecuada depende del tipo de recurso que intentes 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 2 categorías: los recursos que deseamos incluir en caché y los datos que almacenaremos en caché en tiempo de ejecución.

Almacenamiento en caché de recursos estáticos

Precachear tus recursos es un concepto afín a lo que ocurre cuando 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 bien se almacenan en la memoria caché del dispositivo a fin de que puedan cargarse más tarde, si hay conexión de red o 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 vez de ir a la red para conseguir los recursos, se extraen de la caché local; Sólo si no está libre, intentaremos conseguirlo de la red.

Extraer de la memoria caché local suprime cualquier variabilidad de la red. No importa en qué género de red esté el usuario (WiFi, 5G, 3G o incluso 2G), los recursos clave que necesitamos para ejecutar están disponibles casi inmediatamente.

Los datos de la aplicación

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

En circunstancias normales, los datos guardados en la memoria caché se devolverán casi de manera inmediata proporcionando la aplicación con datos recientes que puede utilizar. Luego, 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 esperar hasta el momento en que la solicitud de la red caduque para poder ver algo en la pantalla. Posiblemente inicialmente vean datos más antiguos, mas en el momento en que se devuelva la petición de red, la aplicación se actualizará con los datos más recientes.

Actualizar la lógica de la aplicación

Como se mencionó anteriormente, la aplicación debe iniciar 2 peticiones asíncronas, una para la caché y otra para la red. La aplicación emplea el objeto caches libre en window para acceder a la memoria caché y recuperar los últimos datos. Este es un genial 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 marchar.

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

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

Nuestra aplicación meteorológica ahora realiza 2 solicitudes 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 exageradamente rápido (decenas y decenas de milisegundos). Entonces, cuando responda fetch, la tarjeta se actualizará con los datos más recientes directamente de la API meteorológica.

Observe cómo la solicitud de caché y la petición fetch acaban 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 siguiente código de renderForecast() :

Cada vez que se actualiza una tarjeta, la aplicación guarda la marca de tiempo de los datos en un atributo escondo en la tarjeta. La aplicación sencillamente 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.

Pre-cachear nuestros recursos de la aplicación

En el service worker, agregamos 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 antiguas, 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 sincronizados.

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

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

Actualiza el array FILES_TO_CACHE con la lista de archivos:

Ya que estamos generando manualmente la lista de ficheros a cachear, toda vez que actualizamos un fichero, debemos actualizar CACHE_NAME. Pudimos eliminar offline.html de nuestra lista de ficheros en caché porque nuestra aplicación ahora cuenta con todos los recursos necesarios para trabajar sin conexión y nunca volverá a mostrar la página sin conexión.

Actualizar el supervisor de eventos activate

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

public / service-worker.js

Actualizar el controlador de acontecimientos fetch

Necesitamos modificar el service worker para interceptar 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 da la información más reciente. Si no puede, está bien fallar pues 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 solicitudes.

El código intercepta la petición y verifica si es para un pronóstico del tiempo. Si es así, emplea fetch para realizar la solicitud. En el momento en que se devuelve la respuesta, abre la memoria caché, clona la contestación, la almacena en la memoria caché y devuelve la contestación al demandante original.

Necesitamos quitar la comprobación evt.request.mode !== 'navigate' porque queremos que nuestro service worker maneje todas las solicitudes (incluidas imágenes, scripts, archivos CSS, etcétera), no solo 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.

Pruébalo

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

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 enseñar los datos almacenados para cada urbe.

Luego, abre DevTools y cambia al panel service workers, y marca la casilla de verificación Offline, entonces intenta 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 desea 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 las peticiones a la API de pronóstico se retrasarán 5000ms.

Verificar cambios con Lighthouse

También es una buena idea regresar 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 doscientos cuando está sin conexión.
• ✅ PASADO: start_url responde con un doscientos cuando está desconectado.
• ✅ PASADO:</ <a href="https://citiface.com/es/consultoria-web-0">cpc marketing 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.

Añadir experiencia de instalación

Cuando se instala una Progressive Web Aplicación, se ve y se comporta como todas y cada una de las demás aplicaciones instaladas. Se comienza desde el mismo lugar 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 y cada una de las demás aplicaciones instaladas, es una aplicación de nivel superior en el conmutador de labores.

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

Auditoría con Lighthouse

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

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

Agrega install.js a index.html

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

Escucha el acontecimiento beforeinstallprompt

Si se cumple la función de agregar a la pantalla de inicio , Chrome activará un acontecimiento de beforeinstallprompt, que puede emplear para apuntar que tu aplicación se puede "instalar" y después pedir al usuario que la instale. Añade el siguiente código para percibir el evento beforeinstallprompt :

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

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

Mostrar el prompt / esconder el botón

Cuando el usuario hace click en el botón de instalación, debemos llamar a .prompt() en el evento beforeinstallprompt guardado. También necesitamos ocultar el botón de instalación, por el hecho de que solo se puede llamar a .prompt() una vez en todos y cada acontecimiento 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.

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 esperarse.

Registrar todos y cada uno de los eventos 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 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.

Actualizar el service worker

No olvides actualizar CACHE_NAME en tu fichero service-worker.js, puesto que has efectuado cambios en los archivos 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, pero no ayudará en el mundo real.

Pruébalo

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

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

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

1. Abre la URL en una nueva pestaña de Google Chrome.
2. Abre el menú de tres puntos de Chrome (al lado de 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 el rincón superior derecha para asegurarnos de que cumplimos con las . ▢ Comprueba que el icono de instalación esté perceptible en el encabezado de la aplicación.

Verifica que el botón de instalación funcione

A continuación, nos cercioramos de que todo se instala apropiadamente y de que nuestros acontecimientos se activan correctamente. 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 utilizando la depuración remota 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 clic en el botón de instalación en el rincón superior derecha. ▢ Verifica que el botón de instalación desaparezca ▢ Comprueba que se muestra el cuadro de diálogo modal de instalación.
4. Haz clic en Anular. ▢ Verifica que "El usuario rechazó la petición A2HS" se muestra en la salida de la consola. ▢ Comprueba 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. ▢ Comprueba 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 en general 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 enseñar una pancarta de dirección porque localhost no se considera un host seguro.

Verifica que la instalación de iOS funcione correctamente

Veamos también el comportamiento en iOS. Si tienes un dispositivo iOS, puedes utilizarlo, o si estás utilizando 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 clic en el botón Compartir! .
3. Desplázate cara la derecha y Haz clic 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. ▢ Verifica que el icono de la aplicación se añade a la pantalla de comienzo.
5. Inicia la PWA Clima desde la pantalla de comienzo. ▢ Verifica que la aplicación se comienza en pantalla completa.

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

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

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

Bonus: Desinstalando tu PWA

Recuerda, beforeinstallevent no se dispara si la aplicación ya está instalada, con lo que a lo largo del desarrollo seguramente querrás instalarla y desinstalarla varias veces para cerciorarte de que todo marcha como se esperaba.

Android

En Android se desinstalan de igual forma 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.

ChromeOS

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

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

macOS y Windows

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

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

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 agregaste un service worker para garantizar que tu PWA sea siempre rápida y fiable. Has aprendido cómo utilizar DevTools para auditar una aplicación y cómo esto puede mejorar la experiencia de usuario.

Ahora conoce los pasos clave necesarios para transformar cualquier aplicación web en una Progressive Web App.

Lectura adicional

referencia

Encontró un inconveniente o tiene comentarios?

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