Unlimited Wordpress themes, plugins, graphics & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Web Design
  2. AMP
Webdesign

Proyecto AMP: ¿Hará tus sitios más veloces?

by
Length:LongLanguages:

Spanish (Español) translation by Eva Collados Pascual (you can also view the original English article)

A partir del 24 de febrero, los resultados de Google han empezado a incluir enlaces a las versiones de páginas móviles creadas usando Accelerated Mobile Pages, más conocido por su  acrónimo es "AMP", un proyecto de código abierto que el mismo Google ha auspiciado. AMP tiene como objetivo conseguir que las páginas preparadas para móviles se carguen más rápidamente y así ofrecer una mejor experiencia a los usuarios.

Google y el Proyecto AMP están realizando un gran esfuerzo para que AMP sea adoptado ampliamente en internet, y lo están consiguiendo. Automattic está incorporando a WordPress.com soporte para AMP, Pinterest también está incorporando esta tecnología, Twitter también se ha comprometido a ofrecer soporte, al igual que lo han hecho Chartbeat, Parse.ly, Adobe Analytics y LinkedIn,y estamos viendo unirse a sitios tan populares como Wall Street Journal, Buzzfeed, The Guardian, BBC News, The New York Times y otros muchos.

La razón por la cual todas estas compañías lo están adoptando es sencilla: el tiempo de carga. El hecho de que las páginas más rápidas son mejores ya no admite debate, así que en este artículo no me uniré al coro enumerando cada uno de puntos que apoyan esta tesis. También voy a evitar enfocarme demasiado en información que puedas obtener sencillamente visitando la propia página del Proyecto AMP, o viendo el vídeo de promoción.

Mejor, vamos a ir al grano y ver exactamente que implica para ti AMP cuando estás creando el código de una página. Vamos a explicar de manera llana lo que vas a requerir en la práctica para usar de AMP, sus beneficios potenciales y los inconvenientes con los que puedes topar, y lo más importante, si hará o no tus webs más rápidas.

¿Por qué me debería preocupar?

Bueno, dicho de forma rotunda, porque se trata de Google. Como en muchos otros aspectos relacionados con Google, es buena idea adoptar pronto sus nuevos desarrollos ya que nunca sabes cuándo o cómo su existencia va a influir en el rendimiento de tus páginas con respecto a los motores de búsqueda. Es muy posible que las páginas que empleen AMP eleven el listón de los requerimientos de Google en cuanto a velocidad y rendimiento a la hora de establecer el posicionamiento en los resultados de búsqueda.

Tal y como afirmó Richard Gingras, El Director Principal de Noticias y Productos Sociales de Google, hablando sobre AMP:

"...si tenemos dos artículos que a excepción de la velocidad tienen igual valoración, entonces efectivamente daremos prioridad a la velocidad..."

De modo que aunque no estés pensando en usar AMP, es aconsejable en cualquier caso examinarlo y procurar que tus páginas móviles estén optimizadas en un grado similar.

El⚡ Relámpago en los Resultados de Búsqueda

Ahora mismo, las webs AMP listadas en los resultados de búsqueda van acompañadas de un pequeño relápago resaltándolas. Es inevitable imaginar que esto va ha hacer destacar a estas páginas más que al resto.

Esto podría no haber pasado todavía

¿Serán únicamente mostrados de esta manera los grandes sitios de noticias? Todavía es muy pronto para decirlo. Pero podría ser un factor al que valga la pena hacer un seguimiento.

¿Usar AMP hará que mis sitios sean más rápidos?

Aquí tienes la respuesta directa y honesta: probablemente, pero no necesariamente.

Esto es así porque la pregunta correcta sería: "¿Más rápida que qué?"

¿Más rápido que la media de los sitios web pesados con una optimización estándar y común? Probablemente.

¿Más rápido que un sitio web que emplee un diseño de estilo sencillo y optimización avanzada? No necesariamente.

La verdad es que no hay nada en AMP que lo convierta en una bala mágica. No es una nueva clase de HTML (tal y como algunos comentaristas lo han descrito), ni tampoco una tecnología nunca vista que garantice convertir en más veloces a tus sitios. En palabras de Google está:

"...construido enteramente fuera de las existentes tecnologías web, lo que permite a los sitios web construir páginas ligeras."

