PWAs fuera de lo establecido

Introducción

Surgen muchas dudas siempre con las Progress Web Applications, en siglas PWAs, y a priori no parece que sirvan de mucho, conceptualmente es difícil de vender y también difícil de comprar si no lo explica alguien que de verdad sepa lo que es. Por internet hay infinidad de artículos relacionados, la mayoría hablando de lo mismo y sin embargo ninguno despeja la mayoría de las dudas.

En este artículo se van a tratar, en la medida de lo posible, aproximaciones distintas para dar un punto de vista diferente e intentar reducir la cantidad de cuestiones, tener más argumentos o convencer / asustar a los reticentes de implementar una PWA en su web. Lo mejor que se puede hacer es leer los artículos que proporciona Google para empezar a entender lo que es. Siempre estará de lo más actualizado, y al fin y al cabo, ellos son los promotores e impulsores de todo esto.

Este artículo no es para aprender, si no para extender las miras y ver un poco por fuera de lo establecido.

 

¿Qué es? ¿Para qué sirve? ¿Merece la pena el esfuerzo? ¿Lo puedo integrar en mi web? ¿Hace falta algo especial? ¿Cuánto tiempo hay que dedicarle?

 

Estas son algunas de las preguntas que pueden surgir, muchas de sus respuestas se pueden encontrar navegando, la mayoría indicando que las PWA son un gran invento y el futuro, todos los blogs hablando de sus bondades. A modo de introducción a las respuestas:

  • Para una web pequeña, con pocos recursos, solo sirve para decir que está ahí y a no ser que sea solo servir HTML plano, es un gran foco de errores y frustraciones para los usuarios. Se puede integrar en cualquier web con poco esfuerzo, poco tiempo y poco conocimiento, ¡ suena muy bien ! (algo que cuesta tan poco, no puede aportar mucho).
  • Para una gran web con recursos, hacer algo útil que marque la diferencia y de verdad se le saque valor, necesita mucho tiempo, esfuerzo y conocimientos específicos, entender bien la manera que tienen de renderizar los navegadores y los sistemas de cacheo del service worker, servidor, CDN, etc. Y a la pregunta de si merece la pena, la respuesta es: sí y sólo sí, hay un plan detrás, organización y claridad en la dirección que tomar. Como más adelante se indica, no es sencillo ver la rentabilidad a la inversión.

 

Qué ofrece un PWA aparte de lo básico

 

¿Y qué es lo básico? Decir que la tienes o poner el caché first y olvidar que existe. La verdad, esto es un error, y en la mayoría de los casos, mejor que no se hubiese hecho. ¿Y lo no básico? Se puede personalizar hasta donde dé la imaginación, aunque por dar algo más aterrizado en forma de ejemplos, es posible:

  • Fomentar visitas a algunas páginas precacheandolas.
  • Mejorar la performance de las páginas (mediante caché) que más interesen y no de todas, puesto que no todas se podrán cachear en el momento que la web tenga un amplio volumen de páginas.
  • Integrar con terceros para aumentar el control de notificaciones o analítica.
  • Integrar con un CMS para aumentar la personalización que puede dar el propietario de la web y su satisfacción.
  • Utilizar diferentes estrategias de caché para diferentes páginas o secciones de la web y no simplemente una para todo.
  • Tener varias PWAs si la web es tan grande y las secciones tan diferentes que puede tener sentido gestionar más de una.
  • Personalizar la página default (la offline) al nivel incluso de modificarla según campañas o promociones sin esfuerzo.
  • Guardar para leer después a demanda del usuario.

Una vez que entras, se abre un mundo de posibilidades, si no entras, no es algo que tenga mucho sentido tener. Es una gran inversión para probablemente no ver los beneficios nunca. Si de verdad los beneficios superan los costes, es necesario un experto que le

pueda sacar partido, un arquitecto que sepa sacarle "jugo" a lo que ofrece, y que durante el desarrollo no cree problemas de seguridad.

 

Usar o no usar Framework

 

Frameworks como Angular o React ya traen de caja la posibilidad de tener PWA implementada, si no se usan éstos y en la web en la que implementar hay JQuery o VanillaJS o simplemente se requiere que sea agnóstico se puede usar Workbox para tener más libertad. En caso de no querer framework, sin muchos problemas se puede enfrentar uno mismo con modificaciones de entradas en la base de datos (del navegador) o la caché. Usar framework está bien para funcionalidades básicas, aunque normalmente para trabajos más avanzados, suelen limitar los pasos y es necesario mezclar código escrito con y sin el framework.

 

