Guide complet Google AMP : être compatible, convertir et éviter les pièges
Le projet Google AMP, Accelerated Mobile Pages, est un projet open source porté par Google ayant pour but de délivrer le contenu d’un site web de manière très rapide. Un contenu qui s’affiche comme l’éclair, simple à naviguer. Mais de quoi s’agit-il concrètement ? Il s’agit d’une construction spécifique en HTML de la page, intégrant la librairie JS AMP et plusieurs pratiques de développement, avec plusieurs éléments autorisés et d’autres non.
Concrètement, on écrit différemment son code HTML, avec des contraintes précises, dans le but d’offrir aux visiteurs un temps de chargement le plus faible possible, de préférence sur mobile – car cela a été réalisé dans ce but mais c’est également compatible desktop. C’est comparable à réaliser l’intégration d’un emailing : contraintes de compatibilité, écriture particulière du code, etc. Ainsi, le visiteur visite votre page AMP sur son mobile et voit apparaître le contenu très rapidement. Mais une telle rapidité de chargement nécessite une forte optimisation et donc des sacrifices lors du développement.
Voyons ainsi ce que Google AMP ne permet pas d’utiliser :
- Pas de librairies JS ni de JS custom
- Pas d’éléments de formulaire (zéro inputs, textarea, etc.)
- Pas de feuilles de style chargées en externe
- Une seule et unique balise style CSS dans la partie
<head /> - Pas de style CSS en ligne (inline style – par ex.
<div style="font-size:1em">) - La partie de style CSS ne doit pas dépasser 50kb
Et bien, ça limite sacrément ! Et c’est peut-être ce qui est le plus singulier : Google AMP prend au mot la directive « le contenu d’abord ! », quitte à sacrifier votre beau design et toute l’interactivité derrière.
AMP utilise ses propres composants, où par exemple <amp-img /> remplace <img />. La raison est simple : cela permet au navigateur d’avoir le choix de priorité de chargement sur l’élément selon la vue actuelle (si l’image est en fin d’article, il va retarder le chargement et l’inverse si l’image est visible sur la vue de l’utilisateur). AMP peut utiliser des versions extended que l’on peut appeler en JS pour avoir droit à certaines balises, comme les balises facebook ou twitter pour afficher des interactions spécifiques à ces plateformes. Voici une liste de ces tags actuellement :
amp-img (afficher une image)
amp-audio (faire un embed HTML5 audio)
amp-pixel (comme pour les emailings, permet d'avoir des statistiques visiteurs via un pixel appelé)
amp-video (faire un embed HTML5 vidéo)
amp-carousel (afficher un carousel d'images)
amp-lightbox (utiliser une lightbox pour afficher une image)
amp-ad (afficher une publicité depuis des services prédéfinis)
amp-anim (afficher un gif sous une placeholder)
amp-iframe (afficher une iframe)
amp-instagram (afficher un feed instagram)
amp-twitter (afficher un tweet)
amp-youtube (affiche une vidéo youtube)
amp-analytics (permet d'apposer un code propre aux statistiques, avec uniquement Google Analytics pour le moment)
Il s’agit d’une liste exhaustive, mais vous pouvez retrouver d’autres balises pour des besoins plus spécifiques sur la doc de Google Extended Components. Il existe également des balises expérimentales disponibles ici.
Toutes ces balises possèdent des pré-requis (par exemple, amp-img nécessite la largeur et hauteur, amp-iframe n’accepte que des sources sous HTTPS, etc.) que je vous invite à connaître sur la doc officielle de Google AMP.
La conception d’AMP peut se diviser en trois parties : AMP HTML, AMP JS et Google AMP Cache.
I. Comment être compatible AMP
AMP HTML concerne la partie HTML / CSS avec les balises spécifiques à AMP.
La seconde partie AMP JS implémente toutes les techniques de gestion des éléments et leurs délais de chargement respectifs, appelle le Google AMP Cache, réalise le rendu des balises amp, rends toute source d’iframe sandboxed (protégées), le pré-calcul des éléments de structure de la page et enfin la désactivation de propriétés CSS lentes. En bref, c’est là où la magie se fait.
Enfin, Google AMP Cache s’occupe de re-router toutes vos pages AMP vers les serveurs de Google, les mettre en cache pour améliorer les performances générales de chargement. Pas de choix de CDN, il faut accepter l’idée que toutes vos pages passeront par les serveurs Google (vendre son âme encore un peu plus, un peu moins… 
).
C’est bien beau tout ça, mais je voudrais une page AMP tout d’suiiiiite
Tout d’abord, il faut rester poli et dire s’il vous plaît. Ensuite, nous allons voir la base de la base : ce qu’il faut faire pour rendre votre page AMP-specific (source). Posez les stylos et prenez une feuille Notepad++ ou SublimText (ou autres). Nous allons reprendre le boilerplate d’une page AMP basique, présentée par Google :
<!doctype html>
<html amp lang="fr">
<head>
<meta charset="utf-8">
<title>Il faut AMParler</title>
<link rel="canonical" href="http://example.ampproject.org/article-metadata.html" />
<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": "Open-source framework for publishing content",
"datePublished": "2015-10-07T12:02:41Z",
"image": [
"logo.jpg"
]
}
</script>
<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>
<script async src="https://cdn.ampproject.org/v0.js"></script>
</head>
<body>
<h1>Merci d'allumer la l'AMP</h1>
</body>
</html>Voici donc un document basique, avec une balise canonical vers l’article de base non-AMP ainsi qu’une définition meta-data NewsArticle de Schema.org (optionnelle). Une page compatible AMP doit donc contenir :
- Une balise
<!doctype html> - Une balise html spécifique :
<htmlou⚡><html amp> - Une balise
<head />et<body /> - Une balise
<meta charset="utf-8" />(et pas d’autre choix de charset) - Une balise
<link rel="canonical href="#url" />qui renvoie vers la version non-AMP de la page, soit la page web standard avec tout votre design et vos librairies JS aussi lourdes qu’un éléphant adulte en Meurthe-et-Moselle (54) - Une balise
<meta name="viewport" content="width=device-width,minimum-scale=1">, sachant que l’attributinitial-scale=1est recommandé - Le script AMP JS via la balise
<script async src="https://cdn.ampproject.org/v0.js"></script>tout à la fin du<head /> - Contient cette balise
<style>dans le<head />:
<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>Et voilà, vous avez une page AMP !
Quelques headings, un contenu texte et votre page devrait s’afficher comme l’éclair, sur smartphone et desktop.
Pour éviter tout duplicate content, on prendra soin de lier les pages non-AMP et celles AMP. Les pages AMP doivent obligatoirement lier leurs pages non-AMP donc autant le faire sur la version non-AMP.
- Sur les pages non-AMP, rajouter la balise :
<link rel="amphtml" href="URL_de_la_page_AMP_sur_les_AMPoules">
- Sur les pages AMP, rajouter la balise :
<link rel="canonical" href="URL_de_la_page_Non-AMP">
Et quid du webdesign ? S’il-vous-plaît ?
On l’a vu, les contraintes imposées par les pages AMP pénalisent pas mal le côté webdesign de la page.
Cependant, les nombreux tags amp- mis à disposition permettent de remplir 80% des cas standards et n’oublions pas que nous avons droit jusqu’à 50kb de CSS 
.
Par exemple, vous pouvez trouver une bonne inspiration sur la page d’accueil de la présentation de Google AMP, qui est un bon exemple d’une page AMP optimisée avec un design abouti (une font custom, le CSS custom intégré avec le CSS obligatoire d’AMP, l’utilisation d’amp-analytics, il y a même une div sortante du footer en erreur 
) : https://www.ampproject.org
Vous comprenez donc que réaliser une page AMP passe par une intégration spécifique qui peut prendre du temps, Bootstrap et jQuery sont évidemment à oublier. Les preprocessors (Sass par exemple) sont autorisés. Comme AMP se concentre sur les performances, de nombreuses conditions affectent l’utilisation du CSS. Voici la liste de ce qui n’est pas autorisé avec AMP en terme de CSS :
- Le qualificatif
!important - La balise
<link rel="fichier.css">— à l’exception des polices personnalisées - Le sélecteur universel
* - La pseudo-classe
:not() - Les pseudo-sélecteurs, pseudo-classes et pseudo-éléments qui ne ciblent pas directement les tags, sans
amp-(exemple BIEN :a:hover/ exemple PAS BIEN :amp-img#id:hover) - Les sélecteurs et classes -amp- & i-amp internes à AMP
- Les propriétés behavior, -moz-binding et filter
La balise <link> utilise son exception d’utilisation dans le cas de custom fonts, qui s’écrit alors comme une balise <link> classique :
<link rel="stylesheet" href="https://fonts.googleapis.com/css?family=RAMPeD'Escalier">
Enfin, les propriétés transition et animation (et donc les @keyframes) peuvent être utilisées uniquement avec opacity et transform (il faut aussi inclure -vendorPrefix-transform, c’est-à-dire -moz-transform, -webkit-transform, -o-transform, etc.).
Voici un retour d’expérience intéressant sur quelques problèmes propres à Google AMP, utiles à savoir :
- Pas de formulaires : vous ne pouvez pas utiliser AMP pour des applications web complexes. Cela signifie donc que vous ne pouvez pas réaliser de formulaires d’inscription de newsletter, de gestion de commentaires ou même un champ de recherche. Cependant, l’utilisation de
amp-iframepourrait permettre ce dernier cas, avec probablement des désagréments dues au sandboxing réalisé par Google AMP. La piste du traitement PHP est aussi envisageable. - Un menu Hamburger [stag_icon icon= »bars » url= » » size= »1em » new_window= »no »] compliqué : en raison des restrictions propres à AMP, la réalisation d’un menu [stag_icon icon= »bars » url= » » size= »1em » new_window= »no »] de type Hamburger peut être compliqué (ce qui est ironique vu que ce type de menu est idéal sur mobiles). L’utilisateur jpettit a posté un exemple de solution sur le Github AMP et une feature request pour une balise
amp-sidebarest ouverte. - Des statistiques différentes : la balise
amp-analyticspermet de faire appel à Google Analytics pour vos statistiques. L’utilisation d’event est autorisée, vous n’aurez cependant pas de retour sur les adresses IP de vos visiteurs (et donc leur localisation, provenance, referrals, etc.) car la synthèse de vos analytics est réalisée via AMP JS. - Des images contrôlées : l’interaction AMP avec
amp-imgvous forcera à préciser la largeur et la hauteur de l’image que vous souhaitez afficher. Ajoutez l’attributlayout=responsivepour qu’AMP calcule automatiquement l’étirement maximal de l’image. Prévoyez d’y mettre une div qui cadrera la largeur maximale car AMP appliquera automatiquementwidth="100%"sur l’image avec l’attributresponsive. - Pas de JS, pas de chocolat : Comme toutes les balises
ampsont transformées par Javascript, les visiteurs qui visiteront vos pages AMP avec Javascript désactivé ne pourront pas accéder à toute transformation de contenu (comme par exemple les images, vidéos, lightbox, iframe, etc.). Cependant, vous pouvez utiliser la balise<noscript>pour vos fallbacks en cas de javascript désactivé, ce qui revient cependant à dupliquer le contenu. Enfin, les pages AMP ne peuvent être validées via le W3C ou tout autre validateur HTML.
Contrôle et Validation des pages AMP
Validez votre AMP-CSS ainsi que le contenu AMP-HTML en utilisant l’AMP Validator. Pour l’exécuter, il faut ouvrir sa page AMP dans votre navigateur préféré (Firefox, Chrome, Internet Explorer, Opera, Netscape, Avant Browser, etc.) puis rajouter #development=1 à la fin de l’URL. Ouvrez la console JS (via « Inspecter l’élément », Firebug, la Console Chrome, etc.) et vous aurez ainsi les erreurs et avertissements relatifs à votre page AMP.
Vous pouvez trouver les significations des codes erreurs affichés sur le Guide AMP Validation Errors.
II. A-t-on vraiment besoin de Google AMP ?
On vient de voir comment réaliser une page compatible AMP, passons de la pratique à l’analyse. Est-ce que l’effort de rendre compatible son site AMP vaut-il le coup ? S’agit-il d’une réelle avancée dans le développement pour le web mobile ou seulement une concurrence à Facebook Instant Articles ou Apple News, par exemple ?
Qu’est-ce que le Top Stories sur Google ?
Le Top Stories de Google est une nouvelle méthode d’affichage des actualités sur les mobiles pour les éditeurs de Google News (ou Google Actualités), disponible sur les versions anglaises de Google à l’heure où ces lignes sont écrites. Cela permet d’afficher sur mobile les actualités rédigées sous page AMP tout en restant sur Google (via un système de frame). C’est sûr, ça améliore votre visibilité et votre contenu devient plus accessible. Mais comme Facebook Instant Articles ou Apple News, votre contenu ne sort pas de Google dans un premier temps. Cela peut représenter un point d’accès supplémentaire à votre site, vous pouvez toujours monétiser avec de la publicité native et vous gardez l’autorité sur le contenu. Mais le visiteur visitera et accèdera à votre contenu sous Google et non sur votre site. C’est en cours de déploiement donc son affichage n’est pas encore garanti mais vous pouvez tenter de voir le Top Stories anglais via google.co.uk sur mobile.
Comment monétiser et convertir quand Google garde le contrôle ?
On l’a vu, les pages AMP interdisent tout Javascript personnalisé. Adieu les interstitiels, le lien externe omniprésent sur le body, les bannières privant 50% de hauteur de contenu visible dès le chargement, etc.
Le système de la publicité mobile en ligne ne doit pas ruiner le plaisir de navigation, ni être l’un des premiers responsables de hausse du Taux de Rebond (ce qui est un comble !), il ne fallait pas s’étonner du fulgurant succès des Adblockers lorsqu’ils sont arrivés sur les smartphones. Les pages AMP imposent des restrictions propres aux publicités, obligeant ainsi à réfléchir à de nouveaux moyens de communiquer.
Actuellement, on retiendra plusieurs moyens de continuer à monétiser son contenu sur des pages AMP :
- Publicité native : il s’agira d’utiliser une balise image ou vidéo pour présenter directement la publicité sur votre page. Pas d’appel aux plateformes d’enchères, pas d’appel à la régie, pas de programmatique, la publicité sera décidée en amont et affichée manuellement.
- L’iframe : heureusement, AMP permet l’utilisation d’iframe via la balise
amp-iframe. Comme ces iframes sont sandboxed, il ne faudra pas compter sur une exécution de Javascript sur la page encapsulée. Il faut donc prévoir toute exécution de script en amont, la page encapsulée servira seulement à afficher la sortie de ces scripts. - L’article sponsorisé : évidemment, vous pourrez toujours proposer des articles sponsorisés, ces derniers concernant le contenu et non l’affichage.
Pour convertir vos visiteurs avec par exemple l’inscription à une newsletter, l’utilisation de formulaire étant interdite, il faudra proposer ces formulaires sur des pages externes non-AMP mais toutes aussi légères.
A noter que Google planche actuellement avec différents partenaires pour élaborer de nouvelles formes de publicité, implantées dans Google AMP et inspirées du Manifest d’Acceptable Ads.
III. Conclusion
On vient de voir qu’une page Google AMP agit sur plusieurs choses pour votre site web.
Commençons par les points positifs :
- Afficher un contenu responsive très rapidement, sur n’importe quel écran (desktop, tablette, mobile)
- Afficher sa page dans la partie Top Stories sur Google, une situation idéale en terme de CTR
- Être probablement et légèrement favorisé dans le ranking Google Mobile, par supposition hypothétique probable d’un algorithme partial favorisant les propres produits Google. Peut-être.
Le projet Google AMP est un projet aux idéaux qui sont à la fois positifs et négatifs : cela favorise un Web mobile axé sur le contenu, où le développement, lui, est axé sur la performance. Cependant, cette vision s’accorde sur un Web restreint aux balises imposées, au détriment de l’innovation graphique, interactive et ergonomique, avec des restrictions qui rappellent la réalisation d’un emailing pour d’anciens clients de messagerie. C’est ainsi que nous pouvons lister certains points négatifs :
- Une restriction rimant avec frustration dans l’ensemble du procédé de développement d’une page AMP
- Moins de place à l’originalité, sauf éditoriale
- Un CDN obligatoire chez Google
- Votre contenu chez Google dans son Top Stories
- Retour au web fin 90 : pas de Javascript personnalisé, pas de CSS évolué, pas de formulaire, etc.
Le projet AMP vise à promouvoir un web accessible rapidement, de préférence sur mobile. Mais si vous avez déjà optimisé votre site responsive sur les performances (voir notre fabuleux article sur le Guide d’optimisation du référencement mobile 
), ce n’est peut-être pas si rentable de passer sur Google AMP, selon votre cas. Et justement, dans quel(s) cas cela pourrait valoir le coup ?
Pourquoi utiliser Google AMP et dans quels cas ?
Si Google AMP est équivalent à un site responsive optimisé incluant les Rich Snippets, on repère cependant deux avantages à réaliser une version AMP :
- Apparaître dans le Top Stories Google
- Offrir une version optimale pour les pages à grand contenu éditorial
En effet, vous serez plus sensible à prévoir une version AMP si les pages concernées sont principalement liée au contenu éditorial : blogs, presse, actualités, journaux, documentation, encyclopédie, information, thèse, etc. Car l’optimisation d’une page AMP est l’idéal pour ce type de contenu. De plus, si vous êtes éligibles et éditeurs sur Google Actualités, vos articles pourront s’afficher sur le nouveau carrousel d’actualités Top Stories. L’effort offre un bénéfice intéressant.
Cependant, si votre site ne concerne pas la mise en valeur du contenu éditorial uniquement (toutes les catégories de sites ne rentrant pas dans le type des précédentes catégories citées), vous avez le choix entre :
- Avoir un site responsive pour desktop, mobiles et tablettes et une version AMP pour les résultats de recherche Google mobile (le visiteur pourrait être perdu par la schizophrénie de contenu du site) ;
- Avoir un site pour desktop et une version AMP pour les mobiles ;
- Avoir un site responsive pour desktop, mobiles et tablettes
En effet, soit vous proposez votre site intégral pour les vues desktop et une version AMP au design et aux possibilités d’interaction et d’ergonomie incompatibles (ce qui est similaire à avoir un site desktop et un site mobile distinct) ; soit vous proposez le même site et le même design pour toutes vos vues. Du moment que ce dernier est correctement optimisé sur la performance et adopte les Rich Snippets quand cela est possible, ce n’est pas grave de ne pas utiliser Google AMP. Cela évite la multiplicité d’accès du contenu, le visiteur peut se trouver perdu en accédant à une version différente du site via les résultats de recherche Google mobile et une autre version en accédant directement au site.
Si vous êtes sous WordPress, il existe un plugin nommé AMP réalisé par Automattic, propriétaire de WordPress. Il permet de générer automatiquement et dynamiquement une version AMP de votre blog / journal / etc. Pour le moment compatible uniquement aux articles et pas encore aux pages et archives, cela permettra dans un premier temps de déployer rapidement Google AMP sur votre site.
Et à l’avenir ?
Le big deal à long terme sera de voir comment Google traite son algorithme avec les pages AMP, s’il favorisera uniquement la technologie AMP ou s’il restera impartial en favorisant les sites rapides à charger. Le projet AMP souhaite résoudre des problèmes de performances sur les sites actuels qui trouvent leurs sources via des interaction et scripts externes ou third-party qui alourdissent la page : publicité lourde, trackers innombrables, etc. Surtout que les attentes des consommateurs sur mobile sont différentes des visiteurs desktop : sur mobile la data est limitée, la vitesse de transfert peut ne pas être au top (en ville comme en cAMPagne), ils n’apprécient pas d’être bloqués dans leur recherche de contenu par de la publicité obstructive, des messages bloquants leur demandant de télécharger une appli, une bandeau couvrant 30% du contenu leur demandant de télécharger la même appli, etc.
Il y a une notable incompréhension entre les annonceurs et les attentes des visiteurs mobiles depuis plusieurs années. Et Google AMP souhaite enrayer ce fléau du site lent. Mais un site optimisé le fera tout autant qu’un site restreint sous AMP.
Cependant, si vous vous intéressez à Google AMP en détails, c’est que vous faites déjà attention aux performances de votre site. Et qu’il est probablement déjà suffisamment optimisé. Les sites qui offrent une exécrable expérience de navigation sur mobile sont lents car apparemment ils ne s’intéressent justement pas à ces questions de performance.
Comme Google favorisera au fur et à mesure du temps la rapidité des sites, notamment sur mobile (et en espérant qu’il ne perde pas sa partialité en favorisant AMP), vous pouvez commencer à conseiller vos clients et éditeurs sur la question de la performance en lien avec leur référencement et ranking.
Et vous, que pensez-vous de Google AMP ? De son utilité, sa pertinence et son contexte de cible ?
Sources : HFR, Tunetheweb, Arobasenet, 10up, AMPProject, AMPProject Github, Pagefrog.
Mise à jour novembre 2019 : Aujourd’hui, Google fait apparaître votre site dans une version mise en cache sur leurs serveurs, lorsque vous apparaissez dans les Top Stories ou dans le Search. Bien que Google a annoncé que ce fait changerait dans le futur, je vous déconseille l’utilisation de la technologie AMP.
.
. Il est donc primordial d’avoir son site optimisé pour le référencement mobile (tablettes et smartphones) sur ces deux plate-formes au moins. Vous pouvez consulter notre article qui s’attelle à la question en détail : 
). Lorsque vous souhaitez améliorer vos chances d’apparaître sur un thème précis, n’hésitez pas à communiquer sur ces réseaux sociaux pour apparaître via votre pertinence.
.
et c’est parti pour l’importation ! 
de votre site web : améliorer sa visibilité , faire baisser son taux de rebond et enfin faire plaisir à de nouvelles bouches :
où :
) puis s’en va tout heureux… et bien il sera compté comme un bounce. Alors que le but original du Taux de Rebond, c’est de détecter un problème de pertinence de contenu ou d’accès au site.
Wah, ça bounce !