Si estás al corriente de las últimas noticias en optimización y tienes un alto nivel en comprensión técnica sobre como hacer que los sitios web funcionen asombrosamente veloces, AMP no te va a ayudar en ningún sentido. De hecho, es posible incluso observar pérdidas de velocidad en ciertas circunstancias, aunque probablemente esto cambie a medida que el proyecto evolucione.

AMP no es perfecto, no es una solución automática para todo, ni tampoco lo pretende. Paul Bakaus, Developer Advocate for Chrome y de la Open Web en Google, dice en una presentación sobre AMP:

"En la actualidad, si tú mismo creas tu propio sitio web, y sabes bien lo que estás haciendo y tu sitio es genial, rápido y todo lo demás, AMP no hará que sea mejor, esto es así. Para ser claros, posiblemente no hará que tu sitio sea mejor."

Realmente AMP consiste en una colección de técnicas de optimización relativamente complejas que han sido agrupadas para facilitar su implementación, de manera que no necesites pensar en todas las partes que entran en juego tras los bastidores. Te proporciona un conjunto de reglas estrictas, que si las sigues, te permiten obtener un sitio web más rápido que otro que o bien no esté optimizado o no lo esté a un mismo nivel.

Aunque al mismo tiempo, si prefieres ensuciarte las manos con cada elemento en tu rutina de optimización, puedes implementar tus propias técnicas sin usar AMP en absoluto. El empleo de AMP, de momento, no es esencial, pero saber cómo optimizar hasta el mismo nivel lo será dentro de poco.

Vamos a ahondar un poco más en qué es AMP, en cómo funciona, y veremos algunos resultados de pruebas de velocidad, y después, al final del artículo, retomaremos de nuevo la pregunta "¿Hará que mis sitios web sean más veloces?"

Qué significa AMP para un desarrollador

Oficialmente, AMP es descrito como una combinación de tres cosas: AMP HTML, AMP JS, AMP CDN. Esto es cierto, por supuesto, pero desde el punto de vista de un desarrollador me parece que las tres cosas más pertinentes para ti mientras trabajas con código son:

  1. Mejores prácticas de código con AMP
  2. Elementos HTML propios de AMP
  3. Validador de AMP para asegurarte de haber implementado los anteriores puntos.

En pocas palabras, empezarás creando un documento AMP básicamente copiando y pegando el código que encontrarás en la página de ejemplo dentro de los documentos de AMP. A partir de aquí, el siguiente paso es rellenar tus páginas usando los tres elementos de esta lista, los cuales están basados en AMP HTML y AMP JS.

Nota: AMP CDN puede utilizarse automáticamente y de forma totalmente gratuita para los usuarios de AMP, aunque posiblemente puedas usar también sin problemas otros servicios de CDN como CloudFlare. Por este motivo, y por el hecho de que el CDN no forma parte del proceso del código, lo he dejado fuera de mi lista de los tres aspectos destacados para desarrolladores.

Permíteme que resuma cada uno de ellos.

1. Las reglas de AMP para CSS, HTML y JS

Para empezar hay reglas que al trabajar con AMP ayudan a optimizar cualquier página, así que es buena idea que te familiarices uses o no AMP. Son muy estrictas, y existen algunas cosas que estás acostumbrado a usar de las que deberás prescindir, así que prepárate porque la creación del código te va a resultar un poco extraña al principio.

Por ejemplo, todo el CSS debe estar en línea y dentro de la sección head, contenido entre las etiquetas ...<style amp-custom>...</style>, nada de enlazar a una hoja u hojas de estilo externas. Es poco probable que vayas a querer escribir tu código CSS directamente en tus documentos HTML, así que deberías considerar usar algo parecido a Jade includes o disponer de un sistema de salida PHP para los contenidos de tu hoja de estilo en línea.

Tu CSS tampoco puede pesar más de 50kb. Para verlo con perspectiva, un CSS minificado de Bootstrap, sin el tema, pesa alrededor de 121kb. Un tema añadiría alrededor de 23kb resultando en un total de 144kb, casi tres veces la cantidad permitida. Así que tendrás que aplicarte bien con los estilos y crear código muy eficiente.

Además de todo esto, existen selectores CSS prohibidos, como por ejemplo *, así que no podrás usar más * { box-sizing: border-box } para controlar los espacios de tu web. De igual modo, también hay elementos HTML prohibidos, como baseframeembed y algunos otros. La admisión de formularios está actualmente en desarrollo, así que por el momento todavía no se usa el elemento form ni ningún campo de entrada.

