Tráfico y conversión Aitor García Hermida Autor
26 Jan 2017
amp-html
Reading time: 19 mins.
|
Difficulty:

Cómo implementar AMP en tu sitio web

GREAT SCOTT! Marty, Has visto esos tiempos de carga??

En un artículo anterior hemos visto los conceptos básicos de la tecnología Accelerated Mobile Pages (AMP), sus limitaciones y motivos (nuestros y de Google) para usarlo.

En este post vamos a ver en detalle cómo funciona, sus especificaciones técnicas e instrucciones paso a paso para implementar páginas AMP en nuestro sitio web.

AMP: Especificaciones técnicas

Como ya hemos visto anteriormente, la tecnología detrás de AMP se apoya en 3 patas:

1) AMP HTML

O lo que es lo mismo, su propia variante específica de HTML, más restrictiva que el HTML estándar, del que difiere en múltiples puntos. Entre otras cosas:

  • Elimina o restringe la utilización de ciertos elementos: imágenes, formularios, iframes…
  • Añade sus propias etiquetas específicas, por lo general para sustituir funcionalidad restringida. Por ej. <amp-img> en lugar de <img>
  • No admite Javascript, con excepción de la propia librería AMP JS. La funcionalidad adicional normalmente conseguida mediante scripts JS deberá ser sustituida por soluciones estandarizadas vía extensiones o eliminada
  • No admite hojas de estilo externas. Todo el CSS de la página se incluye inline dentro de una única etiqueta <style amp-custom>. También se restringen algunas reglas CSS (ej. @import)

En general, este nuevo estándar está orientado a la carga y renderización rápida de contenido puro y duro (artículos, noticias, fichas de producto…) a costa de elementos secundarios o de navegación (sidebars, menús…) y de funcionalidad más compleja (formularios de contacto, comentarios, scripts de analítica…), cuya inclusión, aun posible, está restringida.

En breve nos meteremos más a fondo con lo que este formato y sus restricciones implican a la hora de implementar.

Es lo que hay.
Es lo que hay.

2) AMP JS

Una librería Javascript que debe ser incluida en todas las páginas AMP, dentro de la etiqueta <head>:

<script async src="https://cdn.ampproject.org/v0.js"></script>

Y que se encarga de realizar las operaciones necesarias para que la carga y renderización del contenido se haga de forma correcta y optimizada: carga asíncrona de recursos externos, interpretación de etiquetas personalizadas…

Imaginamos que, si el proyecto sobrevive y no acaba haciendo compañía a Google Wave de un día para otro, la idea de Google & Co. es que eventualmente sean los propios navegadores los que lo hagan de forma nativa. Pero de momento, esto será suficiente para que puedas ver contenido AMP en cualquier navegador actual, sea en escritorio o móvil.

¡Ah! Y también incluye herramientas de validación y debug

3) Google AMP Cache

Como parte del proyecto AMP, se ha creado una red de distribución de contenido (CDN), de uso automático y gratuito, especializada en almacenar, cachear y servir cualquier contenido AMP.

Esto significa que, aunque sirvas tu contenido desde tu propio alojamiento web, éste podrá estar automáticamente disponible y cacheado en fuentes externas (por lo general, cdn.ampproject.org), que serán las utilizadas para servir el contenido al usuario de forma automática y transparente mediante un sistema estandarizado de URLs. Así, por ejemplo, la versión AMP de este mismo artículo:

https://aukera.es/blog/crear-paginas-amp/amp/

Estará disponible como:

https://aukera-es.cdn.ampproject.org/c/aukera.es/blog/crear-paginas-amp/amp/

Además, al guardar contenido en el AMP Cache se realizan operaciones adicionales de optimización: Sanitización de código, eliminación de comentarios y espacios en blanco, conversión a UTF-8…

Si nuestras páginas pasan correctamente la validación AMP, todo esto ocurrirá de forma automática. Lo único de lo que debemos preocuparnos es del hecho de recordar que nuestro contenido estará siendo cacheado y servido externamente, con todo lo que ello implica: tráfico, analítica, propagación de cambios…