Scopes, escalabilidad y mantenibilidad en caso de aplicación compleja

 

Este punto siempre es importante y cualquier desarrollador con cierta experiencia orientará su trabajo a que esto sea posible. Una PWA, si es básica y no se quiere nada con ella más que esté ahí, no ocupa nada, tres líneas en la web y 10 en su hilo o código propio.

Si se trabaja en ella, puede crecer enormemente y por ello es interesante usar varios archivos, diferenciados por carpetas y que cada uno tenga claro para qué sirve y cuál es su propósito. En caso de que por ejemplo se tengan varias estrategias de caché, según distintas funcionalidades, es interesante que cada una tenga su sección, propósito y código reutilizable. Para mantenerlo, siempre será más sencillo de depurar si los archivos son independientes, incluso se puede tener en varios archivos distintos que carguen en el navegador según sea necesario y no todo en el mismo (durante el runtime). Aunque se use un framework, sería interesante valorar este punto de cara a maximizar la performance del conjunto.

Para los scopes, teniendo una web con secciones muy diferenciadas, sería interesante tener varios service workers, cada uno independiente y dedicado a su sección, se puede controlar por url el ámbito de cada uno y esto por suerte es una característica básica.

 

¿Necesita mantenimiento?

 

La respuesta es, depende, como en todo. Es una "tecnología" que está creciendo, Google desarrolla nuevas funcionalidades y posibilidades, más permisos desde los navegadores para poder almacenar y gestionar las aplicaciones que surgen del uso de las PWA. Al ser algo en lo que tienen puesto foco, cambia con frecuencia y siempre es bueno aprovecharse de las novedades. Por el contrario, si como se hace referencia en varios puntos de este artículo, solo es para decir que la web es PWA, es cero mantenimiento.

 

Mal uso de la caché y pérdida de la seguridad que se proporciona desde el servidor

 

Con una mala gestión de la caché, con una política de cachear todas las peticiones, se provocan brechas de seguridad. Se guardan en el navegador datos y peticiones a back que no se pretendían guardar y esta información permanece en el navegador de manera indeterminada con independencia de si es información confidencial o no. Este desconocimiento ocurre tanto, que es posible que pronto Google haga algo para evitarlo. Con la PWAs solo debería cachearse aquello que sea imprescindible para poder navegar offline y ahí no es recomendable incluir nada privado, la mejor estrategia es tener tan integrada la PWA que en los huecos que haya información privada poner “esqueletos” defaults o aguantar esa información privada durante pocos minutos, eliminandola junto con la información de logado si pasa demasiado tiempo.

 

Sacar el máximo provecho a cada una de las aproximaciones para cacheo

 

De las que existen, siempre hay tendencia a querer usar la misma, o como mucho dos. Lo correcto sería que para cada caso particular y aislado, decidir cuál es la mejor aproximación.

Por ejemplo, ¿Cuándo usar la “Stale while revalidate”? es complicado aunque no lo parezca a priori decidir el cuándo usarla como estrategia. Lo que se muestre en la web, siempre siempre siempre, estará desactualizado y provendrá de la caché. Para más inri, las peticiones a servidor se realizan o se intentan realizar, también siempre. Parece llevarse lo malo de ambas partes y sin embargo sin tener conocimiento, es de las más lógicas a usar. Lo más interesante, si hay peticiones a servidor un poco lentas, sería mostrar lo cacheado inicialmente y en cuanto la petición lenta termine actualizar la vista si fuese necesario, incluso indicar de algún modo user-friendly de que cierto campo ha cambiado con respecto a lo inicialmente mostrado (¿con un resaltado temporal?). Al final está bien la velocidad, pero que el usuario vea la información cambiar delante de sus ojos sin ningún aviso, parece que está mal implementado o la web está mal hecha, y sin embargo es justo lo contrario. Esto último es de lo más importante a gestionar, las expectativas y reacciones, ahí está la diferencia entre una web bien desarrollada y mal, en los detalles (dejando fuera el UX).

 

Analítica de uso

 

Es muy interesante tener analíticas para cualquier aplicación o funcionalidad que se desarrolle, sin embargo para las PWAs es más importante si cabe. Lo es para, por ejemplo, saber si los usuarios están teniendo una respuesta mejor o más rápida de navegación, si todos los usuarios se están beneficiando o para si, en algunos de los despliegues que se realicen, se ha empeorado la performance que hubiese.

