Toi aussi tu te demandes pourquoi l’AMP est sensé être si rapide ? Ça tombe bien dis donc, je vais justement en parler 🙂

L’AMP est sans nul doute la dernière techno à la mode dès que l’on va parler d’optimiser la vitesse de chargement de son site web, que ce soit du eCommerce ou non. Enfin, je devrais plutôt dire lorsque l’on souhaite que son contenu soit chargé rapidement. Pourquoi une telle différence ? Car les pages AMP sont aussi servies dans les résultats de recherche de Google, et l’internaute n’atteindra pas directement votre site à ce moment-là.

Cet article va s’inscrire dans une série d’articles plus large sur l’AMP. En effet, moi aussi j’ai besoin de me former, et quoi de mieux que te faire un ou deux articles basés sur des lectures importantes et spécialement sélectionnés pour toi (et aussi un peu pour moi hein :p)

Aujourd’hui, je vais donc me pencher un peu plus sur l’article de Malte Ubl : Why AMP is fast. Après tout, ce n’est jamais que le tech lead sur le projet AMP 😉

Pourquoi l’AMP est-il si rapide ?

Le projet AMP a été conçut pour offrir un chargement quasi instantanée aux composants web. Ce qui va suivre est une liste désordonnée des différentes optimisations qui ont lieu au sein de tout document AMP, qui tous mis bout-à-bout feront que ton site web va se charger à la vitesse de l’éclair.

Même si tout ce qui va suivre est mis en ligne pour parler des optimisations offertes par l’AMP, sache quant même que chacune de ces optimisations peut-être réalisées indépendamment sur ton site, et le rendre plus rapide à charger. Mais si tu veux faire de l’AMP, alors tout ce qui suit est un prérequis et te permettra de mieux comprendre comment l’AMP parvient à cet “exploit”.

Lazy Load

Le Lazy load ou chargement paresseux en bon français, est une technique en JavaScript qui consiste à ne charger certains éléments que lorsqu’ils sont visibles par l’internaute. L’utilisation du lazy load en AMP est la base.

Utilisation intensive de preconnect

Preconnect est une toute nouvelle directive HTTP offerte par l’API qui permet d’assurer un branchement prémonitoire sur les contenus web. L’idée, tu l’auras compris, gagner du temps sur ce que l’on pense que pourra faire l’utilisateur. Le projet AMP fait une utilisation massive de cette directive et offre par exemple, des temps de chargement record sur les données en lazy load lorsque celles-ci sont effectivement demandées.

Les ressources Lazy load en prefetching

Parfois, j’adore certains titres. Celui-ci en fait parti. Sérieux, si tu comprends ni le mot lazy load ni prefectching, c’est du Chinois !

Bon, le but du lazy load est de charger les ressources le plus tard possible. Mais… Littéralement, prefetching signifie aller chercher en avance. L’idée est donc que la ressource en question soit chargée très tôt. En fait, le plus tôt possible (prefetching), mais que le CPU ne soit utilisé que lorsque cela est vraiment nécessaire (Lazy load).

Tout le JavaScript en asynchrone

Tu veux un site valide AMP ? Alors il va falloir que 100% de tes ressources JavaScript soient chargées en asynchrone.

Pour faire simple, le JavaScript asynchrone c’est de la délégation au navigateur web. Tu veux en savoir plus ? Va lire ça ! 😉

CSS en ligne

Si j’adore le roller en ligne, après une rapide recherche, il semblerait que l’utilisation du inline CSS pose soucis mais… réduit le nombre de requêtes HTTP. Au grand minimum, une requête sera supprimé. Tu l’auras compris… Le inline CSS style est obligatoire en AMP.

Attention quand même… Le style inline impose une limite un peu chiante quand même. Si tu veux faire des trucs super sophistiqués, va falloir aller voir ailleurs. Pourquoi ? Car le style inline autorise un nombre maximum de caractères à être passé au système.

