El anuncio del Accelerated Mobile Pages Project (AMP) por parte de Google deja completamente clara una cuestión: a pesar de que los smartphones y otros dispositivos móviles empiezan a parecernos ya un elemento que ha estado con nosotros desde prácticamente el principio de los tiempos, la realidad es que su uso para la navegación web seguía en realidad utilizando protocolos y estándares propios de la pantalla del ordenador, simplemente adaptados para pantallas de menor tamaño. Lo más que se solía hacer era, por parte del creador de contenido, generar una versión móvil, habitualmente con menos elementos, que se acomodaba al espacio disponible – diseño responsive – en función del user agent que identificaba algunas características del sistema.
El resultado era, en muchos casos, páginas muy poco optimizadas para su visualización o uso en dispositivos móviles, a pesar de estar teóricamente preparadas para ello: la idea estaba obviamente clara, pero la «caja de herramientas» seguía siendo básicamente la misma.
Lo que estamos viendo desde hace algunos meses con ideas como Snapchat Discover, Facebook Instant Articles, Apple News y ahora con Google AMP supone básicamente eso: el cambio de caja de herramientas, el desarrollo de nuevos procedimientos que de verdad planteen una optimización real diseñada desde el principio para la movilidad, sin herencias del pasado.
Básicamente, lo que AMP significa es un conjunto de restricciones en las funciones que pueden ser utilizadas de HTML, CSS y Javascript, de manera que se obtiene un rendimiento muy superior. Se trata de quedarse con los elementos que cargan rápido en una página y prescindir de los que cargan de manera más lenta: ningún script creado por el usuario ni por terceras partes, ningún elemento embebido o multimedia más allá de los específicamente diseñados para ello, y nada cuyo consumo de recursos no podamos controlar con mano de hierro. Las funciones que antes llevábamos a cabo con esos recursos ahora «proscritos» pasan a realizarse con elementos propios creados y optimizados específicamente para ello. A partir de ahí, si añadimos además procedimientos de cacheado muy eficientes, podemos plantearnos páginas que cargan de manera casi instantánea, y una experiencia de usuario que al principio será llamativa, pero que tendrá mucha más importancia cuando simplemente sea «lo normal» y observemos por comparación las páginas que no lo utilizan.
El AMP de Google es un movimiento de respuesta de esos que gustan tan poco a la compañía: se ve obligada a platearlo ante la evidencia de que, en caso de no hacerlo, el fenómeno iba a tener lugar sin ellos. Como creador de contenidos, la decisión de participar en unos Instant Articles de Facebook que te ofrecen incrementar tus ingresos de publicidad al exponer potencialmente tu contenido a más personas (por el número total de usuarios de Facebook y por la potencia de los algoritmos de recomendación) y que incluso te ofrecen la posibilidad de aportarte ingresos extra mediante la publicidad de la propia red (siguiendo el esquema clásico de comisiones del 70% – 30%) era, como dirían en El Padrino, «una oferta que no se podía rechazar». La idea de que Facebook «se coma internet» y se convierta en el lugar donde mayoritariamente se informan sus 1.500 millones de usuarios resultaba aterradora, por mucho que parte de esos contenidos pudiesen llevar embebida publicidad gestionada por Google. A Google, que Facebook, Apple o incluso Snapchat en el segmento más joven se conviertan en partes significativas de la dieta informativa de un número importante de personas es una circunstancia que, lógicamente, le da mucho miedo. De ahí que el contraataque no se produzca simplemente con un producto de Google, sino con una solución completamente de código abierto, con una licencia Apache completamente business-friendly, y disponible en Github, el repositorio más popular.
¿Qué debe hacer el usuario ante esto? Simplemente, sentarse a disfrutar: se encontrará con que un número cada vez mayor de páginas se cargan a una velocidad que al principio les resultará sorprendentemente rápida, pero que pronto se convertirá en el estándar esperado. Para el creador de contenidos, las opciones son también muy pocas: quedarse fuera implica arriesgarse a ser ese por cuyos contenidos hay que esperar, en medio de un entorno en el que todo se mueve mucho más rápido, algo competitivamente insostenible. La única forma de afrontar esta situación en la que las empresas tecnológicas han conseguido hacerse con las claves de la experiencia de usuario es tratar de estar en todo, de apuntarse a todo, y de jugar con todas las barajas. Quien pierda oportunidades y se retrase, no saldrá en la foto, perderá canales que prometen convertirse en muy importantes tanto a la hora de aportar páginas vistas como ingresos, y podrá perder mucho más si los algoritmos de la propia Google, que penalizan de forma severa las páginas con tiempos de carga lentos, lo degradan en sus páginas de resultados.
Si tu negocio son los contenidos, ya puedes estar dedicando recursos, personas y esfuerzo a trabajar con todos estos nuevos formatos, porque no hacerlo te puede llegar a costar mucho. En este mundo, si pierdes la relevancia en buscadores que te trae el importantísimo tráfico de descubrimiento, te quedas al margen de los algoritmos de recomendación que hacen lo mismo, y ofreces además una experiencia de usuario sensiblemente peor, estás condenado a un rápido fracaso. Estratégicamente podrás pensar lo que quieras sobre la conveniencia de meterte de cabeza en una plataforma en la que todo parece controlado por grandes empresas tecnológicas frente a otra en la que todo respondía a estándares abiertos… pero en la práctica, la gran verdad es que no vas a tener ninguna otra opción. En carrera de la reinvención de la web móvil, convertida en la verdadera plataforma del futuro que nadie puede ignorar, el disparo de salida ha sonado ya.
This article is also available in English in my Medium page, “The mobile web: ready, steady… go!»
Muy buen artículo. El problema que veo es que de momento hay que esperar, aunque hay que estar atentos para ver que plataforma o plataformas se imponen, porque invertir en todas es imposible, al menos para los más «pequeños».
El tema es que imponerse como tal, no se va a imponer ninguna. Cada una tendrá su canal, funcionará razonablemente aunque solo sea por la tracción que tienen como marca, y en breve veremos un escenario en el que las noticias son leídas sobre todo en Facebook, en Apple News, en distintos sitios además de en su cabecera. Hay que plantearse estar en todas…
Desde luego, es rápido. Pongo aquí 2 enlaces, el primero a un artículo «normal» y el segundo a ese mismo artículo en AMP:
http://www.theverge.com/2015/10/7/9467149/google-accelerated-mobile-pages-caching-preview
http://www.theverge.com/platform/amp/2015/10/7/9467149/google-accelerated-mobile-pages-caching-preview
Otro ejemplo de rapidez. El propio buscador de Google en versión AMP:
https://www.google.es/webhp?esrch=AcceleratedMobilePages::Preview,AcceleratedMobilePagesDesktop::Promo&gws_rd=cr
La verdad es que algo así era necesario. Es increíble la cantidad de tiempo que perdemos esperando a que se carguen las páginas.
Enrique: ¿te animas a hacer una versión AMP de este blog? :-)
Seguramente sí. Pero no te me quejes mucho, que ahora va como un tiro!! ;-)
Jejeje. Aguardo impaciente. ¡Contemos los milisegundos!
Krigan, claro que carga más rápido…..la versión AMP (yo la llamaría MIN) ‘pesa’ mucho menos, al no cargar los gráficos del panel derecho e inferior.
Eso ya lo hacían los globos para ascender más rápido, se llama echar lastre :-)
Lo que muchos hacemos con un simple AdBlock.
Yo no lo veo claro sinceramente.
El progreso no se consigue restringiendo si no aportando nuevas soluciones y posibilidades.
Y mucho menos si estas restricciones significan que tienes que desarrollar el site de dos formas diferentes.
De momento me parece un paso atrás con lo que nos proporciona el responsive, algo que tampoco creo que sea una solución definitiva al problema móvil.
Una solucion semejante es tener instalado memcached en el servidor. Con esto se mejora el tiempo de respuesta. Aunque no es una solucion distribuida tipo CDN como de seguro lo sera AMP a futuro.
Saludos Sr. Dans, desde Villa Altagracia, Republica Dominicana.
A veces no te queda otra que sonreír y sentarte admirado ante los hypes y los acontecimientos que se producen en comunicación. Lo que se está viendo estos últimos días con AMP html es un auténtico fenómeno de expectativas desmedidas ante el panorama, en el que los medios tradicionales se están viendo desplazando del foco de la comunicación en los dispositivos digitales.
Leo titulares (Google News) y lo único que se comenta, convenientemente aderezado con guiños a los editores desde la nota de Google, es que se trata de una «nueva plataforma de publicación» para los contenidos de los editores de contenidos.
Cosas como:
«La prensa digital se reinventa» (El País)
«Plataforma de noticias » «Navegación mejor y más rápida de noticias en el móvil»
«Google y grandes diarios del mundo, crean AMP»
Y todas así.
No sé, pero da la impresión de existe cierto «War nerves» entre los editores de contenidos y no sin motivo.
AMP html no es ninguna revolución. Es un Framework desde el que pretende crear un filtro que separe el grano de la paja, en este caso, la paja son los formatos no deseados en una plataforma móvil y ofrecer un servicio de «Content Optimization» en su llegada al mercado de los CDN, al que llega con algo de retraso.
Ya existen soluciones bastante más completas y eficaces de «Mobile Content Acceleration» «Content Distribution Network as a Service» que la que ofrece Google, por citar algunos de los más conocidos;
Cloudfront Cloudflare, aiMobile, revapm, peerapp, kwicr, incapsula, AdaptiveCDN, Flashnetworks, etc.De esta forma, Google trata de evitar el revuelto de formatos y falta de uniformidad que se está produciendo en las Paginas «Responsive» y los diferentes mobile XML sitemap que se generan a la hora de mostrar contenidos. Actualmente se duplican paginas para desktop y luego «sitios móviles» en diferentes formatos.
Habrá que ver las consecuencias de lo que entiende Google como una página «Mobile friendly» en términos de posicionamiento, cuando es a través de cualquier CDN de terceros. La etiqueta «Slow» de Google puede desatar una guerra de aceleración y reducción de datos en los móviles.
Evidentemente, el cache de «Mobile CDN» que ofrece Google queda restringido a las páginas que usen su formato, AMP html.
Y desde luego, plantea cuestiones bastante interesantes – y largas de explicar – en términos de Ad serving, targeting, tracking y analíticas, que relegará unas tecnologías en beneficio de otras.
Por lo que he podido ver del código en Git Hub, solo se admiten redes de anunciantes con cierta conformidad a los estándares de Google y no elude a los Ad Blockers, sino más bien, prioriza a la red nativa de ads.
Lo que hacen los editores al adoptar el AMP html es ahorrarle parte de trabajo a Google adoptando un formato para «estar en esa tecnología» y retratarse ante un servicio de una empresa que mantiene una notable predominancia en el mercado. De forma muy parecida a lo que sucedió con el protocolo Wap.
O por supuesto, posicionarse ante cosas Open Graph de Facebook y otros. E incluso a soluciones de Network Caching especificas para dispositivos IOS.
Esa optimización de contenidos previa, le evita a Google el scrapping de esos medios para su propio servicio de publicación, que no es este, ni tiene nada que ver con Instant Articles u otros agregadores sociales como el de Twitter.
Creo que plantea cuestiones de bastante relevancia en torno a los «Value add services» y el MobileFirst.
Pero claro, este tipo de cuestiones, parecerá chino y desbordará a cualquier periodista, y ese déficit tecnológico plantea serios retos a las publicaciones la hora de generar ingresos y acabar cediendo un significativo porcentaje de proveniente de su publicidad.
https://azure.microsoft.com/es-es/services/cdn/
https://www.cloudflare.com/mobile
http://www.kwicr.com/
Por cierto Enrique, no quería ser yo quien lo mencionara, pero te han tangado con el diseño responsive de tu página. El cajetín de texto solo tiene 40 caracteres por línea para escribir en el navegador de escritorio, el mismo tamaño que los campos de nombre y e-mail.
Lo que hace bastante farragoso leer y editar con agilidad el comentario antes de darle a enviar.
Si además eres miope, darle arriba y abajo al scroll para poder leerlo, ni te cuento.
El diseño responsive que Google «obliga a usar» para visualizar de forma supuestamente correcta blogs o tiendas online personalmente lo considero horrible y contraproducente. Entras a cualquier tienda virtual responsive desde el móvil y tienes que ir arrastrando producto por producto, que se ven en grande, lo que lo hace superincómodo. Sería mejor que se viese una visión general de la tienda, y tu poder con el dedo desplazarte. Es mi opinión.