AMP
FR
English Deutsch العربية Español Italiano Indonesia 日本語 한국어 Português Русский Türkçe 中文 Polski Tiếng việt

Comment optimiser vos pages AMP hébergées

Ce guide fournit des astuces et des conseils aux webmasters sur la façon dont ils peuvent optimiser leurs sites Internet AMP hébergés.

AMP n'est-il pas rapide par défaut?

Le runtime AMP est optimisé en vitesse et si vos pages AMP sont diffusées par un cache AMP, elles sont entièrement optimisées et offrent les meilleures performances de chargement. Par exemple, si vos utilisateurs accèdent à vos pages AMP à partir de la recherche Google sur mobile, par défaut, les pages sont diffusées par un cache AMP.

Cependant, les pages AMP ne sont pas toujours diffusées à partir d'un cache AMP. Un site Internet peut décider d'afficher des pages AMP depuis ses propres serveurs pour d'autres sources de trafic. Les cas d'utilisation les plus fréquents sont les sites entièrement créés en AMP, tels que tasty.co, où les utilisateurs accèdent directement au site. Une autre source de trafic est Twitter, qui a commencé à créer des liens vers des pages AMP au lieu de fournir la version mobile standard. Cela signifie que si un utilisateur clique sur un lien dans l'une des applications mobiles de Twitter, le lien va vers la version AMP de votre page sur votre propre origine (si elle est disponible).

Par conséquent, vous ne pouvez pas toujours être sûr que vos pages AMP sont uniquement diffusées à partir d'un cache AMP. Dans ces cas, où vous diffusez des pages AMP à partir de vos propres serveurs, il est important de vous assurer que vos pages AMP offrent des performances de chargement optimales.

Les pages AMP chargent rapidement par défaut, mais vous pouvez implémenter des optimisations de performances supplémentaires pour aider le navigateur à charger les pages AMP encore plus rapidement. Ce guide décrit quelques optimisations à prendre en compte lors de la publication de pages AMP. Cependant, avant de commencer à lire ce guide, assurez-vous d'avoir déjà couvert toutes les bonnes pratiques de base en matière de performances Web. L'optimisation de l'image en particulier a un impact important sur les performances de chargement.

Par exemple, en appliquant les techniques d'optimisation suivantes:

le modèle « The Scenic » charge deux secondes plus vite sur une connexion 3G.

Si vous souhaitez ignorer les détails, consultez le générateur de modèles AMP, que vous pouvez utiliser pour générer des pages AMP optimisées personnalisées.

Optimiser le chargement du runtime AMP

Bien que AMP soit déjà assez restrictif sur le balisage autorisé dans la section <head>, l'optimisation reste possible. Le secret est de structurer la section <head> de manière à ce que tous les scripts de blocage de rendu et les polices personnalisées chargent le plus rapidement possible.

Voici l'ordre recommandé pour la section <head> dans une page AMP:

<!doctype html>
<html ⚡ lang="en">
  <head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width">
    <meta name="description" content="This is the AMP Boilerplate.">
    <link rel="preload" as="script" href="https://cdn.ampproject.org/v0.js">
    <link rel="preload" as="script" href="https://cdn.ampproject.org/v0/amp-experiment-0.1.js">
    <link rel="preconnect dns-prefetch" href="https://fonts.gstatic.com/" crossorigin>
    <script async src="https://cdn.ampproject.org/v0.js"></script>
    <script async custom-element="amp-experiment" src="https://cdn.ampproject.org/v0/amp-experiment-0.1.js"></script>
    <!-- Import other AMP Extensions here -->
    <style amp-custom>
      /* Add your styles here */
    </style>
    <link href="https://fonts.googleapis.com/css?family=Inconsolata" rel="stylesheet">
    <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.selected}}@-moz-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@-ms-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@-o-keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}@keyframes -amp-start{from{visibility:hidden}to{visibility:visible.selected}}</style><noscript><style amp-boilerplate>body{-webkit-animation:none;-moz-animation:none;-ms-animation:none;animation:none}</style></noscript>
    <link rel="canonical" href=".">
    <title>My AMP Page</title>
  </head>
  <body>
    <h1>Hello World</h1>
  </body>
</html>

Examinons cela étape par étape:

  1. La première balise doit être la balise meta charset, suivie de toutes les autres balises meta.

  2. Ensuite, préchargez la balise du runtime AMP v0.js <script> avec <lien as=script href=https://cdn.ampproject.org/v0.js rel=preload>. Le téléchargement du runtime AMP devrait commencer dès que possible car le modèle AMP cache le document via body { visibility:hidden } jusqu'à ce que le runtime AMP soit chargé. Le préchargement du runtime AMP indique au navigateur de télécharger le script avec une priorité plus élevée. Consultez la section affichage côté serveur pour savoir comment éviter cela. {amp-img6} {/amp-img6}

  3. Si votre page comprend des extensions de retard d'affichage (par exemple, amp-experiment, amp-dynamic-css-classes, amp-story), préchargez ces extensions car elles sont requises par le runtime AMP pour afficher la page.