Se puede utilizar la analítica de la web para precisamente cachear aquellas páginas más visitadas o que se quiera inducir a que tengan más visitas. Además, gracias a, por ejemplo, Workbox, toda la navegación que se realice en offline, se manda al servidor una vez se recupere la conexión automáticamente, para saber incluso así la navegación o la lógica seguida en la navegación de la web por parte del usuario en todo momento.

Todo esto está muy bien, pero hay que cuantificar, tanto en aumento o disminución de visitas como en mejora o pérdida de performance. la pregunta sería ¿Qué se puede medir? La respuesta no es muy satisfactoria. No todo realmente, hay algunas limitaciones o para conseguir algunas mediciones hay que realizar una pesada lógica que al final empeoran esa performance inicial. Algunos ejemplos de mediciones que se pueden tener en cuenta:

  • Tiempos de carga antes de tener PWA y después.
  • Cantidad de visitas antes y después de implementar la PWA.
  • Tiempos de carga teniendo una buena CDN y unas buenas políticas de cacheo vs lo conseguido por los fetch que permite la PWA.
  • Tiempo de primera renderización. Tiempo invertido en repintados.
  • Tiempos de carga en offline vs en online.
  • Tiempo hasta el onload, o tiempo hasta tener una página que responda a los movimientos del ratón.
  • Tiempo hasta que haya algo útil que visualizar en la web más que un loading o un skeleton.
  • Cantidad de gente que se descarga y usa la PWA como tal o se beneficia de ella.
  • Cantidad de visitas que se consiguen aumentar procurando dirigir a los usuarios hacia páginas precacheadas que no tardan ni un instante en estar disponibles.

 

Usar una shell para mejorar percepción de velocidad

 

Su uso se está extendiendo bastante rápido, sobretodo en dispositivos móviles, y con razón. En ocasiones se hacen peticiones al servidor de datos que tardan en recuperarse incomprensiblemente mucho, bien por el volumen o bien por una lógica pesada. Para conseguir distraer al usuario, para hacerle pensar que la web es mucho más rápida de lo que lo es en realidad se puede usar este trick sistema.

Simplemente consiste en tener una plantilla vacía que se muestra antes incluso de que la petición http realizada devuelva su OK (status 200) correspondiente. Esta plantilla tendrá los espaciados, círculos, huecos, cabecera o pie de página, etc. vacío, de modo que enseguida parece que en la página ya hay cosas, cuando en realidad, en cuanto la página haya cargado, todo esto desaparecerá (en caso de que realmente sea shell) y será sustituido por el contenido real.

Esto se puede conseguir sin usar la PWA, pero vendría con la respuestas del servidor, al hacerlo con la PWA desde el milisegundo cero ya se podría estar mostrando al usuario. Una pregunta que puede surgir a raíz de esto, es, ¿Por qué no se muestra la cabecera y pie real, que siempre son los mismos y solo se modifica el contenido central? La respuesta es simple, SEO. Esas siglas deben estar presentes y tenidas en cuenta por encima de todo en cualquier desarrollo y las PWAs no son una excepción.

Si el sistema de los crawlers estuviese más avanzado, las web funcionarían mucho más deprisa, el único problema es que de momento no ejecutan scripts, o no lo hacen lo suficientemente bien y por ende, todos los avances que existen en este sentido se encuentran con un muro que continúa muy alto.

 

Lo que no te cuentan. Luces y sombras

 

La caché es muy peligrosa si no se trata con pericia y sin utilizar todo el potencial, mejor usar lo que ofrece http con los códigos de respuesta, los 304 o las cabeceras para cachear que son universales (y deberían estar bien configuradas), no como las PWA que no funcionan en algunos navegadores o están menos rodadas.

Cómo sombra, destacar que puedes hacer un man in the middle qué no se detecta, completamente válido y funcional. Ningún antivirus ni el navegador se van a percatar de que está ahí, quizá ni el propio dueño de la web se de cuenta de que está ese service worker leyendo todas las peticiones en claro, con independencia de que sea https o no. Todas las contraseñas y datos se pueden ver comprometidos y en ningún momento saltar una alarma. Lo normal es que cuando se hackea una web sea para hacer redirecciones a otra y la otra tener tráfico o intentar conseguir acceso al servidor o simplemente tirar el servidor, esto es completamente diferente, es peor que estar en una red de wifi pública con alguien viendo las peticiones (aunque solo aplica para una web y no toda la navegación..)