Error de validacion en AMP Cache
Si el contenido no valida correctamente, en su lugar verás esto. Ves? Tu falta de respeto por los estándares ha hecho llorar a la pobre mascota antropomórfica. Debería darte vergüenza.

¿Cómo hacer nuestra web compatible con AMP?

Vale, entonces ¿cómo configuramos nuestro sitio web para que A) Sirva contenido AMP, y B) Google y demás proveedores de contenido lo reconozcan como tal y actúen en consecuencia? En teoría, tenemos dos opciones:

  • Modificar el HTML de todo el sitio web para que sea compatible con la especificación AMP. Teniendo en cuenta las restricciones, salvo que el sitio sea muy simplón y/o tengas muuuuuuucho tiempo libre, vamos a descartar directamente esta opción por imposible, improbable o sencillamente absurda.
  • Crear versiones alternativas de las páginas existentes en formato AMP, servidas bajo otro URL, e informar de la disponibilidad de las mismas mediante una etiqueta HTML especial que veremos más abajo. Evidentemente, este es el método utilizado normalmente y al que nos referiremos a partir de aquí.

Es importante destacar que no es necesario crear alternativas AMP para todas las páginas del sitio. Normalmente, nos centraremos en crearlas para las páginas “hoja” o de contenido final (artículos, noticias, recetas, fichas de producto…), que serán las verdaderamente interesantes para Google y demás proveedores.

Tranqui, el esquema de nuestro AMP es mucho más sencillo que esto
Tranqui, el esquema de nuestro AMP es mucho más sencillo que esto

Implementación paso a paso

Bueno, hora de ponerse a trabajar. Vamos a ver, punto por punto, la estructura base de una página AMP HTML y utilizarla para crear o adaptar, a mano, nuestra primera página AMP.

Para ello, usaremos la siguiente plantilla como punto de partida:


<!doctype html>
<html amp lang="es">
  <head>
    <meta charset="utf-8">
    <script async src="https://cdn.ampproject.org/v0.js"></script>
    <title>[[TITULO]]</title>
    <link rel="canonical" href="[[URL PAGINA ORIGINAL]]" />
    <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
    <script type="application/ld+json">
      {
        "@context": "http://schema.org",
        "@type": "NewsArticle",
        "headline": "[[TITULO]]",
        "datePublished": "2017-01-19T11:22:42Z",
        "image": ["[[URL IMAGEN]]"]
      }
    </script>
    <style amp-custom></style>
    <style amp-boilerplate>body{-webkit-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-moz-animation:-amp-start 8s steps(1,end) 0s 1 normal both;-ms-animation:-amp-start 8s steps(1,end) 0s 1 normal both;animation:-amp-start 8s steps(1,end) 0s 1 normal both}@-webkit-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>
  </head>
  <body>
  </body>
</html>

1. Elementos base

Para empezar, los siguientes elementos son comunes y obligatorios a toda página AMP:

amp-html
It’s the freakiest show
  • <!doctype html> como primer elemento
  • Inmediatamente después, identificar el documento con <html amp> o, si así lo prefieres, su versión original y más graciosilla: <html ⚡>. Opcionalmente, añadir información de idioma con lang=".."
  • <head> y <body>. Duh.

Y, dentro de <head>:

  • <meta charset="utf-8"> como primer elemento
  • La librería AMP JS: <script async src="https://cdn.ampproject.org/v0.js"></script>, preferiblemente inmediatamente después.
  • Una etiqueta <link rel="canonical"> que enlace con la versión HTML original del documento. Más información en Publicación y pruebas
  • <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">
  • Finalmente y justo antes del final de <head>, copiar el código <style amp-boilerplate> arriba indicado, tal cual. Esto incluye unos estilos CSS básicos relacionados con la visualización del contenido.

2. Metadatos

Aunque no es estrictamente obligatorio, sí es muy recomendable incluir metadatos de Schema.org del tipo más adecuado al contenido de la página: en el caso más habitual —un artículo o noticia—, este será Article, NewsArticle o BlogPosting.

Esto ayudará a que los proveedores indexen y muestren nuestro contenido; por ejemplo, hacer esto es necesario (junto con la inclusión de una imagen principal) para salir en el carrusel de noticias de las páginas de resultados de Google.

