Tout ce que vous devez savoir sur les pages mobiles accélérées de Google

En mai 2015, Facebook a dévoilé sa nouvelle plateforme de publication intégrée, Instant Articles. Un mois plus tard, Apple a déclaré que l'ancienne expérience Kiosque (essentiellement un dossier sophistiqué rempli d'applications d'actualités) serait remplacée dans iOS 9 par une toute nouvelle plate-forme d'agrégation et de découverte d'actualités appelée Apple News.

Pour en savoir plus sur Smashing :

• Performances perçues
• Précharge : à quoi ça sert ?
• Se préparer pour HTTP/2
• Amélioration progressive
• Web AMP progressifs

Quatre mois plus tard, c'était au tour de Google d'annoncer son propre plan, un peu tardif mais non moins ambitieux, pour révolutionner la consommation d'actualités mobiles avec une solution web open source appelée Accelerated Mobile Pages, ou AMP. En quelques mois seulement, nous avons vu la relative tranquillité de l'édition numérique mobile éclater en une nouvelle guerre de plates-formes à grande échelle alors que Facebook, Apple et maintenant Google se disputent à la fois la loyauté des éditeurs et l'attention des lecteurs.

Alors que Facebook et Apple ont une longueur d'avance significative sur Google, il y a tout lieu de croire qu'AMP va rapidement rattraper son retard (et pourrait même dépasser l'un ou les deux de ses concurrents). Si vous êtes un développeur ou un éditeur qui a besoin de se familiariser avec le pourquoi, le quoi et le comment des pages mobiles accélérées de Google aussi rapidement et efficacement que possible, vous êtes au bon endroit.

Mais quel est le problème ?

Avant de discuter des solutions, il vaut la peine de prendre un moment pour explorer le problème. Si vous lisez beaucoup sur des appareils mobiles, il y a de fortes chances que vous sachiez déjà que l'interaction avec du contenu Web sur un téléphone ou une tablette va d'à peine acceptable à horrible. Les pages se chargent souvent lentement, s'affichent de manière erratique et se comportent de manière imprévisible pour deux raisons principales :

• intervention de tiers . Les publicités et les techniques de suivi associées ajoutent non seulement des requêtes en masse et supplémentaires à un appareil déjà limité en bande passante et en CPU, mais les pages se comportent souvent comme si elles étaient possédées lorsqu'elles convulsent autour de plusieurs appels document.write() . Le New York Times a récemment effectué un test qui a montré une diminution significative de la taille des pages et une augmentation de la durée de vie de la batterie après l'installation d'un bloqueur de contenu iOS.
• dommages collatéraux du design réactif . Bien que la plupart des sites Web conçus de manière réactive s'affichent bien sur des écrans de toutes tailles, ils contiennent souvent une grande partie du bagage des sites Web de bureau lorsqu'ils sont consultés sur mobile. Lorsque Paul Irish a effectué un audit des performances de Reddit, il a découvert qu'une grande partie de la surcharge pouvait être attribuée à un actif appelé SnooIcon, la mascotte Reddit rendue en SVG afin qu'elle puisse être animée (par une bibliothèque tierce, ce qui signifie plus de frais généraux) au survol de la souris - pas une situation dans laquelle les actifs se retrouvent fréquemment sur des appareils mobiles.

Entrez Facebook Instant Articles, Apple News et Accelerated Mobile Pages - nos sauveurs d'un monde où, selon Facebook (PDF, 3,4 Mo), le temps de chargement moyen d'un article sur les appareils mobiles est de 8 secondes. Bien qu'appeler 8 secondes une éternité soit évidemment une hyperbole, étant donné que vous pourriez être bien dans votre deuxième vidéo Vine dans ce laps de temps, il est probablement juste de dire que, selon les normes d'aujourd'hui, c'est au moins un éon.

Une courte démo de Facebook Instant Articles, Apple News et Accelerated Mobile Pages. Notez que Facebook Instant Articles et Apple News sont des expériences intégrées à l'application, tandis que AMP est entièrement basé sur un navigateur.

En quoi AMP est-il différent ?

Un certain contexte sur la différence entre AMP et Facebook Instant Articles et Apple News clarifiera certaines des décisions prises par Google pour sa nouvelle initiative de publication numérique.

Facebook Instant Articles et Apple News ont plusieurs caractéristiques en commun :

• expériences intégrées à l'application . Les lecteurs accèdent aux articles instantanés de Facebook via Facebook sur les appareils mobiles, et Apple News est une application autonome fournie avec iOS 9. Aucune des plates-formes ne permet actuellement aux utilisateurs de visualiser les articles dans leurs formats spécifiques en dehors de l'application respective. Considérez les deux comme une actualisation spécifique à l'application de RSS.
• axée sur la syndication . Alors que Facebook Instant Articles et Apple News utilisent des formats de syndication très différents (Apple News Format est basé sur JSON, et Instant Article Markup est plus ou moins HTML enveloppé dans un flux RSS), ils sont basés sur des principes similaires : Amener votre CMS à générer le formats de syndication nécessaires, et Facebook ou Apple News l'aspireront, l'analyseront et le rendront à la fois beau et rapide grâce à des moteurs de rendu personnalisés et optimisés.
• axé sur l'expérience . Bien que Facebook Instant Articles et Apple News soient tous deux axés sur les performances, ils sont également soucieux de donner aux articles une apparence et une sensation modernes. Les deux plates-formes ont des composants qui permettent les interactions fluides et fluides que nous associons généralement aux expériences de lecture sur mesure et faites à la main.

En revanche, les pages mobiles accélérées ont un objectif distinct :

• expérience basée sur le Web . Les documents AMP sont conçus pour être rendus soit dans le navigateur, soit dans WebViews.
• documents atomiques . Bien que les documents AMP soient validés, analysés et partiellement rendus par le runtime AMP (beaucoup plus à ce sujet ci-dessous), ce sont des documents complets et indépendants qui résident sur votre propre serveur Web (et, éventuellement, dans un cache CDN), plutôt que des collections de métadonnées qui seront à un moment donné transformées en articles et rendues dans des applications.
• axé sur la performance . AMP se soucie beaucoup plus des performances des documents AMP que de l'esthétique ou des modèles d'interaction. Cela ne veut pas dire que les documents AMP sont intrinsèquement simples (ils peuvent être tout aussi attrayants que les articles instantanés de Facebook ou les articles d'Apple News avec le bon style), mais le temps d'exécution est beaucoup plus soucieux de rendre un article rendu rapidement que de fournir des effets visuels fantaisistes comme petites choses folles.

Qu'est-ce que l'AMP exactement ?

Assez de philosopher et d'agiter la main de haut niveau. Entrons dans les détails. Bien qu'il soit assez facile de se familiariser avec Facebook Instant Articles et Apple News (il s'agit essentiellement d'agrégateurs de nouvelles sophistiqués avec des moteurs de rendu personnalisés construits sur des formats de syndication propriétaires), AMP est la valeur aberrante. C'est un peu plus difficile à saisir, pour deux raisons :

• Il n'existe pas de modèle simple auquel le comparer. Lorsque RSS était nouveau, nous nous sommes tous émerveillés de sa puissance, avons écrit d'innombrables articles et articles de blog sur son potentiel perturbateur, déclaré la page d'accueil morte (encore une fois), puis nous avons tout oublié. Facebook Instant Articles et Apple News sont essentiellement un redémarrage RSS, sauf qu'ils dispensent de tous les inconvénients des normes, et que chacun fonctionne dans une seule application.
• AMP n'est pas un client. . Alors que Facebook Instant Articles, Apple News et AMP ont plusieurs éléments en commun, tels que des formats de syndication propriétaires et des moteurs de rendu personnalisés, AMP est le seul à ne pas avoir de client dédié (autre que le navigateur). Plus que ses frères, AMP est un ensemble de spécifications, de conventions et de technologies qui peuvent être combinées dans une solution, plutôt que d'être une solution de bout en bout (éditeur à lecteur) en soi.

Maintenant que nous savons considérer l'AMP comme une collection d'ingrédients plutôt que comme un gâteau entièrement cuit, examinons quels sont ces composants individuels :

• AMP HTML,
• l'environnement d'exécution AMP,
• le cache AMP.

AMP HTML

Les documents AMP sont écrits en HTML, mais pas n'importe quel HTML. Certaines balises sont interdites, tandis que quelques nouvelles balises sont introduites (en partie pour remplacer celles qui sont interdites et en partie pour encapsuler des fonctionnalités interactives). Vous pouvez penser à AMP HTML comme à quoi ressemblerait le HTML s'il avait été conçu en pensant uniquement aux performances mobiles (au lieu d'avoir été introduit 14 ans avant l'introduction de l'iPhone).

Parce que AMP HTML est conçu pour des performances optimales, pour comprendre et apprécier sa valeur, nous devons comprendre les problèmes qu'il résout. Voici les trois principales choses qui nuisent au chargement et à l'affichage des pages Web sur les appareils mobiles :

• taille de la charge utile . La conception Web réactive nous a bien servi car elle nous permet de créer un site Web unique pour chaque appareil et écran. Mais cela signifie aussi parfois fournir des charges utiles de la taille d'un ordinateur de bureau (HTML, JavaScript, CSS et actifs) à des appareils mobiles extrêmement limités en bande passante et en CPU. (Ceux qui considèrent leurs téléphones comme de petits ordinateurs de bureau accordent beaucoup trop de crédit au matériel mobile. Votre iPhone 6s dispose de 2 Go de RAM, tandis que votre ordinateur portable en a probablement 8 ou 16.)
• chargement des ressources . Les ressources ne sont pas toujours chargées dans l'ordre optimal, ce qui signifie que la bande passante, le processeur et la RAM sont souvent dédiés à des actifs que les utilisateurs ne verront peut-être même jamais. De plus, les ressources ne déclarent souvent pas leurs largeurs et leurs hauteurs (en particulier lorsqu'elles sont diffusées via des réseaux publicitaires ou injectées via des appels document.write() ), ce qui non seulement entraîne le redimensionnement de la page lorsque les dimensions des ressources sont déterminées paresseusement, mais déclenche également des événements inutiles. et des recalculs de mise en page coûteux. C'est ce qui fait bondir les pages Web comme des chatons chassant au laser alors qu'ils se manifestent toujours aussi lentement.
• Exécution JavaScript . Je ne suis pas sur le point d'aborder le sujet des performances de JavaScript ici, mais les sites Web modernes l'empilent souvent par mégaoctet, et bien qu'il puisse s'exécuter sans aucune latence perceptible sur les ordinateurs de bureau, le mobile est toujours un environnement très différent, où, je pense nous sommes tous d'accord, il vaut mieux garder JavaScript au minimum.

Compte tenu de ces trois obstacles aux expériences Web fluides sur les appareils mobiles, AMP HTML existe principalement pour trois raisons :

• encourager la brièveté . Les documents AMP ne sont pas des versions réactives des sites Web de bureau. Alors que les documents AMP peuvent être (et sont généralement) réactifs, ils sont réactifs dans un contexte mobile. En d'autres termes, plutôt qu'une page fonctionnant absolument partout (ordinateur de bureau et mobile), les documents AMP sont conçus spécifiquement pour bien fonctionner sur tous les appareils mobiles.
• contrôler le chargement des ressources externes . Le runtime AMP contrôle le chargement des ressources externes pour s'assurer que le processus est très efficace, ce qui permet d'afficher le contenu sur les écrans des utilisateurs aussi rapidement et intelligemment que possible.
• encapsuler des fonctionnalités interactives . Bien que les documents AMP aient tendance à présenter aux lecteurs des expériences de lecture simples, cela ne signifie pas qu'ils ne peuvent pas être modernes et interactifs. Le runtime AMP fournit des fonctionnalités encapsulées via JavaScript hautement optimisé, de sorte que les développeurs ne risquent pas d'entraver les performances en écrivant les leurs.

Balises HTML AMP

Vous trouverez ci-dessous une liste de balises qui sont carrément interdites dans AMP HTML :

• script C'est évidemment un gros problème. Je fournirai plus de détails sur la position d'AMP sur JavaScript ci-dessous ; pour l'instant, supposons simplement que les seules balises de script que vous aurez dans vos documents AMP sont celles qui chargent le runtime AMP et, éventuellement, une balise pour les données liées basées sur JSON.
• base La balise base semble être interdite par prudence, et elle pourrait se retrouver sur la liste blanche si la communauté se plaint. (Je suppose que personne ne s'en soucie vraiment d'une manière ou d'une autre.)
• frame and frameset Ce n'est pas exactement une bonne utilisation de l'immobilier mobile de toute façon, alors bon débarras.
• object , param , applet et embed Malheureusement, vos documents AMP ne contiendront aucune applet Flash ou Java. (C'était du sarcasme, au cas où ce ne serait pas tout à fait évident.)
• éléments form et input (à l'exception de la balise button ) La prise en charge des formulaires sera probablement éventuellement implémentée en tant que composants encapsulés car ils sont d'une utilisation limitée sans script.

Voici maintenant une liste de balises qui remplacent leurs homologues HTML afin d'optimiser le chargement des ressources et d'appliquer les meilleures pratiques de sécurité :

• [amp-img](https://www.ampproject.org/docs/reference/amp-img.html) Remplace la balise img et optimise le chargement des ressources en tenant compte de facteurs tels que la position de la fenêtre d'affichage, les ressources système et la connectivité.
• [amp-video](https://www.ampproject.org/docs/reference/amp-video.html) Remplace la balise video HTML5, afin que le contenu vidéo puisse être chargé paresseusement (en tenant compte de la fenêtre d'affichage).
• [amp-audio](https://www.ampproject.org/docs/reference/extended/amp-audio.html) Remplace la balise audio HTML5 afin que le contenu audio puisse être chargé paresseusement (en tenant compte de la fenêtre d'affichage).
• [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) La balise amp-iframe applique les meilleures pratiques de sécurité en procédant par exemple au sandboxing du contenu par défaut et en imposant des restrictions sur où les iframes peuvent apparaître pour s'assurer qu'ils ne dominent pas un document AMP.

Enfin, voici toutes les balises introduites par AMP HTML pour ajouter des fonctionnalités ou de l'interactivité à vos documents, sans vous obliger à écrire du JavaScript :

• [amp-ad](https://www.ampproject.org/docs/reference/amp-ad.html) La balise amp-ad permet à l'environnement d'exécution AMP de gérer le chargement des annonces comme toutes les autres ressources chargées en externe (actuellement , les publicités sont chargées en dernier), et cela garantit que le JavaScript des réseaux publicitaires ne peut pas s'exécuter dans le document AMP parent ou déclencher des calculs de mise en page inutiles. (Au revoir, document.write() !)
• [amp-analytics](https://www.ampproject.org/docs/reference/extended/amp-analytics.html) Ce cadre miniature regroupe les données d'analyse et les envoie à des fournisseurs tiers. À ce jour, le support AMP provient d'Adobe Analytics, Chartbeat, ClickTale, comScore, Google Analytics, Nielsen et Parse.ly.
• [amp-pixel](https://www.ampproject.org/docs/reference/amp-pixel.html) Ceci est utilisé pour intégrer des balises Web et prend en charge les jetons pour envoyer plusieurs variables client au serveur.
• [amp-carousel](https://www.ampproject.org/docs/reference/extended/amp-carousel.html) Ce composant optimisé affiche les images enfants dans une orientation horizontale interactive.
• [amp-lightbox](https://www.ampproject.org/docs/reference/extended/amp-lightbox.html) Cela permet aux lecteurs d'ouvrir des images dans une vue "lightbox" plein écran. Il prend en charge la spécification des vignettes et des images en taille réelle.
• [amp-anim](https://www.ampproject.org/docs/reference/extended/amp-anim.html) Cela charge les GIF animés et fournit une fonctionnalité d'espace réservé indispensable.
• [amp-font](https://www.ampproject.org/docs/reference/extended/amp-font.html) Définissez un délai de chargement sur les polices personnalisées et spécifiez des polices de secours si vos polices personnalisées ne se chargent pas dans le délai imparti .
• [amp-fit-text](https://www.ampproject.org/docs/reference/extended/amp-fit-text.html) Le texte d'une balise amp-fit-text se verra automatiquement attribuer une taille de police optimisée pour l'espace disponible. Considérez cela comme une petite réactivité préemballée.
• [amp-list](https://www.ampproject.org/docs/reference/extended/amp-list.html) Avec la balise amp-list , vous pouvez charger des données JSON dynamiques et répétitives, puis les restituer à l'aide d'un code HTML. modèle. (Voir la balise amp-mustache ci-dessous.)
• [amp-mustache](https://www.ampproject.org/docs/reference/extended/amp-mustache.html) Cela prend en charge le rendu des modèles HTML Moustache.
• [amp-install-serviceworker](https://www.ampproject.org/docs/reference/extended/amp-install-serviceworker.html) Si vous choisissez de ne pas utiliser de cache AMP (plus d'informations sur la mise en cache ci-dessous), le La balise amp-install-serviceworker charge et installe un service worker pour la page en cours. Les travailleurs des services sont habiles, mais à mon avis, il est un peu trop tôt pour compter sur eux.
• [amp-youtube](https://www.ampproject.org/docs/reference/extended/amp-youtube.html) Comme on pouvait s'y attendre, cela intègre la vidéo YouTube avec l'ID vidéo spécifié.
• [amp-twitter](https://www.ampproject.org/docs/reference/extended/amp-twitter.html) Intégrez des tweets (cartes Twitter facultatives).
• [amp-instagram](https://www.ampproject.org/docs/reference/extended/amp-instagram.html) Intégrez des images Instagram.
• [amp-brightcove](https://www.ampproject.org/docs/reference/extended/amp-brightcove.html) Ce composant charge et affiche les vidéos (et un lecteur vidéo) de Brightcove.
• [amp-pinterest](https://www.ampproject.org/docs/reference/extended/amp-pinterest.html) Intégrez un widget Pinterest ou un bouton "Pin It" dans votre document AMP.
• [amp-vine](https://www.ampproject.org/docs/reference/extended/amp-vine.html) Intégrez la vidéo Vine spécifiée dans votre document AMP.

Notez que, même si amp- préfixées par amp ne sont pas exactement du HTML standard, elles ne sont pas non plus propriétaires. Ce sont plutôt des éléments personnalisés légitimes avec des implémentations JavaScript qui font des choses comme appliquer les meilleures pratiques de sécurité et donner la priorité au chargement des ressources distantes (plus à ce sujet dans la section "AMP Runtime" ci-dessous). En d'autres termes, bien que AMP HTML puisse ressembler de manière suspecte à la stratégie d'embrasser, d'étendre et d'éteindre, il ne s'agit en réalité que d'une application intelligente des normes Web et pas si différente des attributs de data- personnalisés.

Style AMP HTML

Le style des documents AMP est effectué avec le CSS standard et n'est pas très différent de la façon dont vous stylisez déjà le contenu. Cependant, gardez à l'esprit plusieurs choses :

• Tout le style doit être fait avec une feuille de style en ligne - pas de feuilles de style liées en externe et pas de styles en ligne au niveau de l'élément. (Une feuille de style liée en externe nécessiterait le téléchargement d'un document supplémentaire avant que la mise en page puisse être calculée, et les styles au niveau des éléments en ligne pourraient gonfler le document.)
• Les styles sont limités à 50 Ko. La philosophie de Google est que 50 Ko suffisent pour un beau document ou article mais pas assez pour un beau site web.
• Votre feuille de style en ligne doit avoir l'attribut amp-custom (c'est-à-dire <style amp-custom> ).
• Les règles @ — @font-face (plus d'informations sur les polices ci-dessous), @keyframes et @media — sont autorisées.
• Certains sélecteurs ont des limitations connues pour affecter les performances, comme le sélecteur universel ( * ) et le sélecteur :not() .
• Le qualificatif !important est interdit pour garantir que le runtime AMP a le dernier mot sur le dimensionnement des éléments.
• Le style des composants AMP personnalisés comme amp-carousel est effectué en remplaçant les classes par défaut, comme .amp-carousel-button-prev , ou en utilisant un ensemble prédéfini de propriétés personnalisées CSS, comme --arrow-color .
• Toutes les ressources chargées en externe doivent avoir des propriétés de largeur, de hauteur et de mise en page spécifiées (plus d'informations sur la mise en page ci-dessous) pour minimiser les recalculs coûteux de mise en page DOM.
• Les transitions et les animations qui peuvent être accélérées par le GPU (et qui ne déclenchent pas de recalculs) sont autorisées. Actuellement, opacity et la transform sont sur liste blanche.

Pour plus de détails sur le style des documents, consultez la spécification AMP HTML.

Polices

AMP prend volontiers en charge les polices personnalisées, avec quelques réserves :

• Les polices doivent être chargées avec une balise de lien ou une règle CSS @font-face . En d'autres termes, vous ne pouvez pas charger de polices à l'aide de JavaScript.
• Toutes les polices doivent être diffusées via HTTPS.
• Les fournisseurs de polices doivent figurer sur la liste blanche. Actuellement, les seuls fournisseurs sur liste blanche sont fonts.googleapis.com et fast.fonts.net . Mais, étant donné la rapidité avec laquelle les éditeurs, les annonceurs et les fournisseurs d'analyses ajoutent la prise en charge d'AMP, je soupçonne que d'autres suivront bientôt.

Mise en page

L'approche d'AMP en matière de mise en page a été conçue autour de deux objectifs principaux :

• L'environnement d'exécution doit pouvoir déduire la taille de toutes les ressources chargées en externe avant qu'elles ne soient réellement chargées, afin qu'une mise en page finale puisse être calculée aussi rapidement que possible. Une fois la mise en page calculée, l'article peut être rendu et les lecteurs peuvent commencer à interagir avec lui, même si les annonces, les images, l'audio et la vidéo n'ont pas encore terminé le chargement. (Et, au fur et à mesure du chargement de ces ressources, elles s'afficheront de manière transparente, sans perturber l'expérience de lecture en mettant à jour la mise en page du document.)
• Les articles AMP doivent être réactifs. Comme le nom « Accelerated Mobile Pages » l'indique, les documents AMP sont spécifiquement destinés aux appareils mobiles ; donc, dans ce contexte, "réactif" n'inclut pas les résolutions de bureau. Au lieu de cela, les documents AMP devraient bien paraître sur tous les appareils mobiles, de ces minuscules anciennes reliques de l'iPhone 4 que les gens utilisent encore jusqu'aux iPad Pro relativement gargantuesques.

Le premier objectif est principalement atteint par l'exigence que toutes les ressources chargées en externe aient des attributs de width et de height (et il est encore renforcé en limitant les scripts, ce qui garantit que de nouvelles ressources ne peuvent pas être intégrées). Ce dernier est réalisé par des requêtes média standard, l'attribut media , l'attribut sizes et l'attribut de mise en layout spécifique à AMP.

Voici un aperçu des mises en page actuellement prises en charge par AMP :

• nodisplay L'élément n'est pas initialement affiché, mais l'affichage peut être déclenché par une action de l'utilisateur. (Ceci est utilisé en conjonction avec des composants tels que amp-lightbox .)
• fixed L'élément a une largeur et une hauteur fixes, ce qui signifie que le moteur d'exécution ne peut appliquer aucun comportement réactif.
• À mon avis, c'est la plus utile et la plus magique des options de responsive en page d'AMP. L'élément utilise l'espace alloué tout en conservant son rapport hauteur/largeur. (En gros, "Faites en sorte que cette chose ait l'air bien à n'importe quelle résolution, s'il vous plaît et merci.")
• fixed-height L'élément utilise l'espace alloué mais conserve une hauteur fixe (mise à l'échelle horizontale).
• fill L'élément remplit le conteneur dans lequel il se trouve sans tenir compte des proportions. (Pensez à la width: 100% et à height: 100% ).
• container L'élément est un conteneur et, par conséquent, laisse ses enfants (par opposition à son parent) définir sa taille, exactement comme un élément div standard.

Il est relativement facile d'obtenir une mise en page de document fonctionnelle et simple à l'aide du système de mise en page d'AMP, mais lorsque vous considérez tout ce qu'il prend en charge et comment les valeurs s'appliquent aux différents types d'éléments, il y a beaucoup de nuances. Pour une ventilation beaucoup plus détaillée, consultez les spécifications de mise en page AMP.

Qu'en est-il du SVG ?

Prise en charge! SVG de base bénéficie d'une prise en charge complète sur les navigateurs de bureau et mobiles, et les graphiques ne deviennent pas beaucoup plus réactifs que les vecteurs, donc AMP et SVG forment une très bonne équipe. La plus grande limitation est qu'en raison des restrictions de script, vous ne pourrez pas animer vos vecteurs avec JavaScript - ce que, si nous sommes honnêtes, vous ne devriez probablement pas faire sur mobile de toute façon. Cependant, si vous devez vraiment donner un peu de vie à votre SVG, vous pouvez toujours le faire en utilisant des animations CSS, selon les mêmes contraintes décrites dans la section de style ci-dessus. N'oubliez pas que SVG fait partie du DOM, il peut donc être stylisé - et animé - aussi facilement que n'importe quel autre élément.

Philosophie d'AMP sur JavaScript

Bonnes et mauvaises nouvelles ici. La mauvaise nouvelle est que vous n'écrirez pas de code JavaScript pour vos documents AMP de si tôt. Mais d'une certaine manière, c'est aussi la bonne nouvelle. Gardez à l'esprit que AMP n'est pas un framework d' application mobile. Il s'agit plutôt d'un cadre d' article mobile, et parce que les articles doivent être optimisés pour des expériences de lecture transparentes et fluides, il n'y a vraiment pas beaucoup de bons cas d'utilisation pour les scripts lourds côté client.

Cela étant dit, interdire définitivement tout JavaScript est à la fois irréaliste et un peu draconien. La réalité est que le Web s'appuie sur JavaScript depuis un certain temps maintenant - même dans le contexte d'expériences de lecture simples et relativement fades - pour des choses comme la publicité, l'analyse et les fonctionnalités interactives. De plus, l'une des meilleures choses à propos du Web est son ouverture et sa capacité apparemment infinie d'expérimentation, d'expressivité et de créativité - dont une grande partie est alimentée par JavaScript.

Reconnaissant à la fois le fardeau que le JavaScript arbitraire écrit par l'utilisateur impose aux garanties de performances, ainsi que l'omniprésence et l'inévitabilité de JavaScript dans un environnement Web moderne, l'équipe AMP a proposé les principes de script suivants :

• Aucun JavaScript écrit par l'utilisateur n'est pris en charge ou autorisé pour le moment. Vous ne pouvez avoir que deux types de balises de script dans vos documents AMP : les balises de données liées (dont le type est application/ld+json ) et les balises pour inclure à la fois le runtime AMP et les composants AMP étendus.
• Les auteurs du projet AMP ont anticipé la plupart des besoins en JavaScript dans le cadre de la consommation d'articles mobiles, et donc AMP supporte soit des alternatives ( amp-pixel , y compris des polices personnalisées avec des balises de lien ou des règles @font-face , etc.) soit fournit des implémentations compatibles avec le runtime AMP et qui garantissent donc à la fois sécurité et performances ( amp-ad , amp-analytics , amp-carousel , etc.).
• Si vous devez vraiment utiliser JavaScript pour quelque chose comme une fonctionnalité interactive, vous pouvez créer la fonctionnalité indépendamment, puis l'inclure avec un [amp-iframe](https://www.ampproject.org/docs/reference/extended/amp-iframe.html) . Le contenu inclus dans un amp-iframe est même autorisé à une communication limitée avec le document parent pour des choses comme les demandes de redimensionnement.
• Les composants AMP sont open source (Apache 2) et ouverts aux contributions, donc de nouveaux composants apparaîtront au fil du temps (en fait, plusieurs nouveaux composants sont apparus au cours de l'écriture et de l'édition de cet article, j'ai donc déjà mis à jour plusieurs fois). Bien que l'équipe AMP donne la priorité aux composants généralisés par rapport aux fonctionnalités spécifiques au service (un widget spécifiquement pour votre startup sociale, par exemple), elle s'engage également à fournir suffisamment de diversité pour accueillir la plus large gamme de contenu possible.
• Enfin, toutes ces politiques sont susceptibles d'être modifiées. À mesure que les fonctionnalités du navigateur telles que les Web Workers, les éléments personnalisés et le DOM fantôme deviennent plus largement pris en charge, les options de prise en charge du JavaScript écrit par l'utilisateur et des composants personnalisés, tout en garantissant la sécurité et les performances, se développeront considérablement.

Pour plus d'informations sur l'avenir des composants AMP, consultez la section "Composants étendus" de la spécification "Composants HTML AMP".

Anatomie d'un document AMP

Maintenant que vous avez une compréhension assez solide du HTML AMP, décomposons un passe-partout.

Bien entendu, vous commencerez vos documents AMP par une déclaration doctype :

 <!doctype html>

Ensuite, désignez votre document HTML comme AMP HTML, ce que vous faites, croyez-le ou non, en utilisant l'emoji haute tension comme attribut dans la balise html :

 <html >

Ou, si vous êtes un grincheux à l'ancienne et que vous vous hérissez à l'idée d'orner votre code d'adorables emojis, vous pouvez utiliser l'attribut amp beaucoup plus conservateur à la place :

 <html amp> <!-- A good sign that you're boring! -->

Dans votre balise head , n'oubliez pas les instructions d'encodage de caractères utf-8 :

 <meta charset="utf-8">

Et créez un lien vers la version non AMP de votre document (marquée comme canonical , afin qu'elle n'apparaisse pas comme contenu dupliqué) :

 <link rel="canonical" href="my-non-amp-index.html">

Inversement, votre version non-AMP doit contenir une référence au document AMPlified :

 <link rel="amphtml" href="my-amp-index.html">

Étant donné que les pages AMP sont destinées aux appareils mobiles (et que vous souhaitez également une pixellisation GPU), assurez-vous d'inclure une balise viewport :

 <meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1">

La ligne de code suivante vous semblera un peu étrange, et c'est parce qu'elle l'est. Vous savez comment vous verrez parfois une page Web restituer brièvement le texte avant que les polices aient été chargées et appliquées, puis scintiller et restituer à nouveau l'aspect prévu par le concepteur ? La balise ci-dessous maintient l'opacité de la page à 0 (invisible) jusqu'à ce qu'elle soit correctement stylée.

 <style> body { opacity: 0 } </style> <noscript> <style> body { opacity: 1 } </style> </noscript>

Le problème avec cette approche est que, si le runtime AMP ne se charge pas, il est techniquement possible que l'opacité de la page ne passe jamais de 0 à 1 . Pour compenser de telles éventualités, le code ci-dessus sera probablement remplacé par quelque chose de plus proche de ceci :

 <style> body { animation: amp-timeout 0x 5s 1 normal forwards; } @keyframes amp-timeout { 0% {opacity: 0;} 100% {opacity: 1;} } </style>

La prochaine chose à faire est d'inclure l'environnement d'exécution JavaScript AMP :

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

Et incluez les implémentations JavaScript pour les composants étendus dont vous avez besoin :

 <script async custom-element="amp-youtube" src="https://cdn.ampproject.org/v0/amp-youtube-0.1.js"></script> <script async custom-element="amp-audio" src="https://cdn.ampproject.org/v0/amp-audio-0.1.js"></script> <script async custom-element="amp-carousel" src="https://cdn.ampproject.org/v0/amp-carousel-0.1.js"></script> <script async custom-element="amp-lightbox" src="https://cdn.ampproject.org/v0/amp-lightbox-0.1.js"></script> <script async custom-element="amp-anim" src="https://cdn.ampproject.org/v0/amp-anim-0.1.js"></script> <script async custom-element="amp-twitter" src="https://cdn.ampproject.org/v0/amp-twitter-0.1.js"></script> <!-- etc. -->

(Notez l'utilisation de l'attribut async . Ce n'est pas facultatif - moins il y a de blocage, mieux c'est.)

En option, vous pouvez saupoudrer un peu de données liées, comme ceci :

 <script type="application/ld+json"> { "@context": "https://schema.org", "@type": "NewsArticle", "headline": "Turn Your AMP up to 11!", "image": [ "img/cover-opt.jpg" ], "datePublished": "2015-01-11T08:00:00+08:00" } </script>

Ajoutons maintenant quelques polices, en utilisant soit des balises de link , soit des règles @font-face dans votre CSS :

 <link href='https://fonts.googleapis.com/css?family=Roboto+Condensed:300,700' rel='stylesheet' type='text/css'> <link href='https://fonts.googleapis.com/css?family=Lora:400,700,400italic,700italic' rel='stylesheet' type='text/css'>

Et puis nous aurons quelques styles (pas plus de 50 Ko), avec l'attribut amp-custom requis :

 <style amp-custom>

Vous êtes maintenant prêt à créer un document HTML plus ou moins standard en utilisant tout ce que vous venez d'apprendre sur AMP HTML.

L'environnement d'exécution AMP

Je ne passerai pas beaucoup de temps sur le runtime AMP car, comme tous les runtimes, c'est un peu une boîte noire. Cela ne veut pas dire que le runtime AMP est inaccessible (il est open source, comme le reste du projet). Au contraire, comme tous les bons runtimes, les développeurs n'ont pas besoin de savoir exactement comment cela fonctionne pour en tirer parti, tant qu'ils comprennent généralement ce qu'il fait.

L'environnement d'exécution AMP est entièrement implémenté en JavaScript et est lancé en l'incluant dans le document AMP, comme vous le feriez pour n'importe quel fichier JavaScript externe :

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

À partir de là, l'environnement d'exécution AMP effectue principalement trois opérations :

• gère le chargement et la priorisation des ressources,
• implémente les composants AMP,
• inclut éventuellement un validateur d'exécution pour AMP HTML.

Le validateur est essentiel à la création de documents conformes à l'AMP. Il peut être activé simplement en ajoutant #development=1 à l'URL du document. Ensuite, tout ce que vous avez à faire est d'ouvrir votre console pour voir votre bulletin.

Les erreurs ressemblent à ceci :

Un document AMP agréable, propre et conforme ressemble à ceci :

Le cache AMP (facultatif)

Les documents AMP peuvent être servis à partir d'un serveur Web comme n'importe quel autre document HTML, mais ils peuvent également être servis à partir d'un cache AMP spécial. Le cache optionnel utilise plusieurs techniques pour optimiser encore plus un document AMP :

• Les références d'image peuvent être remplacées par des images dimensionnées spécifiquement pour la fenêtre d'affichage du spectateur.
• Les images au-dessus du pli peuvent être intégrées pour enregistrer des requêtes HTTP supplémentaires.
• Les variables CSS peuvent être intégrées pour réduire la surcharge côté client.
• Les implémentations de composants AMP étendus peuvent être préchargées.
• HTML et CSS peuvent être minifiés pour réduire le nombre d'octets envoyés sur le réseau (ou, dans ce cas, les ondes).

N'importe qui peut exécuter son propre cache AMP sur son propre CDN, ou les éditeurs peuvent utiliser celui de Google gratuitement. Étant donné que Google semble connaître une chose ou deux sur l'évolutivité, je suppose que la plupart des utilisateurs d'AMP seront ravis d'accepter cette offre. (Documentation on how to opt in to Google's cache is forthcoming, but given that Google already indexes and caches the Internet, it's a safe bet that it will revolve around your link tags and perhaps an additional meta tag.)

How Do Readers Find AMP Content?

The fact that AMP document are more or less standard HTML that will render in any modern browser is, in my opinion, a huge advantage (AMP is far more open and inclusive than Facebook Instant Articles or Apple News). But from a practical perspective, it also raises the question of how audiences will find AMP content.

If readers use Google to search from a mobile device, Google can link directly to AMP versions of articles (Google has not said that it will prioritize AMP documents over non-AMP documents, but it has said that it will use “mobile friendliness” as a mobile search signal, so you do the math). In fact, Google has indicated that it will begin sending traffic to AMP pages from Google Search on mobile as early as late February 2016. Discovery and curation engines such as Pinterest may also choose to start directing mobile traffic to AMP pages (with a few infrastructure changes). Finally, websites can redirect their own mobile traffic from responsive versions of articles to their AMP counterparts. But from my perspective, a few pieces of the puzzle are still missing.

Will other search engines direct mobile traffic to AMP articles? (Perhaps not search engines that want to do business with Apple.) Will social networking apps preload AMP documents when users post links to articles, in order to make rendering nearly instantaneous? (Probably not Facebook.) Will mobile browsers start looking for link tags with amphtml relationships? (Chrome, maybe, but probably not mobile Safari.) And will aggregators and news readers out there build specifically for lightning-fast AMP content? (Time to resurrect Google Reader!)

At this point, the answers to most of these questions are the same: to be determined.

See AMP In Action

The easiest way to see AMP in action is to check out Google's search demo. If you're the trusting type, you can watch the video and just assume it all works as well as it's depicted. If you're more the trust-but-verify type, you can go to g.co/ampdemo on your mobile device and try out some AMP pages for yourself (QR code below).

You can also check out the AMP experience through desktop Chrome using Chrome's Developer Tools. All you have to do is this:

1. Go to g.co/ampdemo in Chrome.
2. Open the Developer Tools by going to “View” → “Developer” → “Developer Tools.”
3. Go into device mode by clicking on the little phone icon in the top-left corner.
4. Pick your favorite device to emulate. (For best results, reload the page in the emulator.)

Who's Adopting AMP?

It's still relatively early days for AMP, so it's hard to tell exactly who is adopting the new format in earnest, and to what extent. That being said, I've already seen several implementations out there in the wild, and according to the AMP FAQ and AMP blog, it's being taken seriously by many major publishers (metered content and subscription access is currently under review), CMS developers, advertisers, and analytics providers. I won't list them all here because I'm sure the landscape will change almost daily, but you can keep an eye on the AMP project's home page and/or the AMP blog for news.

What Do I Think?

I'm glad you asked. My guess is that just about all publishers will eventually adopt it. If companies like BuzzFeed have taught the industry anything, it's the importance of being in as many places as possible, and that digital publishing should be a technology platform capable of getting content in front of readers wherever they are, as opposed to being a singular destination waiting for readers to come to it.

The investment required to support AMP is also relatively minimal. If a publisher already supports — or plans to support — Facebook Instant Articles and Apple News, then they might as well implement support for AMP as well. While CMS strategies vary widely across the publishing industry, most CMS' have a concept of templates and/or plugins that, once implemented, would do most of the work of converting articles into AMP HTML. (WordPress, the closest thing we have to an industry leader, already has a plugin and plans on supporting AMP for all publishers in January 2016.) And because AMP is far less proprietary than its competition (meaning that it is open source, open to contributions, based on web technologies and client-agnostic), I would expect publishers to feel more comfortable distributing their content in a format that they feel they will have more control over long-term.

The reality is that publishers will back whatever syndication formats and partners will help get their content in front of the maximum number of readers with the least amount of overhead and investment. Right now, we are in the very early stages of a new type of war that is part platform, part format and in which each party will leverage its unique strengths to maneuver itself into the best possible position. At this point, it's far too early to say which will endure and which will become the RSS of tomorrow.

Ressources supplémentaires

• “Introducing the Accelerated Mobile Pages Project, for a Faster, Open Mobile Web” Google Official Blog
• Accelerated Mobile Pages Project, official website
• Accelerated Mobile Pages, blog
• AMP HTML, GitHub
• Docs, Accelerated Mobile Pages Project
• Nigel Tufnel explaining why his amp goes to 11