Zéro requête HTTP bloquante pour téléchargement de font (police)

L’utilisation de @font-face est souvent synonyme de site personnalisé à font, mais aussi de lenteur pour l’internaute. Que cela soit une lenteur réelle ou perçue.

Comme tous le JavaScript en AMP est asynchrone; comme tout le CSS est en ligne; il est interdit d’utiliser une requête bloquante pour le navigateur de type téléchargement de police (font). Dis autrement, oublie les polices personnalisés en AMP.

Chargement instantané grâce au prerending

L’AMP est optimisé pour permettre une utilisation peu coûteuse et sûre du pré-rendue. Par pré-rendue on entend  qu’une ressource est traitée avant que l’utilisateur ne signifie explicitement qu’il souhaite y accéder. Avec cette technique, la page est disponible en moins de temps qu’il ne faut à l’utilisateur pour cliquer sur le lien. On arrive donc à ce que l’on peu appeler chargement instantané.

Prerending uniquement au-dessus de la ligne de flottaison

Lorsqu’une page en AMP se retrouve en mode prerending dans l’optique de faire du chargement instantané, seul les ressources en dessous de la ligne de flottaison doivent être traités.

Mais… uniquement si cette dite ressource n’est pas gourmande en CPU. Car si le prerending devait se faire sur ce type de ressource, l’internaute serait moyen content je pense. En fait, la ressource n’est pas téléchargée du tout. Un bon exemple à cela : les iframes.

Priorisation intelligente des ressources

L’AMP, ce n’est pas que des règles sorties de nul part. En fait, on remarque que nombre de recommandations sonnent comme logiques. Et si j’en parle maintenant, c’est qu’à mes oreilles, voici le type de recommandation qui est de l’ordre de la logique. Fais en sorte que les ressources les plus importantes pour celui qui les demandes soient envoyées en premier. Cela permettra certainement à ton utilisateur d’avoir la sensation que c’est rapide. Même si d’autres choses se chargent ensuite, si ce qu’il veut est à l’écran, il te dira que ta page est entièrement chargée va 😉

FastDOM

Petit détail, l’AMP traite les DOM de cette manière : Dans chaque “fenêtre d’animation” l’AMP exécute toutes les opérations de lecture sur le DOM, et lorsque c’est terminé, exécute les opérations d’écriture. Cela réduit à un seul recalcule de style par frame.

Réduire le coût analytique

Grâce à l’AMP est sa manière particulière d’implémenté le support des données analytiques, il vous sera possible d’embarquer autant de tracker que tu veux. Cela ne changera pas le coût que représente la présence de tags analytics sur vos pages. L’AMP les traiteras tous comme un seul.

Accélération GPU

Lorsqu’il est question de CSS animé en AMP, tu peux être au moins certain que cela fera appel à de l’accélération GPU lorsque cela est possible. L’avantage ? Tu es enfin certain que ton animation ne sera ni toute floue, ni  saccadé.

Mashup non bloquant

Ce n’est pas parce que c’est de l’AMP, que l’on ne peut rien faire de cool. Si tu veux intégrer une pop in, ou encore des boutons de partages, tu peux le faire ! Mais, il faudra t’assurer que les appels soient non bloquant pour le rendu de la page.

CDN

Je terminerais sur ce point, et ce n’est pas par hasard. Si tu trouves qu’une page en AMP se charge à la vitesse de la lumière, et que tu es sur Google, alors saches que l’AMP est très loin d’être l’unique facteur qui permet cette rapidité. En fait, les pages AMP sont stockés… sur le CDN de Google. Et oui, le contenu n’est même pas chargé à partir de ton site.

Mais bon, cela ne vaut que si l’internaute vient de Google. Mais le but de cet exemple était de te faire comprendre que derrière le mot AMP, il y aussi et surtout le mot CDN.

Tu as des retours à nous faire sur une expérience avec l’AMP ? Fais-toi plaisir dans les commentaires l’ami 😉