Podrías cargar fuentes web externas, pero sólo de Google Fonts o Fonts.com a través de los orígenes https://fonts.googleapis.com y https://fast.fonts.net respectivamente.

Par revisar todo lo que puedes y no puedes usar en tu CSS y HTML, visita la Especificación AMP para HTML.

La regla principal de AMP es que no se permite en absoluto nada de JavaScript personalizado. Si estás acostumbrado a usar el poder de JavaScript para potenciar tus menús responsivos, o cualquier otra cosa por el estilo, no estás de suerte y tendrás que buscar alternativas. De todas formas esto se equilibra en cierto grado gracias a la presencia de los componentes que integra el propio AMP, como un lightbox y un carrusel, entre otras cosas, lo cual nos lleva a nuestra próxima sección: elementos personalizados.

2. Elementos HTML personalizados

AMP incluye un conjunto de elementos HTML a medida enfocados en los archivos media, y cada uno de ellos usa el prefijo amp-. Existen algunos componentes para sustituir algunos elementos HTML estándar, y otros extras que agregan funcionalidad que habitualmente tendrías que añadir usando JavaScript.

Las etiquetas imgvideoaudio y iframe son reemplazadas con amp-imgamp-videoamp-audioamp-iframe respectivamente.

También existen un número de elementos diseñados para incrustar contenido de terceras partes, como amp-adamp-analyticsamp-pinterestamp-twitter y amp-youtube.

Y finalmente existe lo que yo describiría como elementos para añadir funcionalidad como amp-lightboxamp-carousel and amp-anim.

Para conocer el listado completo visita las especificaciones de los componentes HTML de AMP.

Los elementos a medida de AMP están ahí para conseguir principalmente dos cosas:

  1. Asegurar la optimización del código
  2. Facilitar la priorización de la carga y la optimización

Ya he mencionado antes que los tres aspectos más pertinentes de AMP para los desarrolladores son sus normas sobre las prácticas, sus elementos a medida y el validador para reforzarlo todo. Con esto en mente, dado que es posible seguir las reglas para las mejores prácticas ya uses AMP o no, creo que es determinante para descubrir si debes usar AMP conocer en qué grado tu sitio va a hacer uso de los elementos a medida que ofrece.

Si crees que tu web podría usarlos con frecuencia, es probable que AMP te ayude con una carga más rápida y eficiente de tus archivos de medios.

Si piensas que tu sitio sólo los usara ocasionalmente, los resultados serán igual de buenos que si no usas AMP pero implementas las mejores prácticas.

Una forma de evaluar si AMP te reportará mejoras es tener en cuenta el hecho de que el JavaScript que requiere para ejecutarse pesa 44kb. Así que deben existir suficientes elementos de medios en tu página para que la coordinación con eficiencia de su carga con AMP compense la adición de esos 44kb, y que además te reporte otros beneficios.  Algunos elementos a medida, como los de Twitter y YouTube, requieren scripts adicionales para su carga.

En mis pruebas, el JavaScript de AMP se carga entre los 779ms a los 932ms en una conexión simulada 3G de 750kbs, el script de Twitter se carga en alrededor de 367ms-468ms y YouTube en 318ms-386ms. 

Si puedes conseguir esos tiempos con mejor eficiencia, estás en buena forma.

La importancia del elemento amp-ad

Una de las principales razones por las que existe el proyecto AMP es para dar a los creadores de contenido una forma de monetizar sus sitios web con publicidad sin hacerlos horríblemente lentos y detestables para los usuarios.

El proyecto AMP está intentando eliminar experiencias como el llegar a una web y tener que esperar cinco segundos para ver sólo un anuncio a página completa que bloquea el acceso a un artículo. O intentar leer algo de texto y ser apenas capaz de ver nada porque un banner gigante está ocupando cuatro quintas partes del espacio disponible.

En cualquier caso, ellos quieren evitar este tipo de problemas y al mismo tiempo asegurarse de que los creadores de contenido todavía puedan ganar suficiente dinero con la publicidad que sostiene sus negocios. Aquí es donde el elemento amp-ad entra en juego.

Las etiquetas <amp-ad>…</amp-ad> parecen extrañas al principio, pero realmente constituyen un método unificador y rentable de mostrar los anuncios procedentes de gran parte de los proveedores:

