Google AMP ⚡ : point de vue d'un développeur

On a beaucoup parlé de l’AMP (accelated mobile pages) de Google depuis son lancement mondial dans la liste des grands moteurs de recherche….
amp
.. . et dans cet article je veux donner mon avis sur ses bons et mauvais points, en tant que développeur et propriétaire de site. Mais tout d’abord…

Pourquoi ?

Réponse officielle. A-t-on besoin d’un autre format que le HTML pour générer des pages à chargement rapide?
Evidemment, la réponse logique est non, car HTML ce n’est pas le problème, HTML est en fait plutôt efficace. Le problème en ce qui concerne la rapidité de chargement ce sont les iframes, réseaux publicitaires internet (ad networks), gifs et autres tags script. Qu’AMP a essayé de liquider d’un seul coup ! Mais ils ne l’ont pas fait…
Alors, pourquoi est-ce qu’on fait ça? Lisez ce qui suit.

Les bons cotés

  • Le web — et en particulier les sites d’info — est devenu un grand bazar à cause des publicités et des boutons de partage. Nous savons bien que le fait de bloquer les publicités améliore sensiblement notre expérience de navigation. Au départ AMP n’autorise aucun contenu Third-Party. Les specs demandent que les outils externes s’accrochent à des composants HTML custom. Jetez un oeil. C’est une grande victoire pour les utilisateurs, mais pour les développeurs, c’est encore une nouvelle spec custom à gérer. J’espère que vous utilisez les ad networks autorisés sinon… pas de chance. Et d’ailleurs, est ce que votre CMS est prêt pour <amp-youtube>?
  • Une partie de la spec AMP est de baliser votre contenu avec des métadata. Pour les utopistes, Google souhaite que les publishers mettent en oeuvre les métadonnées afin qu’ils aient une meilleur compréhension des attributs et du contexte du contenu de la page, mais pour les cyniques, c’est pour extraire votre contenu et l’injecter directement dans une SERP (Search Engine Result Page). Le bon coté : la nouvelle json-ld spec est beaucoup plus claire que Microdata son prédécésseur (malheureusement encore en vie), qui implique itemscope, itemprop, meta, RDFa ou même des attributs vcard imbriqués dans des éléments DOM.
  • Plus de visibilité dans la page de résultat de Google.com. L’icone AMP peut attirer plus de visites sur votre listing. Elle a aussi été lancée avec un petit booster de Ranking (mise à jour : officiellement, pas de booster de ranking). Mon expérience est que Google dit généralement ça pour que les développeurs adoptent les nouveaux protocoles. Personnellement, je n’ai pas perçu de légère hausse. Et même si cela augmentait votre ranking, tous vos concurrents suivraient et dans 6 mois, il n’y aurait plus d’avantage compétitif. Pour les publishers sur Google News, ce qui est le cas de mon site, le carrousel de news apparait plus souvent et les articles AMP sont beaucoup plus vus qu’avant. Merci Google !
  • Rapidité ! Oui, le rendu est quasi instantané. Et je sais que tous les utilisateurs non-4G/non-Wifi de la planète trouveront que c’est une killer feature à avoir. Elle inclue SSL par défaut. Et même le bon vieux tag <img> a été abandonné à la faveur de <amp-img> pour des raisons de rapidité.

Le mauvais coté

  • Maintenance d’une copie carbone du contenu de votre site. Oui, AMP vit sur sa propre URL que vous hébergez vous-même. Seul Google va pouvoir le visiter, ce n’est pas sensé être une une cible vers laquelle envoyer vos visiteurs (vous pourriez). Des problemes vont apparaitre, et vous allez vous en rendre compte par la suite. Aussi, Google va servir aux utilisateurs sa propre copie de votre site. Ils ferment la porte aux pages customisées pour les utilisateurs connectés. Ils vous autorisent à pinguer leur CDN pour mettre à jour une version plus fraiche. Mais oui, c’est plus de truc à gérer. Pas cool. Bien que Webmaster Tools a de bons compte rendus de problèmes. Mise à jour : et ce nouvel outil de debug.
  • Suite au point ci dessus. Je pensais qu’on faisait tous du web responsive et qu’on ne ferait plus de pages spéciales mobiles ? Je me trompais. AMP est pour les mobiles. Donc vous faite une page mobile custom. Jusqu’à ce qu’ils acceptent aussi le desktop. Pour lequel je devine que vous feriez des media-queries pour que ça fonctionne aussi la dessus.
  • La version AMP-ifiée est généralement moins engageante pour l’utilisateur car réduite aux spec HTML. En comparant le page-per-visit d’une page AMP-ifiée Vs non AMP-ifiée, les utilisateurs sont plus rapidement entrés mais plus rapidement sortis. C’est peut-être dû au fait qu’il y ait moins de désordre sur la page non AMP mais c’est mal. Et j’ai vu plusieurs rapports. On pourrait dire que c’est en fait une bonne chose. Ils supportent des trucs comme les images carrousels – je ne peux pas vivre sans – mais seulement ceux fournis par Google.
  • La spec a commencée simple et efficace. Mais elle devient hors de control et supporte de plus en plus de features web existantes. Bon exemple : les notification pour accepter les Cookies. Il y a une spec custom pour ça. Elle est attachée à un utilisateur, et fait une request CORS sur votre backend. Et n’oubliez pas Glycat ! Je ne vois pas de fin à l’horizon.
  • Plus difficile à monétiser. La raison pour laquelle tous ces ad networks sont chargés dans une même page est pour gagner le plus d’euros possible par page view. Par exemple, mon ad networks n’est pas encore supporté, ce qui fait que je suis comme revenu en 2004, avec une seule unité Adsense, avec des revenus divisés par deux.

Mon conseil

Si AMP est un succès, Google serait le grand gagnant. Ils auraient des résultats qui se chargent instantanément, améliorant considérablement la Google Experience™ invitant l’utilisateur à utiliser encore plus de Google.
En tant que développeur, je ne vois pas ce que m’apporte une copie mobile AMP de mon site. C’est plutôt rétrograde comme truc.
Eh Google ! Faisons chacun la moitié du chemin. Les utilisateurs sur 2G ou GPRS reçoivent l’AMP-ifiée, je fournirai un site AMP, mais on continue de servir une version non-AMP-ifiée à tous les autres utilisateurs (ex: Iphone 7 4G), Non ?
Bon sang, je vais même proposer une spec pour ça : amp-audience-target-only. LGTM.
Article original écrit par Yvo Schaap traduit par JS Staff
 
[separator type=”” size=”” icon=”star”] [actionbox color=”default” title=”” description=”JS-REPUBLIC est une société de services spécialisée dans le développement JavaScript. Nous sommes centre de formation agréé. Retrouvez toutes nos formations techniques sur notre site partenaire dédié au Training” btn_label=”Nos formations” btn_link=”http://training.ux-republic.com” btn_color=”primary” btn_size=”big” btn_icon=”star” btn_external=”1″]