Al final una PWA es un wrapper que se pone por encima de la web y tiene control absoluto sobre todo lo que ocurra en ella, bajo el scope designado.

 

Hacia dónde parece evolucionar, hacia dónde nos llevan. Microsoft store

 

Ya existe Chrome OS el cual no instala nada. ¿Todo? es web para evitar problemas de seguridad. Si no lo instalas, no se ejecuta. Al menos este problema, se erradica de raíz.

Lo básico antes de entrar en materia, es para quién tenga menos contexto, saber qué es. En pocas palabras, una manera de acercar lo que conocemos por las páginas web a las aplicaciones instaladas que tenemos en el móvil o en el ordenador.

Ya existe una Microsoft Store donde cualquiera puede subir su PWA y hacerla disponible. Al subirla, se podría decir que se transforma en aplicación instalable como cualquiera de Office, por decir alguna. De momento no existe una gran variedad de aplicaciones aquí (tampoco pocas) pero por seguro que es algo que va a crecer mucho y es mejor tener presente este hecho por si acaso luego se hace más caro, más difícil o más raro que alguna web no esté ahí presente. Mejor ser de los primeros y no los mejores, que llegar los últimos, que por mucho que sea mucho mejor al haber tenido más tiempo o aprovecharse de errores de otros, ya no será quien se lleve la mejor crítica o la mayor parte de visitas.

Mejor adaptarse que quedarse atrás, por si de repente empiezan a promocionarlo más. Es un carácter diferenciador con respecto a competidores que seguro vale la pena dedicar unos minutos, en principio no es difícil ni caro poder aparecer en los listados o buscadores.

 

Integraciones

 

Integración con un CMS

Aunque parezca un poco raro. Se puede hacer. Para quien no lo sepa, un CMS es un gestor de contenidos, una manera más sencilla de almacenar, editar y visualizar los textos que se usan en las diferentes páginas, además de poder modificar desde aquí el modo de visualización y de poder reutilizar dichos contenidos o textos.

Sin más, desde el CMS se podría por ejemplo gestionar qué páginas se pueden cachear en el navegador y cuáles no, qué páginas tener precacheadas, incluso antes de que el usuario las visite, durante cuánto tiempo las queremos tener cacheadas, etc. Esto resulta de gran utilidad para tener enlaces a estas páginas desde una página default que indique al usuario que en estos momentos no tiene conexión a internet (de normal aparece la default del navegador que se esté usando). El visualizar esta página no debe suponer un impedimento, tendrá una gran cantidad de páginas que puede seguir visitando y disfrutando sin necesidad de esa conexión a Internet. Puede seguir viendo productos, o entradas de un blog, o información de utilidad en una aerolínea cuando se viaja al extranjero y no dispone, nada más llegar, de conexión a internet.

También es muy interesante para campañas o promociones de productos para los cuales se dedican páginas completas, se puede precachear la nueva y eliminar de la caché las antiguas (el almacenamiento es finito) y que, sin haberlas visitado, ya estén disponibles para la navegación offline.

Con el CMS se pueden gestionar también las notificaciones push, los textos e imágenes a mostrar así como el enlace al que apunta dicha notificación, durante cuánto tiempo mostrarla, tanto en lo inmediato como en la duración de la promoción y segmentar por perfiles o roles de usuarios según exista o no esté perfilado.

 

Notificaciones sin pagar un servidor de notificaciones push

 

No es lo mismo, tienes menos funcionalidad y está limitado, aunque como prueba para saber si merece la pena invertir en ello puede ser muy interesante.

Teniendo contratado o posibilidad de uso de un servidor de notificaciones push, esto probablemente no tiene mucho sentido, si por el contrario, se está valorando la posibilidad de tener notificaciones en el dispositivo, tanto móvil como desktop, puede ser una buena opción además que no conlleva un retrabajo para la mayoría del desarrollo que involucra. Estas notificaciones solo se mostrarán cuando la aplicación esté activa.

Se pueden tener notificaciones simples, como un aviso de nuevas funcionalidades desarrolladas para que los usuarios las visiten, ofertas de actualización periódica, un chat, etc. O se puede diseñar un complejo sistema de notificaciones que el propio usuario pueda gestionar y activar/desactivar para las distintas acciones que ocurran en la web.

 

Uso de PWA como wysiwyg

 

Cómo uso fuera de lo común, se puede poner por encima de por ejemplo una aplicación Angular, a modo de wrapper, y cómo resultado tendrá el control (siempre en un entorno preproductivo) de todos los labels que se usen y que un usuario contribuidor de textos pueda clicar, editar y modificar dichos textos sin siquiera necesitar un CMS o una herramienta externa.

Se trata de convertir todos los textos existentes en enlaces/botones.

Explicado brevemente sería:

  • Parsear y editar el html que se va a renderizar antes de pintarlo. Cambiar los textos planos a enlaces y los enlaces, cambiarlos el href.
  • Al clicar en ellos hacer que se muestre una pequeña modal indicando el texto pulsado y un campo input dónde poner el texto nuevo. En caso de ser una web multiidiomada, mostrar el texto actual para todos los idiomas y un campo input para cada uno de ellos.
  • Guardar los cambios en un archivo temporal imagen del JSON original, que será el que se use para subir al repositorio.

No hay problema en que sea la web con múltiples pasos o varios formularios, Cómo lo normal es que esté en GIT el código, también el de los textos, se pueden realizar commits a través de la API (de GitHub o GitLab) y si existe un repositorio para solo los textos, tener programados despliegues para estos archivos JSON. No debería haber problema si se comprueba que el JSON es válido antes de realizar el commit. Como todo esto se realizará en "local" y no se estará desplegando en ningún entorno preproductivo, en caso de por ejemplo usar Jenkins, se puede hacer uso de su API para iniciar una ejecución de despliegue. De este modo el usuario contribuidor de textos puede ir viendo sus modificaciones al momento y solo cuando esté satisfecho con los cambios, realizar los triggers pertinentes para informar al servidor de los cambios.

Con este ejemplo se puede ver cómo puede tener una gran cantidad de usos y solucionar muchos problemas y abaratar costes sin mucho esfuerzo y con poco mantenimiento. Con un CMS no será sencillo ni trivial conseguir este comportamiento de una manera universal para todas las páginas.

 

Otros usos. Descarga de procesamiento usando el resto de núcleos del dispositivo del cliente para mejora de performance

 

Las PWAs se basan o usan service workers. No son otra cosa. Al igual que en el servidor, en el lado cliente también se pueden usar varios hilos de ejecución, tantos como núcleos tenga el dispositivo.

Estos se ejecutan en un hilo independiente al que usa la propia web para cargar y renderizar todos los recursos, se ejecutan en paralelo y en teoría ni ralentizan ni entorpecen y ni siquiera se mezclan con asincronías del código JavaScript. Trabajan en otro hilo que se comporta igual, en el que se puede tener código síncrono y asíncrono.

Estos hilos en caso de querer usarlos para algo distinto, se pueden usar para realizar pesadas lógicas que de otro modo, por la cantidad de recursos que necesitan, no fuese posible tener en cliente. Usando esto se puede reducir enormemente el uso del servidor y trasladar mucho más peso al cliente. Aquí podría haber una gran reducción de costes de mantenimiento de servidores, aunque estos sean escalables y estén en cloud, se puede reducir mucho igualmente. Por ejemplo, si no supone un problema de seguridad, los buscadores internos de las webs, podrían estar en un service worker. Siempre habría una única llamada al servidor, cacheable con la ingente cantidad de elementos por los cuales se pueda buscar y simplemente este service worker, realizaría la búsqueda necesaria y el hilo principal no se vería afectado ni ralentizado. Se puede personalizar más en caso de que el dispositivo tenga pocos recursos. En este último caso se podría seguir pidiendo al servidor, y solo a dispositivos con más recursos se les pasaría el grueso del cómputo. De este modo se pueden reducir las múltiples peticiones al servidor y evitar o reducir la posibilidad de que se caiga por tráfico alto o reducir el tamaño del servidor y por extensión, costes.

 

¿Se puede recomendar?

 

No, para hacerlo o usarla a medias no. Hay muchas cosas que se pueden hacer mal sin mala intención y empeorar de modo inimaginable la experiencia de usuario. Si se pretende invertir en ella y trabajarla, SI con mayúsculas. Considero que puede aportar mucho, tiene un carácter diferenciador con respecto a competidores y además para webs nuevas, se pueden ahorrar crear apps nativas y solo tener que gestionar y desarrollar una, abarcando todos los usuarios según sus preferencias de uso de sus dispositivos.