Si la presencia de publicidad ocupa una parte importante en tus sitios, merece la pena que consideres AMP aunque solo sea por su elemento amp-ad.

Para más información sobre cómo usarlo, visita:https://www.ampproject.org/docs/reference/amp-ad.html

3. Validador

El validador de AMP existe para que puedas asegurarte de que cumples las reglas de AMP. Te indicará si escribes código que no sigue las mejores prácticas, y si usas un elemento nativo que debería ser reemplazado por un elemento a medida.

Cuando empiezas a trabajar en una página AMP, para usar el validador basta con añadir #development=1 al final de la URL de su vista previa y después observar la consola en las Herramientas para Desarrolladores de Chrome. 

Si has hecho o haces algo incorrecto, el validador te lo dirá.

Dado que en especial codificar para AMP implica algunos ajustes especiales, es buena idea mantener el validador abierto en todo momento para detectar inmediatamente los problemas que puedan surgir.

Cómo logra AMP mejorar la velocidad

La mejor visión sobre las especificaciones técnicas de AMP en relación a su método de optimización se pueden encontrar en el blog oficial. En cualquier caso, te he prometido un desglose en lenguaje sencillo, así que ahí va:

Código que no está ahí

Gran parte del porqué las páginas de AMP son más rápidas se debe al código que no está ahí.

No tienes más que 50kb de CSS, y este es código que no necesita su propia petición http para cargarse.  No tienes cierto CSS y tampoco cierto HTML. No tienes ningún JavaScript propio, lo que significa que tampoco tendrás cosas como modales, ni pestañas, ni tooltips, ni alertas, etc. impulsados mediante JS. Y más importante aún que todo lo anterior, no tienes que crear código diferente para cinco distintos proveedores de publicidad y tres servicios de analítica.

La ausencia de todos estos elementos te proporciona una ventaja increíble. El código que no está ahí en absoluto, se corresponde con un tiempo de carga igual a cero. Por supuesto no necesitas AMP para eludir código, ya que esto es algo que siempre se debe recordar ya decidas usar AMP o no.

Priorizar la carga y la optimización

Ya hemos tocado el tema de los elementos a medida de AMP y el hecho de que facilitan la priorización de la carga y la optimización.

La forma en que esto ocurre en la práctica es en el momento en el que aterrizas en la parte visible ("abobe the fold") de una página AMP, esta se carga primero permitiéndote la visualización desde un principio, después de esto se cargarán los restantes elementos de medios. También existen casos en los que una página podría cargarse antes de que el usuario navegue hasta ella, pareciendo que se carga instantáneamente.

Todo esto sucede a través de diferentes técnicas, incluyendo cosas como la carga diferida, el renderizado, la conexión y la captura previos. Podrías realmente implementar estos métodos por ti mismo aunque eligieses no usar AMP. En el artículo del blog de AMP que ya mencioné antes, se afirma lo siguiente:

"Todas las páginas web pueden disponer de estas optimizaciones, pero las páginas AMP no pueden prescindir de ellas. Si bien este artículo trata sobre optimizaciones en AMP, también podría ser útil como una especie de lista de tareas para la optimización de un sitio web que no use AMP."

Así que sin añadir nada más, echa un vistazo a la forma en la que AMP gestiona la carga para obtener nuevas ideas sobre lo que puede hacer por tus propios sitios.

Eficiencia del diseño de página

Todos los medios añadidos a una página AMP deben tener sus propiedades height y width especificadas. Esto significa que a pesar de que todavía es posible tener elementos redimensionables y responsivos, AMP sabrá cómo tiene que establecer la página antes de que se cargue dicho medio. Esto evita tener que esperar hasta que se cargue una imagen y, a continuación, volver a calcular el diseño de la página, lo que ahorra tiempo de representación en el proceso.

Algunas pruebas de velocidad

Si has estado siguiendo todo el ruido en torno a AMP, habrás escuchado a Google compartiendo los resultados de su prueba para lograr un incremento de hasta el 85% en la velocidad en las primeras páginas de sus socios. Pinterest realizó recientemente pruebas y descubrió que "las páginas AMP se cargan cuatro veces más rápido y utilizan ocho veces menos datos que las páginas tradicionales optimizadas para dispositivos móviles".

Estos son algunas cifras bastante significativos, así que quería saber exactamente qué había detrás de estas diferencias de velocidad. Como mencioné anteriormente, la gran pregunta es "¿Más rápido que qué?"

Para averiguarlo comencé desde cero con nada más que el código base de página proporcionado por los documentos AMP, y una página equivalente hecha en HTML sin formato. Quería ver lo que sucedía a medida que añadía contenido a una página con los métodos de AMP, y a la otra de la manera estándar.

En cada una de estas pruebas utilicé Chrome Developer Tools para emular un iPhone 6 con una conexión 3G "estándar" de 750kb/s. Las propias pruebas de Google utilizaron esencialmente el mismo enfoque con una "conexión 3G simulada y un dispositivo Nexus 5 simulado".

He repetido las pruebas varias veces para descartar cualquier contratiempo aleatorio que cause retraso en la carga. En los resultados, además te estoy mostrando siempre el menor tiempo de carga de cada prueba. Las pruebas han utilizado el método de actualización de página "Vaciar caché y volver a cargar de manera forzada" para simular el aterrizaje en el contenido por primera vez.

Prueba 1: Imagen única

En primer lugar, comencé por lo básico, incluyendo una sola imagen de 500 kb (de Unsplash) en cada página.

AMP Version
Versión AMP
Regular Version
Versión estándar

Resultados

  • AMP: 6.23 segundos
  • Estándar: 5.48 segundos

En esta primera prueba AMP resultó ser un poco más lento, y si nos fijamos en las capturas de pantalla del panel network de las herramientas de Google puedes ver que se debe a la necesidad de cargar AMP JS además de un tamaño de página HTML un poco superior. El tamaño de archivo HTML más grande fue provocado por el requisito de algunos CSS reutilizables que evitan que tenga lugar el parpadeo de texto sin estilo mientras AMP JS realiza su procesamiento.

Nota: En esta primera prueba he mostrado una captura de pantalla de toda la página que está siendo testeada para que puedas ver la configuración que usé. Para las próximas pruebas voy a describir lo que hice y te mostraré el panel network como de lo contrario será demasiadas imágenes grandes para poner a través de la carga.

Prueba 2: Dos imágenes

Sabía que la idea era que AMP empezaría a salir ganando a medida que se añadieran más medios. Por tanto, empecé a hacerlo en la segunda prueba, añadiendo otra imagen de 500kb.

AMP Version
Versión AMP
Regular Version
Versión estándar

Resultados

  • AMP: 11.14 segundos
  • Estándar: 10.44 segundos

Una vez más, esta prueba AMP resultó ser un poco más lenta por aproximadamente el mismo margen, por la misma razón.

Prueba 3: Cinco imágenes

Hasta ahora en las pruebas el marcado adicional y el JS había estado provocando que AMP se quedará atrás ligeramente, pero ahora era el momento de ver el efecto de la priorización de carga de AMP, en donde el contenido que no aparece en la parte visible de la pantalla ("below the fold") aplaza su carga. Esta vez, añadí tres imágenes más de 500 kb, con lo que el total ascendió a cinco.

AMP Version
Versión AMP
Regular Version
Versión estándar

Resultados

  • AMP: 16.14 segundos
  • Estándar: 26.08 segundos

Aquí vemos que AMP saca una ventaja por un margen sustancial. Si observas atentamente el gráfico de la red para la carga de AMP, puedes observar que carga las tres primeras imágenes en 16.14 segundos y luego permite que el usuario comience a visualizar. Después de eso carga las dos imágenes restantes, que puedes ver que sucede aproximadamente entre la marca de 22 y 34 segundos.

En la versión estándar, por otro lado, las cinco imágenes tienen que ser cargadas al mismo tiempo, lo cual tarda 26.08 segundos.

Prueba 4: Cinco imágenes con desplazamiento de página

En esta prueba, quería ver cómo AMP comparado con una carga durante la cual la página es desplazada, algo que probablemente los usuarios entusiastas hagan de vez en cuando.

AMP Version
Versión AMP
Regular Version
Versión estándar

Resultados

  • AMP: 26,87 segundos
  • Estándar: 26.09 segundos

En esta prueba, el desplazamiento impidió que ningún contenido fuese identificado como "below the fold", lo que hizo que el tiempo de carga alcanzase casi el mismo nivel que la versión estándar. En la versión estándar, como era de esperar, el tiempo de carga no cambiaba si tenía lugar un desplazamiento durante la carga.