En la plantilla puedes ver un ejemplo sencillo de una posible estructura schema.org a incluir y rellenar (en formato recomendado JSON-LD). En el repositorio GitHub oficial del proyecto puedes ver otros más complejos, servirán para cubrir los casos más comunes.

Ejemplo datos estructurados articulo AMP
En caso de duda, la documentación oficial deja bastante claro cómo lo quiere, así que…

¡Ah! Ya que estamos, pongamos también un <title>. También podríamos incluir otros metadatos, pero no merecerá la pena si ya nos hemos preocupado de schema.org (a día de hoy Google ignora la meta description, por ejemplo).

3. CSS

Como ya hemos comentado, todo el CSS de la página debe ir unificado e incrustado en el <head>, dentro de una única etiqueta <style amp-custom>.

Dado que también se aplican restricciones adicionales en cuanto a reglas y propiedades admitidas (por ejemplo, @import e !important están prohibidas), lo mejor será limitarse a definir unos estilos base sencillos (tipos/tamaños de letra, colores, etc) para el texto y las etiquetas más habituales (encabezados, enlaces…) y no perder el tiempo creando o adaptando hojas de estilo complejas.

style-amp-custom

Hay una excepción en cuanto a la inclusión de archivos externos, y esto son las fuentes o tipos de letra personalizadas. Se puede enlazar a fuentes externas tanto directamente en CSS (usando @font-face) como con una etiqueta <link> en <head>, por ejemplo:

<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=Roboto" />

Pero ¡ojo!, únicamente se admiten archivos alojados en Google Fonts y otros CDNs preestablecidos (ej. FontAwesome).

4. Javascript

Esta parte es sencilla: Todo fuera. Las únicas etiquetas <script> permitidas son la de la propia librería AMP JS (y extensiones, si las hubiera) y las de metadatos JSON-LD.

Si realmente necesitamos incluir una determinada funcionalidad javascript en la página, tenemos dos opciones:

  • Buscar una extensión AMP que nos ofrezca una solución válida alternativa mediante etiquetas específicas. Por ejemplo, para scripts de analítica, publicidad, botones sociales…
  • Replantearnos si realmente es necesaria… o si la propia página es realmente un buen candidato para tener una versión en AMP.

5. Contenido

A partir de aquí, ya es introducir el contenido propiamente dicho dentro del <body>. Normalmente lo que haremos será partir del contenido HTML original de la página cuya versión AMP estamos creando, y adaptarlo para que pase la validación correspondiente.

La mayoría de etiquetas HTML más sencillas y habituales se podrán mantener sin problemas: párrafos, negritas/cursivas, encabezados, listas, enlaces… Sin embargo, con algunas nos encontraremos con más dificultades, y deberemos adaptarlas o eliminarlas.

Imagen aleatoria no relacionada, pero esto se estaba volviendo un poco espeso y había que poner algo.
Imagen aleatoria no relacionada, pero esto se estaba volviendo un poco espeso y había que poner algo.

6. Imágenes

De especial importancia será la necesidad de adaptar las imágenes. Una de las optimizaciones importantes impuestas por AMP es la de conocer el tamaño exacto de los elementos de la página incluso antes de empezar a cargarlos, para evitar tener que redibujar o redimensionar en tiempo real y así reducir al máximo el tiempo de renderización.

Para ello, el estándar AMP sustituye las etiquetas <img> habituales por su propia alternativa, <amp-img>. El formato es similar, pero con una restricción importante: Los atributos width y height —anchura y altura exactas en píxeles— son obligatorios.

<amp-img src="https://aukera.es/blog/imagenes/amp-html.png" width="800" height="500" alt="take your protein pills" ></amp-img>

Y una ventaja: Podemos asegurarnos automáticamente de que sean responsive sólo con añadir layout="responsive".

<amp-img src="https://aukera.es/blog/imagenes/amp-html.png" width="800" height="500" layout="responsive" alt="and put your helmet on" ></amp-img>

También permite otras propiedades que ayudan a servir contenido optimizado para cada dispositivo, como srcset. Más información aquí.

