La estrategia de Google por hacerse con el control de la web abierta

Accelerated Mobile Pages

Google nos sorprendía a finales de la semana pasada con la presentación de Accelerated Mobile Pages (EN), la respuesta de los de Mountain View a la jugada maestra de Facebook con Instant Articles (ES) y de Apple con Apple News (ES).

Y lo hace, como cabría esperar, apostando no por una plataforma cerrada (como en el caso de los anteriores), sino con una solución abierta, disponible desde el mismo día de su lanzamiento en GitHub (EN).

La jugada es maestra, ya que dota a los administradores de servicios de una aparente libertad que precisamente es el punto discordante de las propuestas de la competencia.

Ya no se trata por tanto de abandonar la web y utilizar una herramienta controlada exclusivamente por una empresa de servicios, sino de que la web de cada medio o compañía cuente con una versión móvil que cargue lo suficientemente rápido como para que apenas haya sensación de estar abandonando la aplicación de turno y adentrándose en el navegador, para que la web sea instantánea en la experiencia de consumo del usuario.

Y esto arroja algunos tips que creo convenientes señalar, habida cuenta de que Google ni es el demonio ni es un alma caritativa. Que AMP puede ser todo lo abierto que queramos, y proponer algunas medidas que como veremos son verdaderamente recomendables, pero que en síntesis es una estrategia más por controlar un escenario que hasta ahora era lo suficientemente distribuido como para considerarse libre de los tentáculos de cualquier corporación.

Entendiendo cómo funciona AMP

La mayoría de usuarios seguramente no se hayan dado cuenta (de hecho, no tendrían por qué saberlo) que el renderizado web es de los procesos más complejos a los que habitualmente se tiene que enfrentar un procesador.

Hablamos de un conjunto de tecnologías de programación y maquetado muy flexibles (los lenguajes web se basan en recomendaciones, no en obligatoriedades), y que por tanto fuerzan al motor de renderizado a primero intentar interpretar el código, para luego pintarlo en pantalla.

A esto, hay que añadirle que para mantener una sensación de dinamismo en la web, estos últimos años han proliferado tecnologías que se encargan de mantener en segundo y tercer plano el motor continuamente repintando las páginas, y permitiendo así que el usuario tenga la impresión de que todo ocurre en tiempo real.

En el entorno de escritorio, y debido normalmente a la capacidad de procesamiento que tenemos, a contar con ventilación, a que el propio sistema está preparado para una multitarea real, a estar más acostumbrados a las esperas, a disponer por regla general de conexiones más estables (y rápidas) y a no depender en excesivo del gasto energético, el usuario puede sentir que las páginas cargan más o menos rápido, pero no es un aspecto tan diferencial como en entornos móviles, donde hay limitaciones tanto en tiempo (lo queremos todo inmediatamente), como en procesamiento (tanto por potencia como por disipación de calor), como en gasto energético (menor autonomía de la batería).

Teniendo esto en cuenta, Accelerated Mobile Pages ha sido creado como un estándar de publicación que toma un subconjunto de elementos de HTML/CSS (EN) y limita muy severamente lo que se puede hacer, en especial en el documento principal, con vistas a que el motor de renderizado lo tenga muy pero que muy fácil a la hora de mostrar las páginas web en dispositivos móviles (no necesite apenas interpretar lo que el desarrollador de turno quiso decir en el código, y se dedique a pintarlo en la pantalla).

Por ejemplo, se banea el uso de tags como iframe, embed, object, y todos los script de JSON. Los scripts, por cierto, se tienen que cargar en último lugar siempre. Los tags de multimedia de HTML5, img, video y audio, serían reemplazados por su versión light creada ex profeso: amp-img, amp-video y amp-audio. Y claro está, no se permiten scripts cargados en servidores de terceros (todo tiene que estar en local), a excepción de algunos elementos que embeben contenido de servicios ampliamente utilizados en la web actual, como amp-youtube (EN) y amp-twitter (EN), que como puede ver tiene también su propio etiquetado.

Las funciones de CSS de transiciones y animaciones son también simplificadas, el HTML y el CSS se entrega minimizado, y se generan varios sistemas de tracking noscript.

Todos somos conscientes que una web sin javascript (y añadidos) carga como un tiro, pero la idea es buscar un punto medio entre funcionalidad y rendimiento, permitiendo algunos scripts específicos que dotan de lo primero sin afectar exageradamente al tiempo de carga, y añadiendo el cacheado de Google por debajo, que funciona a la vez de CDN mundial.

Aquí es donde el ceño se me frunce, puesto que casualmente entre esos tags permitidos están algunas versiones simplificadas del tracking que como cabría esperar, es parte crítica del modelo de negocio de Google.

Es de paso, una respuesta bastante equilibrada a la paulatina hegemonía del uso de adblockers que empezó hace años en el escritorio, y que estos días está en pie de guerra con el movimiento de Apple.

La cuestión es que donde antes se hacía uso de un javascript abierto para estos menesteres, ahora se plantea el uso de un nuevo estándar que dependería de la maquinaria de Google, y que controlaría tanto esos scripts de monitorización necesarios (supuestamente) para seguir manteniendo la industria publicitaria, como el resto de scripts necesarios para mostrar dinamismo en la web.

La web abierta y la web abierta de Google

Es importante señalar que la propuesta de Google no está cerrada. Es decir, AMP es a día de hoy un proyecto abierto a solicitudes (e interpretaciones) de terceros. Una prueba de campo que propone un escenario en el que la web sigue teniendo cabida.

Es, quizás, el mejor de los males a los que nos vamos a enfrentar en esta tensa guerra fría de la publicidad digital.

Pero no está exenta de riesgos.

Google propone a los medios seguir teniendo el control del contenido dentro de sus webs, a diferencia de las soluciones que ofrece Facebook y Apple (contenido dentro de sus propias plataformas, con vistas a competir en igualdad de oportunidades con terceros, y con un reparto desigualitario de los beneficios, a priori desbalanceado a favor de los medios, con la idea de pagar esa pérdida de control esperable). Pero con el movimiento, parte de la web (la web móvil) pasa a ser controlada, al menos en las capas inferiores, por la compañía.

Todas las páginas serían desarrolladas con tecnología creada por Google, y se mostrarían mucho más eficaz y rápidamente a los usuarios gracias al sistema de CDN y caching de estos.

El corolario final es un entorno que pasa a a ser un poco menos descentralizado, un poco más dependiente de los vaivenes de una corporación.

Y sigo recalcando que veo mucho futuro en la propuesta por acotar qué consideramos scripts adecuados y qué no en la web. Que la situación actual es insostenible. Que la publicidad y el rendimiento web, sobre todo en móviles, debe mejorarse considerablemente para seguir arrojando una alternativa seria al mundo de las apps. Y que al menos este movimiento va en favor de seguir utilizando el tercer entorno vía web y no vía aplicaciones propietarias.

Pero hay algunos flecos que hay estudiar y debatir antes de apostar ciegamente por el que podría acabar siendo el caballo ganador.

 

P.D.: Al menos en este caso podemos hacerlo.