Prueba 5: Cinco imágenes con script de carga diferida

Debido a que la ventaja de velocidad de AMP en la "Prueba 2" provenía de una especie de técnica de carga diferida, quería ver cómo competiría contra un script que ofrece funcionalidad similar. Para probar esto, cargué jQuery y el plugin Lazy Load, ambos minificados, en la versión HTML estándar, y configuré Lazy Load para que se ejecutara con su configuración predeterminada.

AMP Version
Versión AMP
Regular Version
Versión estándar

Resultados

  • AMP: 16.14 segundos
  • Estándar: 6.59 segundos

Como era de esperar, la velocidad de carga de AMP era la misma que en la "Prueba 2". Sin embargo, la página estándar se redujo de 26,08 segundos a 6,59 segundos con el script Lazy Load de jQuery.

Sin embargo, aquí es importante tener en cuenta que en la configuración predeterminada de jQuery Lazy Load solo ha extraído la primera imagen, la que estaba visible en la ventana. AMP, por otro lado, cargó además las siguientes dos imágenes que pensó que verías.

Prueba 6: Cambio de umbral de carga diferida

Para hacer la comparación más uniforme, quería asegurarme de que jQuery Lazy Load estuviera extrayendo las tres primeras imágenes, tal como lo hacía AMP. Así que cambié la configuración de umbral (threshold) para el script a 1400, lo que significa que cualquier imagen más allá de los 1400px de la ventana gráfica también se cargaría, por lo que cargaría las tres primeras imágenes.

AMP Version
Versión AMP
Regular Version
Versión estándar

Resultados

  • AMP: 16.14 segundos
  • Estándar: 16.51 segundos

Aquí, con ambas páginas cargando tres imágenes, AMP se adelanta de nuevo por un pequeño margen.

Cargar el mismo número de imágenes concluyó con unos resultados más o menos similares en las dos pruebas, lo que para me sugirió que un enfoque no era necesariamente mejor que otro, simplemente la opción con jQuery era más configurable, mientras que AMP estaba automatizado y manos libres.

Prueba 7: Incrustaciones de Twitter y YouTube

En esta prueba quería ver qué resultados se obtenían con los elementos personalizados amp-twitter y amp-youtube en comparación con el código de inserción nativo de cada servicio. Incrusté un video y un tweet en cada página, usando cada uno de los métodos.

AMP Version
Versión AMP
Regular Version
Versión estándar

Resultados

  • AMP: 11.22 segundos
  • Estándar: 9.56 segundos

En esta prueba, los elementos personalizados de AMP proporcionaron unos resultados un poco más lentos que el uso de código de inserción nativo. Sin embargo, lo que no hice en esta prueba fue apilar varios videos y tweets uno encima del otro para ver qué efecto tenía la priorización de carga de AMP.

Con las imágenes, vimos ganancias sólo una vez que había suficiente contenido en la página que asistido por la priorización de la carga, por lo que es probable que ocurra lo mismo con los videos de YouTube y los tweets.

Prueba 8: AMP CDN vs GitHub

Lo siguiente que quise probar fue ver qué ganancias potenciales en la velocidad podrían ser proporcionadas si la página tiene las cinco imágenes que utilicé en la "Prueba 3" servidas desde la CDN de AMP.

Si deseas probar cualquier página AMP que esté online para ver cómo va a ser servida desde la red CDN sólo tienes que añadir cdn.ampproject.org/c/ antes de tu URL, o cdn.ampproject/c/s/ si se estás cargando a través de https. Por ejemplo:

La forma en que funciona la red CDN en la práctica es la versión estándar de cómo una página incluiría un enlace a la versión de AMP en su sección head. Google seguirá ese enlace, y al reconocer la nueva página como un sitio AMP la almacenará automáticamente en la red CDN de AMP.

Al probar la red CDN de AMP por ti mismo, asegúrate de permitir una carga más larga la primera vez que la página pase por la caché y, a continuación y después de esto, comprueba los tiempos de carga.

Cargué mi página de prueba en el alojamiento de páginas de GitHub y, a continuación, ya tenía una versión cargada en la red CDN de AMP. La comparativa de los tiempos de carga, todavía con una conexión simulada de iPhone 3G, fueron los siguientes.

AMP Served from AMP CDN
AMP servido desde AMP CDN
AMP Served from GitHub
AMP servido desde GitHub

Resultados

  • AMP vía CDN: 16,71 segundos
  • AMP a través de GitHub: 16.50 segundos

Los dos resultados fueron básicamente los mismos, con las páginas de GitHub siendo servidas una quinta parte de un segundo más rápidas.

Prueba 9: AMP CDN vs. un alojamiento personal

No estaba seguro de si GitHub podría estar haciendo algún tipo de vudú para servir las páginas tan rápido como la CDN de AMP, por lo que la siguiente prueba que realicé fue compararlo con mi propio alojamiento personal, que sabía de hecho que no tenía la optimización de velocidad de carga fuera de lo habitual.

AMP Served from AMP CDN
AMP servido desde AMP CDN
AMP Served from Personal Hosting
AMP servido desde el alojamiento personal

Resultados

  • AMP vía CDN: 17.28 segundos
  • AMP vía alojamiento personal: 16.33 segundos

Mi alojamiento personal, sorprendentemente, sirvió la página con la misma velocidad que la CDN. En esta prueba, la CDN realmente tuvo una velocidad un poco inferior, alrededor de diecisiete segundos.

Desafortunadamente no pude crear una prueba en la que la CDN de AMP sirviese una página más rápidamente. Sin embargo, el hecho de que resida en Australia y estar ubicado fuera de una ciudad principal puede tener mucho que ver con esto. Tus resultados podrían ser diferentes.

Prueba 10: The Guardian sin y con AMP

En todas las pruebas realizadas hasta ahora utilicé páginas que no tenían casi ningún CSS, sólo el contenido en bruto. Pero no es así como diseñamos sitios web, ¿verdad? Trabajamos duro para perfeccionar el estilo y el diseño, salpicamos algunos JavaScript para añadir características, y todo esto no lo hacemos de forma poco habitual, podemos ser propensos a usar más código del absolutamente necesario.

Además, ejecutar algunas pruebas colocando contenido muy básico no es lo mismo que hacer pruebas con sitios completos que tienen contenido en vivo, en el mundo real. En este contexto, la prueba real, sin duda, proviene de la realización de pruebas con sitios en vivo antes y después de la optimización de AMP.

Así que eso es lo que hice a continuación, empezando con un artículo de The Guardian. Primero probé la versión HTML estándar del artículo, y luego la versión AMP del mismo.

Pre AMP link
Sin AMP (enlace)
Post AMP link
Después de AMP (enlace):

Resultados

  • Sin AMP: 5.05 segundos
  • Con AMP: 3.87 segundos

Aquí comenzamos a ver una mejora significativa entre las versiones antes de y después de AMP, que reduce en 1.18 segundos el tiempo de carga. Eso es una mejora del 23%, ¡algo bastante sustancial!

Prueba 11: BBC News sin y con AMP

En la siguiente prueba, la última de la que hablaré, comparé la versión predeterminada de un artículo de noticias de la BBC con su versión AMP. Al igual que con la prueba en The Guardian, el mismo artículo se prueba exactamente en cada uno de sus formatos.

Pre AMP link
Sin AMP (enlace)
Post AMP link
Con AMP (enlace)

Resultados

  • Sin AMP: 20.44 segundos
  • Con AMP: 2.74 segundos

Bien, ahora sí estamos hablando de algo. Este aumento de velocidad es masivo. Pasar de 20,44 segundos a 2,74 segundos está incluso un poco por encima de la mejora del 85% de las primeras pruebas de AMP. En realidad es una mejora del 86%.

Echa un vistazo de cerca a las capturas de pantalla, en particular a los gráficos que representan la carga de cada recurso individual con una barra horizontal verde/roja/azul. La cantidad de recursos que se cargan en la versión sin AMP es increíble. Compáralo con el gráfico de la versión con AMP, donde el número de recursos ha mejorado. No es de extrañar que la optimización haya sido capaz de crear una mejora tan considerable.

Aquí, me vienen a la mente dos preguntas.

Uno, ¿podría haberse alcanzado este grado de optimización sin AMP? Sí, creo que podría haberlo conseguido.

Dos, ¿se habría conseguido este grado de optimización sin AMP? No, con toda probabilidad probablemente no lo habría logrado.