Ejemplo de etiqueta amp-img con layout responsive y srcset
Ejemplo de uso en AMP by Example

Comentar que si queremos que nuestra página pueda aparecer en el carrusel de noticias de Google, será importante que el artículo incluya al menos una imagen principal, y especificarla como tal dentro de los metadatos Schema.org.

7. Videos y contenido incrustado

Algo similar nos pasará con otros elementos incrustados en la página como videos, audio, iframes… En lugar de sus respectivas etiquetas o códigos de inclusión, tendremos que recurrir a alternativas específicas de AMP. Por ejemplo, para <video> HTML5 tenemos <amp-video>:

<amp-video src="andaunvideo.mp4" width="400" height="300" poster="portada.jpg"></amp-video>

En general, estas etiquetas funcionarán como <alt-img>: Requieren especificar dimensiones exactas (width/height), y permiten la propiedad layout.

En cuanto a servicios de terceros con códigos de inclusión específicos -y evidentemente, incompatibles-, para algunos casos dispondremos de soluciones a medida mediante extensiones. Por ejemplo, para videos de Youtube:

<amp-youtube data-videoid="TJvvn1klmZ4" width="560" height="315" layout="responsive"></amp-youtube>
Además de youtube, hay extensiones compatibles para múltiples plataformas y partners
Además de youtube, hay extensiones compatibles para múltiples plataformas y partners

En general, tendremos que buscar la solución adecuada para cada caso concreto. En caso de duda, siempre tendremos la opción de sustituir el recurso incrustado por un enlace al mismo. Ej: Sustituir un documento/presentación inline por un botón de descarga, un mapa de localización por el enlace correspondiente a Google Maps…

8. Otros elementos

Respecto a formularios y otros elementos funcionales, dado que no serán directamente compatibles con AMP (y su reimplementación costosa, inviable o ni siquiera recomendable), tendremos que considerar eliminarlos o sustituirlos por llamadas a la acción simples, como enlaces y botones. Por ejemplo, podemos sustituir el formulario de comentarios de un blog por un enlace “Deja un comentario…” a la sección correspondiente del artículo original.

Más allá de eso, y si ya nos metemos en terreno de aplicaciones web completas, con funcionalidad compleja que no tenga sentido simplificar… lo dicho, probablemente AMP no encaje aquí de todas formas.

9. Layout y recomendaciones

Una vez generado el contenido, solo quedará preocuparse por la presentación del mismo y los elementos que normalmente lo acompañarían en la página: cabeceras, sidebars, menús, botones sociales… La idea será mantener un diseño sencillo, limpio, centrado en el contenido. Unas recomendaciones generales:

amp-sidebar
amp-sidebar en acción
  • Una cabecera simple (una franja de color con tu logo es lo habitual), que no ocupe excesivo espacio vertical.
  • Un pie de página más simple aún. Mínimo. Una franja con ©, minienlaces de interés, o incluso nada.
  • Además de responsive, diseño unificado. Piensa en móvil. No te molestes en crear un diseño alternativo más complejo para navegadores de escritorio y llenar todo de CSS y HTML superfluo. No es la idea.
  • Obviar sidebars, menús y elementos de navegación complejos. Si vas a incluirlos, que sean ocultos y no intrusivos. En la extensión amp-sidebar tienes una buena solución.
  • Si vas a poner botones/enlaces sociales para compartir, considera utilizar la extensión amp-social-share o, si vas a crear los tuyos propios, que sean enlaces-iconos simples (lo cual ya es recomendable de por sí, pero en este caso básicamente obligatorio…)
  • Considerar incluir siempre un enlace visible a tu página/contenido original en HTML, ya que los buscadores/proveedores de contenido no siempre van a preocuparse por facilitar la visibilidad o el acceso a la fuente original.

Publicación, validación y pruebas

Una vez creada nuestra página AMP, y subida a nuestro servidor web de forma que esté públicamente disponible bajo algún URL (idealmente, alguna variante sobre el de la página original; por ejemplo, puedes ver la versión AMP de esta misma página añadiendo /amp o ?amp=1 al final de la barra de direcciones), podremos ver como queda simplemente abriéndola en cualquier navegador actual, sea de escritorio o móvil.

