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

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

by
Read Time:26 minsLanguages:

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 (páginas móviles aceleradas), más conocido por su acrónimo "AMP", un proyecto de código abierto que el mismo Google ha avalado. AMP tiene como objetivo conseguir que los sitios web 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 este sea adoptado ampliamente en la web, 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 visitando simplemente la propia página del Proyecto AMP, o viendo el vídeo de promoción.

Mejor, vamos a ir al grano explicando exactamente qué implica para ti AMP cuando estás creando el código de una página. Vamos a explicar de manera clara lo que necesitarás en la práctica para usar AMP, sus beneficios potenciales, los inconvenientes que puedes encontrar, y lo más importante, si hará o no más rápidos tus sitios web.

¿Por qué me debería importar?

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 sitios 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.

Según lo declarado por Richard Gingras, Director Senior de noticias y productos sociales de Google, cuando hablaba de AMP:

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

De modo que aunque no estés pensando en usar AMP, aun así es aconsejable examinarlo y procurar que tus sitios móviles estén optimizados en un grado similar.

La insignia con forma deen los resultados de búsqueda

Ahora mismo, los sitios web AMP listados en los resultados de búsqueda van acompañadas de un pequeño relámpago destacándolos. Es inevitable imaginar que esto va a hacer destacar a estos sitios sobre el resto.

Esto podría no haber pasado todavía

¿Serán mostrados de esta manera únicamente 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.

¿Hará el uso de AMP más rápidos mis sitios?

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

Esto es así porque la pregunta correcta sería: "¿Más rápido 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 a partir 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, Promotor de desarrollo de Chrome y la web abierta en Google, dijo 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. De momento, el empleo de AMP 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 por supuesto es cierto, 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 en el uso de AMP, lo acabes usando finalmente o no. 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 sitio web. De igual modo, también hay elementos HTML prohibidos, como baseframeembed y algunos otros. El soporte para los 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 solo 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 e iframe son reemplazadas con amp-imgamp-videoamp-audioamp-iframe respectivamente.

También existen un número de elementos diseñados para incrustar contenido de terceros, 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 y 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 relevantes 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 con independencia de que 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 a alcanzar una carga más rápida y eficiente de tus archivos de medios.

Si piensas que tu sitio solo los usará ocasionalmente, los resultados serán igual de buenos que si no usases AMP o implementases las mejores prácticas sin él.

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 la 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 36 ms-468 ms y YouTube en 318ms-386ms. 

Si puedes mejorar la eficiencia de esos tiempos, estará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 horriblemente 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 a todo el código que simplemente no está ahí.

No tienes más que 50kB de CSS, y se trata de 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 no añadirá ningún tiempo de carga extra. Por supuesto no necesitas AMP para eludir código, ya que esto es algo que siempre se debe recordar con independencia de que 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 parte se carga primero permitiéndote iniciar la visualización, 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 carga 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 puedes 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 de altura (height) y anchura (width) especificadas. Esto significa que a pesar de que todavía es posible tener elementos redimensionables y responsivos, AMP sabrá cómo tiene que disponer el diseño de la página antes de que dicho medio se cargue. Esto evita tener que esperar hasta que se cargue una imagen y, a continuación, volver a recalcular el diseño de la página, lo cual ahorra tiempo de renderizado en el proceso.

Algunas pruebas de velocidad

Si has estado siguiendo todo el alboroto en torno a AMP, habrás escuchado a Google compartiendo los resultados de sus pruebas para lograr un incremento de hasta el 85% en la velocidad de 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".

Estas son algunas cifras bastante significativas, 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 puro. 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 la recepción del contenido por primera vez.

Prueba 1: Imagen única

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

AMP VersionAMP VersionAMP Version
Versión AMP
Regular VersionRegular VersionRegular 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 la necesidad 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, ya que de lo contrario te haría revisar demasiadas imágenes.

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 hacer precisamente esto durante la segunda prueba, añadiendo otra imagen de 500kB.