<link as="script" rel="preload" href="https://cdn.ampproject.org/v0/amp-custom-css-0.1.js">
<link as="script" rel="preload" href="https://cdn.ampproject.org/v0/amp-experiment-0.1.js">
<link as="script" rel="preload" href="https://cdn.ampproject.org/v0/story-1.0.js">
  1. Utilisez la préconnexion pour accélérer la connexion à une autre origine où l'URL complète de la ressource n'est pas connue à l'avance, par exemple, lors de l'utilisation de Google Fonts:
<link rel="preconnect dns-prefetch" href="https://fonts.gstatic.com/" crossorigin>
  1. Chargez le runtime AMP:
<script async src="https://cdn.ampproject.org/v0.js"></script>
  1. Spécifiez les balises <script> pour les extensions de retard d'affichage (p. ex., amp-experiment amp-dynamic-css-classes et amp-story
  2. Spécifiez les balises <script> pour les extensions restantes (par exemple, amp-bind ...). Ces extensions ne retardent l'affichage et ne doivent donc pas être préchargées car elles consommer supprimer une bande passante importante pour l'affichage initial.
  3. Spécifiez les styles personnalisés à l'aide de la balise <style amp-custom>.
  4. Ajoutez toutes les autres balises autorisées dans la section <head>. En particulier, toutes les polices externes doivent être appliquées en dernier puisqu'elles bloquent l'affichage.
  5. Enfin, spécifiez le modèle standard AMP. En mettant le modèle standard en dernier, il empêche les styles personnalisés de remplacer accidentellement les règles css standard.