Fuera de las pruebas controladas, en una organización real, los desarrolladores pueden querer optimizar un sitio en producción, pero es posible que no puedan hacerlo debido a la presión de colegas que necesitan centrarse en la monetización y el análisis. Ambas partes están tratando de hacer su trabajo, y es posible que no puedan llegar a un acuerdo.

Ahí es donde AMP está intentando intervenir y cerrar la brecha. Crean un marco de optimización estricto que tiene que ser respetado si deseas obtener la aprobación de AMP, algo que hará felices a los desarrolladores. Pero también proporcionan monetización integrada, análisis y posiblemente una mayor visibilidad en Google, lo que hace felices a las personas responsables de los flujos de ingresos.

Si eres un desarrollador que se encuentra en esta situación, estos resultados sugieren que posiblemente AMP sea justamente la receta que el médico prescribió.

Entonces, ¿hará AMP que mis sitios sean más rápidos?

Hemos visto muchas pruebas en este artículo, todo con el objetivo de averiguar si finalmente, AMP hará que tus sitios sean más rápidos. La respuesta, al parecer, depende no sólo de las consideraciones técnicas de tus sitios, sino también de las necesidades prácticas de las empresas que esos sitios respaldan.

Si eres tú mismo quien toma todas las decisiones sobre cómo se construyen tus sitios, AMP puede hacer que tus sitios sean más rápidos si:

  • Estás utilizando suficientes medios (imágenes, vídeo, etc.) como para beneficiarte significativamente de los procesos de carga optimizados.
  • Preferirías que AMP guiara tu proceso de optimización en lugar de gestionarlo manualmente tú mismo.

Al mismo tiempo, si está dentro de tu poder de decisión la optimización de tus sitios como desees, puedes obtener resultados iguales o posiblemente mejores mediante el uso de tus propios métodos de optimización, siempre y cuando estén en un nivel comparable a lo que hace AMP.

Si no puedes tomar todas las decisiones sobre cómo se construyen tus sitios, AMP puede hacer que sean más rápidos si:

  • Te permite convencer a tus colegas para que aprueben su implementación, por lo tanto, te da la capacidad de aplicar optimizaciones para las que de lo contrario no recibirías la luz verde.

Para ser claro, creo que el punto es que AMP en sí no es rápido, esa es la manera equivocada de expresarlo.

AMP te proporciona un método para hacer tus sitios veloces.

No tienes que utilizar necesariamente ese método, pero si deseas un enfoque conveniente o uno que tus colegas acepten, AMP puede ser la opción correcta para ti.

Conclusión

AMP sigue siendo un proyecto muy reciente, por lo que es una buena idea vigilarlo a medida que evoluciona. Lo que significa para tu posicionamiento en los motores de búsqueda podría cambiar en cualquier momento, al igual que los requisitos de uso de AMP, o su rendimiento.

En las pruebas que ejecuté AMP, este ofreció resultados un poco más lentos en ciertas circunstancias, pero a medida que el proyecto continúe estoy seguro de que se volverá más eficiente y estos resultados podrían volverse irrelevantes. Al mismo tiempo, fuera de las pruebas controladas, estaba claro que en los principales sitios en vivo, la aplicación de la optimización AMP era un medio que a veces proporcionaba enormes mejoras de rendimiento.

Siento que decidas utilizar AMP o no, todo el mundo debería al menos echarle un vistazo muy de cerca. Como mínimo, es una gran fuente de ideas para los desarrolladores sobre formas en las que pueden impulsar la optimización de sus sitios.

Con el nuevo despliegue de páginas AMP en los resultados de búsqueda de Google, será muy interesante mantenerse a la escucha de los comentarios realizados por los primeros que hayan adoptado AMP. La razón por la que digo esto es porque se podría especular que sólo continuarán usando AMP si los resultados son una mayor retención de tráfico e ingresos. Lo que suceda en este sentido podría perfectamente resultar en el éxito o el fracaso de AMP.

Hasta entonces, posiblemente la mayor ventaja de la aparición de AMP sea que la optimización de sitios en el mayor grado posible se convierta probablemente en algo cada vez más importante. Los días de hojas de estilo hinchadas y excesivo JavaScript, por no hablar de los anuncios invasivos, pueden pronto quedar muy lejos al igual que sucedió con las introducciones animadas con Flash de sitios.

Y eso es algo de lo que todos podemos alegrarnos.

Enlaces relacionados:

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.