AMP VersionAMP VersionAMP Version
Versión AMP
Regular VersionRegular VersionRegular 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á ligeramente atrás, 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 500kB, con lo que el total sumaban cinco.

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

Resultados

  • AMP: 16,14 segundos
  • Estándar: 26,08 segundos

Aquí vemos que AMP saca una ventaja con un margen sustancial. Si observas atentamente el gráfico de la pestaña network de la carga 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 cargarse al mismo tiempo, lo cual tarda 26,08 segundos.

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

En esta prueba, quería ver la eficacia de AMP comparando los resultados de la página desplazándose durante la carga, algo que probablemente los usuarios entusiastas hagan de vez en cuando.

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

Resultados

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

En esta prueba, el desplazamiento impidió que cualquier 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 VersionAMP VersionAMP Version
Versión AMP
Regular VersionRegular VersionRegular 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, los resultados de la página estándar se redujeron de 26,08 segundos a 6,59 segundos gracias al 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 del umbral de la 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 será cargada, de modo que se cargan las tres primeras imágenes.

AMP VersionAMP VersionAMP Version
Versión AMP
Regular VersionRegular VersionRegular 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 me indicó que un enfoque no es necesariamente mejor que otro, lo que sucede es simplemente que la opción con jQuery es más configurable, mientras que AMP es automático y no tienes que configurar nada manualmente.

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 VersionAMP VersionAMP Version
Versión AMP
Regular VersionRegular VersionRegular 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 solo cuando existía suficiente contenido en la página asistido por la priorización de 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 de velocidad podrían ser proporcionadas si las cinco imágenes de la página que utilicé en la "Prueba 3" son 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 su URL, o cdn.ampproject/c/s/ si la estás cargando a través de https. Por ejemplo:

En la práctica, la implementación de la red CDN consiste en la inclusión de un enlace en la sección head de la versión estándar de la página apuntando a su propia versión AMP. 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 CDNAMP Served from AMP CDNAMP Served from AMP CDN
AMP servido desde AMP CDN
AMP Served from GitHubAMP Served from GitHubAMP 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 privado, que sabía de hecho que no tenía una optimización de velocidad de carga fuera de lo habitual.

AMP Served from AMP CDNAMP Served from AMP CDNAMP Served from AMP CDN
AMP servido desde AMP CDN
AMP Served from Personal HostingAMP Served from Personal HostingAMP 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, del 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 linkPre AMP linkPre AMP link
Sin AMP (enlace)
Post AMP linkPost AMP linkPost 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 y después de AMP, el cual 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 con The Guardian, el mismo artículo se prueba exactamente en cada uno de sus formatos.

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

Resultados

  • Sin AMP: 20,44 segundos
  • Con AMP: 2,74 segundos

Bien, ahora sí estamos hablando de algo sustancial. 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% obtenido en 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.

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

La segunda, ¿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 también 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, no solo depende de las consideraciones técnicas de tus sitios, sino también de las necesidades prácticas de las empresas propietarias de esos sitios.

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.
  • Prefieres que AMP te guíe durante tu proceso de optimización en lugar de gestionarlo manualmente tú mismo.

Al mismo tiempo, si realizar la optimización de tus sitios como prefieras está dentro de tu poder de decisión, 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, lo que quiero decir es que afirmar que AMP en sí no es rápido, es una explicación errónea.

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 más adecuada en tu caso.

Conclusión

AMP sigue siendo un proyecto muy reciente, por lo que es buena idea vigilar su evolución. 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 en las 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 los resultados de estas pruebas podrían quedar obsoletos. Al mismo tiempo, aparte 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.

Creo 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 estar pendiente de los comentarios realizados por los primeros que hayan adoptado AMP. La razón por la que digo esto es porque cabría suponer que solo 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 quedar pronto muy desfasados al igual que sucedió con las intros animadas de sitios usando Flash.

Y eso es algo de lo que todos podemos alegrarnos.

Enlaces relacionados:

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.