Para que esta nueva página pueda ser indexada y utilizada por Google y otros servicios, además de visibilizarla debemos validarla y comprobar que cumple correctamente con los requisitos AMP HTML. Debe ser código AMP HTML válido al 100% o no se cacheará ni indexará…

Validación y debug

Podemos utilizar el validador que viene ya incluido en la librería AMP JS. Para activarlo, abrimos la página en el navegador (preferiblemente en Chrome), añadiendo #development=1 al final del URL:

https://aukera.es/blog/crear-paginas-amp/amp/#development=1

Abrimos la consola de depuración y desarrollo (F12) y, si todo ha ido bien, veremos un mensaje como este:

Consola validacion AMP

De lo contrario, se mostrará una relación detallada de los errores de validación. Utiliza la información de cada error junto con sus referencias en la documentación oficial para corregirlos uno a uno, y sigue intentándolo! ⚡

Además del validador interno, hay otras herramientas externas que pueden ayudarte, por ejemplo:

Que por cierto, debería echarle un ojo a esos 3 errores...
Que por cierto, debería echarle un ojo a esos 3 errores…

Todo esto para lo que al HTML se refiere; si hemos incluido metadatos Schema.org, estos deberán ser validados aparte. Para ello podemos utilizar, como de costumbre, la herramienta de pruebas de datos estructurados o Structured Data Testing Tool.

Publicación

Una vez confirmado que nuestra nueva página AMP está correcta, sólo nos quedará hacerla visible. Para ello, lo que haremos será enlazar mediante etiquetas <link> la página HTML original y su versión AMP, que buscadores y proveedores de contenido detectarán de forma automática.

Bastará con añadir el siguiente código en el <head> de la página original:

<link rel="amphtml" href="https://URL_COMPLETO_PAGINA_AMP" >

Y a su vez, en la página AMP:

<link rel="canonical" href="https://URL_COMPLETO_PAGINA_HTML" >

Etiquetas para enlazar las versiones HTML y AMP de una página

En el caso improbable de que ámbas páginas sean la misma (sólo existe una versión y es compatible AMP), entonces debemos añadir un canonical a sí misma de todas formas:

<link rel="canonical" href="https://URL_COMPLETO_PAGINA" >

¿¿Y la analítica qué??

Si te preocupa la analítica web, cosa bastante probable si eres asiduo de este blog, probablemente ya habrás tenido tu fase inicial de tirarte de los pelos. ¿¿Contenido servido externamente?? ¿¿Sin javascript ni iframes?? Peroperopero… ¡MIS PAGEVIEWS! ¡MIS CONVERSIONES! ¡ARGH! etc. Venga, vale, para. Bueno, te doy un minuto. ¿Ya? Ya.

Como era de esperar, lo que tengas ya montado no va a servir. Pero como también era de esperar, hay alternativas. Evidentemente, Google no iban a dejarse tirados a sí mismos…

Además de soluciones propias de AMP para scripts de terceros como <amp-analytics>, <amp-pixel> o <amp-ad>, Google Tag Manager ya soporta contenedores específicos para AMP, con sus propias plantillas de etiqueta para múltiples servicios. Veremos todo esto más a fondo en un artículo posterior. Prometido ;).

gtm-amp
Yo, we heard you like containers, so we put containers in your containers

Conclusiones

En este artículo hemos visto como crear a mano versiones AMP de páginas HTML estáticas. Sin embargo, lo habitual es que nuestro sitio web se componga de contenido dinámico almacenado en base de datos y servido por algún tipo de aplicación web: Scripts PHP o de otros lenguajes, CMS como WordPress o Drupal, plataformas de ecommerce, etc.

En estos casos, no crearemos HTML estático a mano para cada página, sino que nos hará falta una solución más general adaptada al caso de cada sitio web y su gestor de contenido.

En el próximo post veremos el caso práctico más común: implementar AMP en WordPress. ¡Permanezcan atentos a sus pantallas!

Enlaces de interés

Category:Tráfico y conversión

Tags: