Accelerated Mobile Pages y Progressive Web Apps, el futuro de la web diseñado por Google

4 min lectura
Innovación / 27 febrero 2017
Accelerated Mobile Pages y Progressive Web Apps, el futuro de la web diseñado por Google
Accelerated Mobile Pages y Progressive Web Apps, el futuro de la web diseñado por Google

BBVA API Market

Dos de los últimos proyectos de Google tienen relación con las páginas web del futuro, sobre todo enfocados a la velocidad de carga del contenido y la experiencia de usuario. Estos dos elementos se han convertido en una obsesión para el gran buscador, no sólo para los medios de comunicación sino para todo internet. Accelerated Mobile Pages (AMP) y Progressive Web Apps (PWA) buscan generar una experiencia de lectura rápida, satisfactoria, donde la fricción y la frustración se reduzcan al mínimo y los niveles de compromiso de los usuarios se disparen.

AMP es una nueva forma de desarrollar páginas web de contenido estático para que, a la hora de ser renderizadas por un navegador, la velocidad de carga sea lo más rápida posible.

Una página web AMP está formada por tres elementos sencillos:

1. HTML AMP, un documento HTML tradicional, pero con algunas restricciones que, al final, son las que permiten que la página web cargue a toda velocidad (el contenido enriquecido es contemplado siempre a través de extensiones).

2. Una librería JavaScript propia para AMP: sobre ella recae el rápido renderizado del HTML.

3. La caché de AMP: permite que lo que renderiza el navegador sea una caché de AMP (este elemento típico de las páginas web acelera aún más la carga del contenido).

PWA es un proyecto que busca incorporar a la página web de carga rápida algunas de las características que hacen tan potente a las aplicaciones móviles nativas: por ejemplo, las notificaciones push y la alta disponibilidad a través de un icono en el escritorio, además de renderizar siempre bajo un dominio de protocolo seguro HTTPs.

La idea de Google es facilitar un desarrollo donde el contenido cargue siempre de forma instantánea, aún en situaciones de conectividad dudosa; respuesta rápida a las interacciones del usuario con animaciones suaves; y una mayor participación del usuario al verse atrapado por un ecosistema inmersivo.

Primeros pasos en la hoja de ruta de AMP para 2017

Durante los primeros meses de este 2017, Google ha hecho algunos cambios interesantes sobre la hoja de ruta prevista para AMP. Ha mejorado algunos elementos importantes para el producto, entre ellos se han pulido algunos formatos interactivos como las galerías, los carruseles o los módulos con imágenes pequeñas como los formularios; el otro factor decisivo es la carga de la publicidad en las páginas web AMP, ahora mejor optimizada; y tercero, la analítica, sobre todo para aquellas páginas que incorporan steppers y formularios como los ecommerce (mejora la obtención de datos cuando se encadenan procesos dentro de una web). 

Publicidad: esta era una de las grandes carencias de AMP y que Google ha querido resolver durante este primer trimestre de 2017. A partir de ahora, el código de renderizado de la publicidad en AMP será más rápido y con un background de aviso por debajo, para reducir todo lo posible los tiempos de carga y evitar los espacios en blanco que no dan información al usuario. Además, se han producido mejoras en algunos formatos de publicidad fijos como el amp-sticky-ad, que se fija en la parte de abajo de la interfaz. 

Cambios en PWA este 2017

Uno de los últimos cambios de PWA está enfocado a la mejora de los tiempos de carga del contenido, vinculados esencialmente al service worker, un archivo JavaScript que se ejecuta en segundo plano más allá del navegador garantizando, por ejemplo, que las páginas PWA tengan funcionalidad offline como las aplicaciones nativas. Los services workers se sitúan entre el cliente y la red y funcionan como un proxy para cachear contenido.

En gran medida, la velocidad con la que cargan este tipo de páginas es gracias a estos service workers y a que se dispone de una shell, un conjunto de archivos HTML, CSS y JavaScript que se cargan en la interfaz de forma inmediata.

Hasta ahora, el service worker devolvía el resultado de una petición al navegador cuando este se la solicitaba, pero siempre después de arrancar. En condiciones normales, un service worker tarda una media de 50 ms en ponerse en marcha para servir contenido que pueda renderizar el navegador. En el caso de los dispositivos móviles, ese tiempo puede alcanzar los 250 ms en los más rápidos y los 500 ms en los más lentos. Aunque el service worker se mantiene despierto en background entre peticiones en un mismo navegador, a veces se producen peticiones para otro sitio web o desde otra pestaña.

Para poner solución a esta situación, Google ha optado por un cambio de enfoque: en vez de comenzar la carga de la petición para servírsela al navegador después del encendido del service worker, ahora las dos acciones se producen en paralelo, existe algo así como un precarga de la petición sin esperar al service worker. Servir la petición nunca podría llegar antes del encendido del service worker, pero el trabajo en paralelo reduce los tiempos.

¿Te interesan las APIs financieras? Descubre todas las que te ofrece BBVA

También podría interesarte