Le cache AMP effectue toutes ces optimisations automatiquement (et d'autres encore). Vous pouvez utiliser l'outil AMP Optimizer pour effectuer automatiquement ces optimisations sur votre propre origine.

Précharger des images de héros

AMP HTML utilise son propre élément image: amp-img. Si amp-img présente de nombreux avantages comparé à la balise HTML traditionnelle img, l'un de ses inconvénients est que le runtime AMP doit être chargé pour que le téléchargement de l'image puisse démarrer. Pour certaines images, telles que les images de héros d'une page de produit, il est crucial que les images puissent charger le plus rapidement possible. Dans ces cas, il est préférable de précharger l'image afin d'assurer que le navigateur démarre le téléchargement aussitôt que possible sans devoir attendre le chargement complet du runtime AMP.

<head>
  <link rel="preload" href="/images/elephants.png" as="image">
</head>
<body>
  ...
  <amp-img width="404" height="720" layout="responsive"
           src="/images/elephants.png" alt="..." >
  </amp-img>
</body>

Mais que faire si votre mise en page interactive nécessite différentes images de héros en fonction de la largeur de l'écran? Par exemple, une image large pour ordinateur de bureau et une image plus petite pour mobile comme celle-ci:

<amp-img width="404" height="720"
    alt="..." layout="responsive"
    src="/images/elephants_narrow.png"
    media="(max-width: 415px)">
</amp-img>
<amp-img height="720"
    alt="..." layout="fixed-height"
    src="/images/elephants_wide.jpg"
    media="(min-width: 416px)">
</amp-img>

La bonne nouvelle est que link rel=preload prend également en charge les requêtes multimédias. Nous pouvons donc utiliser les mêmes requêtes multimédias dans nos déclarations de préchargement, comme ceci:

<link rel="preload" as="image"
    href="/images/elephants_narrow.png"
    media="(max-width: 415px)">
<link rel="preload" as="image"
    href="/images/elephants_wide.jpg"
    media="(min-width: 416px)">

En passant, la même approche est valable pour les images d'affiche amp-video:

<link rel="preload" href="/images/poster.jpg" as="image">
...
 <amp-video width="480" height="270" src="elephant.mp4"
             poster="/images/poster.jpg"
             layout="responsive">
     ...
</amp-video>

Assurez-vous juste de placer les déclarations de préchargement après la déclaration de fenêtre, car le navigateur a besoin des dimensions de la fenêtre pour déterminer la largeur de l'écran.

<meta name="viewport" content="width=device-width">
...
<link rel="preload" media="(max-width: 415px)" ...>

Ne préchargez que les images cruciales, sinon le téléchargement de l'image peut utiliser la bande passante nécessaire pour d'autres téléchargements importants.

Pensez à utiliser un service worker

Maintenant que tous les principaux navigateurs prennent en charge les services workers, il est judicieux d'évaluer s'il est avantageux d'ajouter un service worker à votre site.

Nous savons qu'il existe deux modèles architecturaux différents qui fonctionneront pour des navigations rapides et fiables:

  • Pour les applications monopage: le modèle App Shell (appelé AMP-in-PWA dans le contexte AMP). Ce modèle nécessite un service worker pour mettre à niveau un document AMP vers l'expérience PWA basée sur le shell d'application.
  • Pour les applications multi-pages: diffusion de ressources composites. Un service worker met en cache l'en-tête et le pied de page statiques et utilise la diffusion en continu pour renvoyer instantanément une réponse partielle en cache lors du chargement du contenu.

Si aucun de ces modèles n'est utilisé et qu'il n'est pas possible de mettre en cache l'ensemble du site (ce qui n'est raisonnable que pour les très petits sites), un service worker peut avoir un impact négatif sur les performances. La meilleure solution dans ce cas est de ne pas utiliser un service worker.

Cependant, si vous souhaitez que votre site Web puisse être installé à partir de l'écran d'accueil ou que vous souhaitez offrir une expérience hors ligne, vous devrez utiliser un service worker. Dans ce cas, il est important d'utiliser la précharge de la navigation pour atténuer le ralentissement potentiel (Remarque: actuellement, la précharge de la navigation n'est prise en charge que dans Chrome).

Si votre site Web AMP utilise un service worker, voici quelques bonnes pratiques:

  • Mettez en cache le runtime AMP et les extensions (par exemple, amp-carousel).
  • Mettez en cache les logos, polices et autres contenus statiques utilisés sur la plupart de vos pages.
  • Diffusez des logos, des polices et des images en utilisant une stratégie cache-first.
  • Diffusez le runtime et les extensions AMP à l'aide d'une stratégie stale-while-validate.
  • Lorsque vous utilisez une stratégie axée sur le réseau pour les demandes de navigation, assurez-vous d'activer le préchargement de navigation.

Si vous recherchez un moyen de démarrer avec un service worker dans votre site AMP, consultez cet exemple qui fournit un service worker qui implémente toutes ces bonnes pratiques.

Le runtime AMP est diffusé avec une durée maximale de 50 minutes seulement pour garantir que les mises à jour sont disponibles rapidement. Pour éviter les échecs probables du cache du navigateur, il est judicieux de servir le runtime AMP à partir d'un service worker.

La mise en cache n'est pas seulement pertinente pour la transition des pages AMP mises en cache vers des pages non AMP sur votre propre origine, mais également pour la transition des pages AMP mises en cache vers des pages AMP sur votre propre origine. La raison en est que le cache AMP réécrit les URL du runtime AMP de l'URL permanente vers la dernière version publiée, par exemple:

https://cdn.ampproject.org/v0.js -> https://cdn.ampproject.org/rtv/001515617716922/v0.js.

Par conséquent, une page AMP diffusée à partir de votre propre origine ne bénéficie pas de la mise en cache du navigateur et doit dans ce cas télécharger à nouveau le runtime AMP (sans version). Avec un service worker, vous pouvez mettre en cache en amont le runtime AMP non versionné et accélérer la transition. Pour en savoir plus sur les raisons pour lesquelles le cache AMP crée des version d'URL du runtime AMP, lisez ce document.

Dans Safari, il existe une différence essentielle dans la façon dont les service workers sont implémentés: il n'est pas possible dans Safari d'installer un service worker pour votre origine, si la page est diffusée à partir d'un cache AMP.

Optimiser les polices personnalisées

Avec AMP, vous pouvez faire plusieurs choses pour optimiser le chargement de vos polices (la plupart d'entre elles ne sont en fait pas spécifiques à AMP):

  • Si possible, utilisez font-display: optional: cela n'utilisera la police que si elle se trouve déjà dans le cache, et utilise la police système si votre police personnalisée n'a pas encore été chargée.
  • Optimisez vos polices Web (par exemple, fournissez des polices personnalisées à l'aide de WOFF2).
  • Préchargez les polices personnalisées:
<link rel="preload" as="font" href="/bundles/app/fonts/helveticaneue-roman-webfont.woff2" >
  • Si vous utilisez Google Fonts ou tout autre fournisseur de polices avec des URL de polices inconnues, préconnectez le serveur de polices respectif:
 <link rel="preconnect dns-prefetch" href="https://fonts.gstatic.com/" crossorigin>

Dernier point mais non le moindre, essayez de minimiser le nombre de polices personnalisées que vous utilisez sur votre page. Si vous le pouvez, utilisez les polices système au lieu de polices personnalisées, car les polices système font correspondre votre site Web au système d'exploitation de l'utilisateur et évitent de charger davantage de ressources.

Mises en page AMP d'affichage côté serveur

Les mises en page AMP d'affichage côté serveur sont une technique que les caches AMP utilisent pour accélérer davantage le temps de chargement. Avec l'affichage côté serveur, il est possible de supprimer le modèle AMP afin que le document AMP puisse être peint sans exécuter le JavaScript du runtime AMP. Par exemple, la version affichée côté serveur du générateur de modèles AMP est deux fois plus rapide que la version AMP normale!

Si vous publiez une page AMP, vous devez absolument envisager d'utiliser AMP Optimizer. Les optimiseurs AMP vous permettent de diffuser des pages AMP optimisées à partir de votre propre back-end, qui comprend des mises en page AMP d'affichae côté serveur. AMP Optimizer effectue également automatiquement de nombreuses autres optimisations décrites dans ce document.

Optimisations de base

Bien entendu, toutes les bases de l'optimisation des performances Web s'appliquent également aux pages AMP: