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 hoy en día 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.
y luego BAM! el fuetazo Google cierra las licencias de codigo abierto y quien desee conservar tendra que ceder favores. En todo caso antes de usar adblock nunca hice clic en ningun comercial si es cierto que lo hacen en base a las paginas web que visitas aqui no convence los pocos latinos que hacen clic en esto comerciales son por una oferta falsa o los ad sexys, aunque no se como es en otro pais aqui es asi.
Ten en cuenta que el objetivo no es solo que pinches, sino que se quede marcado en tu subconsciente para que en un futuro, quizás, estés más por la labor de comprar ese producto específico (te resultará más familiar).
Y el caso es que hay publicidad que directamente molesta. Que abusa de la buena voluntad de las personas, o de su desconocimiento, para ocultar el botón de cerrar, o jugar con los formatos para que el usuario pinche sin querer.
Descontando que hace que pese mucho más la web (en algunos casos los scripts de publicidad acaban pesando varias veces más que el contenido propio de la página).
Ahí es donde quizás haya una mejoría en la propuesta de Google, que limita severamente qué se considera aceptable de lo que no.
Nadie trabaja gratis. Pero bueno, si es el único que va en la buena dirección, los de mas que le sigan. Si al final , somos esclavos o de unos o de los otros, pues por lo menos que lo hagan bien. Me parece una buena noticia .Aunque no me queda claro como se implementa esto. Será como un nuevo estándar soportado por unos y por otros no (navegadores)?.
La publicidad en si no es mala. Ya no solo por que de algo se tiene que vivir, si no que es información para el usuario también. Lo que está mal es la forma de implementarla. No se como no se dan cuenta las empresas que no llega al consumidor el mensaje. Apenas se pone en marcha un pop-up , quien no lo cierra al instante?. Claro la web que lo implementa cobra, no le pidas que evolucione, tiene que ser los creativos los que busquen nuevas formas de implementarla. Y no me refiero tecnológicamente
.
Pues me alegra oír eso Federico. En efecto, claro que la publicidad no es mala. Es el abuso del soporte lo que la hace inaguantable.
En principio sería un estándar de desarrollo web. Es decir, que las webs se desarrollarían siguiendo un patrón muy restrictivo si quisiéramos ser compatibles con el mismo. Y sí, dependería en buena parte del apoyo de la industria. Ya sabes que en todo el ecosistema Google está asegurado (Chrome, Android y compañía), y parece que cuenta también con el beneplácito de la mayoría de intermediarios (Facebook, Twitter,…).
También hay que pensar que descontando esas nuevas etiquetas, la mayoría sigue siendo igual. Simplemente que hay muchos elementos que no se pueden utilizar por tema de rendimiento.
Hola, pues perdona: me perdí en la última parte «…este movimiento va en favor de seguir utilizando el tercer entorno vía web y no vía aplicaciones propietarias.»
El tercer entorno de Echevarría? Apps propietarias serían .. simplemente Apps? (no vía browsers)?
Gracias muy interesante artículo. Lo twitteo.
Así es Mauro. A veces tengo ya tan asumido algunos conceptos que por falta de tiempo no profundizo en ellos.
El tercer entorno es el entorno digital, donde la información es un recurso, y que ha estado apoyado hasta ahora en la evolución de la web.
Con Apps propietarias me refiero a que pasamos de ese entorno abierto a otro acotado, dependiente de las murallas del propio servicio (la aplicación) y también el ecosistema (un sistema operativo específico, un market de aplicaciones específico). Una única plataforma de monetización que depende de una única empresa.
De esta manera, lo que antes estaba disponible para cualquiera, ahora solo estaría para aquellos que cumplan y acepten pasar por una serie de criterios (tecnológicos, pero también culturales), con unas limitaciones propias de ese entorno «privado y propietario».
Espero haberme explicado. Cualquier duda pregúntame, que para eso estoy. Y muchas gracias por el apoyo Mauro!