Depuis le lancement des pages AMP, de nombreux éditeurs de site reprochaient à cette technologie de reposer sur des URLs pointant vers des urls de … Google, pour afficher leur contenu.

En effet, les URLs ressemblaient à : https://www.google.com/amp/www.votredomaine.com/votrepage

Ceci posait de nombreux problèmes, notamment pour le tracking.

Depuis des mois, Google promettait de régler le problème. Mais la date de déploiement de la solution a été repoussée plusieurs fois. On sait maintenant quelle solution technique a été choisie, et comment cela va fonctionner.

Des URLs qui pointent toujours vers le cache AMP hébergé chez Google… mais depuis votre domaine

Le challenge consistait à trouver une solution pour substituer les URLs du domaine du site producteur de pages AMP, aux URLs pointant vers les pages du cache de Google, sans que l’éditeur des pages AMP aient besoin d’effectuer des manipulations supplémentaires complexes.

Google a introduit en début d’année une nouvelle technologie baptisée « signed http exchanges », qui permet de certifier l’origine du contenu affiché dans votre navigateur grâce à une clé cryptée. Au passage elle permet aussi de rendre « transparent » un serveur qui hébergerait ces contenus avec une autre url.

                                                    Le schéma de fonctionnement des « échanges signés »

Pour des pages AMP, cela signifie que l’url de ces pages peut à présent pointer vers le domaine de votre site, tout en continuant à appeler les pages stockées dans le cache de Google.

                  Les URLs des pages AMP : sans signed exchanges, et avec

Cela ne fonctionne pas exactement tout seul : l’éditeur des pages AMP doit installer sur son serveur un outil (l’AMP Packager), qui requiert l’installation d’un certificat fourni par un seul fournisseur aujourd’hui : Digicert. Il semble qu’il sera possible à terme d’utiliser aussi les services d’un CDN compatible avec les « signed exchanges » : Cloudflare a annoncé qu’ils allaient proposer d’embarquer cette technologie. D’autres CDN suivront peut-être.

Une solution qui peut être testée dès aujourd’hui

Pour que cela fonctionne, il faut aussi que le navigateur sache exploiter cette nouvelle technologie. Pour l’instant, aucun navigateur ne supporte les « signed http exchanges ». Le premier à le faire sera Chrome, dans sa version 71, qui n’est pas encore déployée complètement.

On peut néanmoins tester la nouvelle techonologie. Il faut pour cela passer par le Chrome beta channel pour installer la version bêta de Chrome 71, et d’aller sur le site de test https://g.co/webpackagedemo (via votre smartphone, ou en émulant un smartphone depuis votre ordinateur desktop) pour afficher des pages AMP montrant cette technologie. Si vous n’en trouvez pas, essayez le site des démo AMP, en tapant la requête « Learn AMP by example ». Et vous verrez ceci :

Une solution qui demandera du temps pour être réellement exploitable

Cette solution est-elle la panacée ? Non. Hélas.

Les « échanges signés » ont certes une vraie chance de devenir un standard du web. Car cette technologie a été intégrées dans les normes du consortium W3C sur le web packaging. C’est une solution sûre et élégante au problème, contrairement aux différents hacks proposés par les ingénieurs de Google au cours de l’année 2017.

Mais il faudra du temps pour que tous les navigateurs supportent les signed exchanges. Au début, seul les versions hyper récentes des browsers le supporteront. Et on ne sait pas quand Firefox, Edge ou Firefox embarqueront cette technologie. Bref, il va falloir être patient : il faudra des mois, voire des années, avant qu’une proportion hyper majoritaire des navigateurs utilisés supportent cette technologie.

Vous aviez rêvé de pouvoir utiliser un first party cookie sur vos pages AMP ? Et bien vos rêves vont se réaliser. Mais pas exactement demain matin…

Pour en savoir plus :
– la page d’annonce du consortium AMP
– le Git des signed http exchanges