Préchargement, prérendu et préchargement de service worker

Dans les derniers modules, vous avez découvert des concepts tels que le report du chargement de JavaScript et le chargement différé des images et des éléments <iframe>. Le report du chargement des ressources réduit l'utilisation du réseau et du processeur lors du chargement initial de la page. Il télécharge les ressources au moment où elles sont nécessaires, plutôt que de les charger à l'avance, où elles pourraient potentiellement être inutilisées. Cela peut réduire le temps de chargement initial des pages, mais les interactions ultérieures peuvent entraîner un retard si les ressources nécessaires pour les alimenter ne sont pas déjà chargées au moment où elles se produisent.

Par exemple, si une page contient un sélecteur de date personnalisé, vous pouvez différer les ressources de ce sélecteur jusqu'à ce que l'utilisateur interagisse avec l'élément. Toutefois, le chargement à la demande des ressources du sélecteur de date peut entraîner un retard (peut-être léger, mais peut-être pas selon la connexion réseau de l'utilisateur, les fonctionnalités de l'appareil ou les deux) jusqu'à ce que les ressources soient téléchargées, analysées et disponibles pour l'exécution.

C'est un peu délicat. Vous ne voulez pas gaspiller de la bande passante en chargeant des ressources qui peuvent rester inutilisées, mais retarder les interactions et les chargements de page ultérieurs peuvent ne pas être parfaits non plus. Heureusement, il existe un certain nombre d'outils que vous pouvez utiliser pour trouver un meilleur équilibre entre ces deux extrêmes. Ce module présente certaines techniques que vous pouvez utiliser pour y parvenir, telles que le préchargement de ressources, le préchargement de pages entières et la pré-mise en cache de ressources à l'aide d'un service worker.

Précharger les ressources nécessaires dans un avenir proche à faible priorité

Il est possible de récupérer de manière préventive des ressources (y compris des images, des feuilles de style ou des ressources JavaScript) à l'aide de l'indice de ressource <link rel="prefetch">. La suggestion prefetch informe le navigateur qu'une ressource sera probablement requise dans un avenir proche.

Lorsqu'une suggestion prefetch est spécifiée, le navigateur peut ensuite lancer une requête pour cette ressource avec la priorité la plus basse afin d'éviter de concurrencer les ressources requises pour la page actuelle.

Le préchargement des ressources peut améliorer l'expérience utilisateur, car l'utilisateur n'est pas obligé d'attendre que les ressources nécessaires soient téléchargées dans un avenir proche, car elles peuvent être instantanément extraites du cache du disque au moment où elles en ont besoin.

<head>
  <!-- ... -->
  <link rel="prefetch" as="script" href="/date-picker.js">
  <link rel="prefetch" as="style" href="/date-picker.css">
  <!-- ... -->
</head>

L'extrait de code HTML précédent informe le navigateur qu'il peut précharger date-picker.js et date-picker.css une fois qu'il est inactif. Il est également possible de précharger les ressources de manière dynamique lorsque l'utilisateur interagit avec la page dans JavaScript.

prefetch est compatible avec tous les navigateurs récents, à l'exception de Safari, où il est disponible derrière un indicateur. Si vous avez besoin de charger de manière préventive des ressources pour votre site Web d'une manière qui fonctionne dans tous les navigateurs (et que vous utilisez un service worker), consultez la section suivante de ce module concernant la mise en cache préalable des ressources à l'aide d'un service worker.

Prélire les pages pour accélérer les navigations futures

Il est également possible de précharger une page et toutes ses sous-ressources en spécifiant l'attribut as="document" lorsqu'elle pointe vers un document HTML:

<link rel="prefetch" href="/page" as="document">

Lorsque le navigateur est inactif, il peut envoyer une requête de faible priorité pour /page.

Dans les navigateurs basés sur Chromium, vous pouvez précharger des documents à l'aide de l'API Speculation Rules. Les règles de spéculation sont définies en tant qu'objet JSON inclus dans le code HTML de la page, ou ajouté dynamiquement via JavaScript:

<script type="speculationrules">
{
  "prefetch": [{
    "source": "list",
    "urls": ["/page-a", "/page-b"]
  }]
}
</script>

L'objet JSON décrit une ou plusieurs actions (actuellement compatibles avec prefetch et prerender), ainsi qu'une liste d'URL associées à cette action. Dans l'extrait de code HTML précédent, le navigateur est invité à précharger /page-a et /page-b. Comme pour <link rel="prefetch">, les règles de spéculation indiquent que le navigateur peut ignorer dans certaines circonstances.

Les bibliothèques telles que Quicklink améliorent la navigation sur les pages en préchargeant ou en prérendu de manière dynamique les liens vers les pages une fois qu'elles sont visibles dans la fenêtre d'affichage de l'utilisateur. Cela augmente la probabilité que l'utilisateur accède à cette page, par rapport au préchargement de tous les liens de la page.

Précharger les pages

En plus de précharger les ressources, vous pouvez également indiquer au navigateur de précharger une page avant que l'utilisateur n'y accède. Cela peut entraîner des chargements de page presque instantanés, car la page et ses ressources sont extraites et traitées en arrière-plan. Lorsque l'utilisateur accède à la page, celle-ci est placée au premier plan.

Le prérendu est disponible via l'API Speculation Rules:

<script type="speculationrules">
{
  "prerender": [
    {
      "source": "list",
      "urls": ["/page-a", "page-b"]
    }
  ]
}
</script>

Démonstrations de préchargement et de prérendu

Pré-mise en cache de Service Workers

Il est également possible de précharger de manière spéculative des ressources à l'aide d'un service worker. La prémise en cache du service worker peut extraire et enregistrer des ressources à l'aide de l'API Cache, ce qui permet au navigateur de traiter la requête à l'aide de l'API Cache sans accéder au réseau. La prémise en cache des Service Workers repose sur une stratégie de mise en cache très efficace, connue sous le nom de stratégie de mise en cache uniquement sur le cache. Ce modèle est très efficace, car une fois que les ressources sont placées dans le cache du service worker, elles sont récupérées presque instantanément à la demande.

Affiche le flux de mise en cache du service worker entre la page, le service worker et le cache.
La stratégie de mise en cache uniquement ne récupère les ressources éligibles du réseau que lors de l'installation du service worker. Une fois installées, les ressources mises en cache ne sont extraites que du cache du service worker.

Pour effectuer une mise en cache préalable des ressources à l'aide d'un service worker, vous pouvez utiliser Workbox. Toutefois, si vous préférez, vous pouvez écrire votre propre code pour mettre en cache un ensemble prédéterminé de fichiers. Quelle que soit la façon dont vous décidez d'utiliser un service worker pour effectuer une mise en cache préalable des ressources, il est important de savoir que la mise en cache préalable a lieu lorsque le service worker est installé. Après l'installation, les ressources mises en pré-cache peuvent être récupérées sur toutes les pages contrôlées par le service worker sur votre site Web.

Workbox utilise un fichier manifeste de mise en cache préalable pour déterminer les ressources à mettre en cache. Un fichier manifeste de mise en cache préalable est une liste de fichiers et d'informations de gestion des versions qui sert de "source de référence" pour les ressources à mettre en cache.

[{  
    url: 'script.ffaa4455.js',
    revision: null
}, {
    url: '/index.html',
    revision: '518747aa'
}]

Le code précédent est un exemple de fichier manifeste qui comprend deux fichiers : script.ffaa4455.js et /index.html. Si une ressource contient des informations de version dans le fichier lui-même (hachage de fichier), la propriété revision peut être laissée null, car le fichier possède déjà des versions gérées (par exemple, ffaa4455 pour la ressource script.ffaa4455.js dans le code précédent). Pour les ressources sans version, une révision peut être générée au moment de la compilation.

Une fois configuré, un service worker peut être utilisé pour effectuer une mise en cache préalable des pages statiques ou de ses sous-ressources afin d'accélérer les navigations sur les pages suivantes.

workbox.precaching.precacheAndRoute([
  '/styles/product-page.ac29.css',
  '/styles/product-page.39a1.js',
]);

Par exemple, sur une fiche produit d'e-commerce, un service worker peut effectuer une mise en cache préalable du code CSS et JavaScript nécessaire à l'affichage de la page d'informations détaillées sur le produit, ce qui accélère considérablement la navigation. Dans l'exemple précédent, product-page.ac29.css et product-page.39a1.js sont mis en cache en pré-cache. La méthode precacheAndRoute disponible dans workbox-precaching enregistre automatiquement les gestionnaires nécessaires pour garantir que les ressources en pré-cache sont extraites de l'API Service Worker si nécessaire.

Étant donné que les service workers sont largement acceptés, vous pouvez utiliser la mise en cache préalable des service workers sur n'importe quel navigateur moderne lorsque la situation l'exige.

Tester vos connaissances

À quelle priorité l'indice prefetch est-il généré ?

Forte.
Réessayez.
Moyen.
Réessayez.
Faibles.
Bonne réponse !

Quelle est la différence entre le préaffichage et le préaffichage d'une page ?

Alors qu'un préchargement et un prérendu d'une page obtiennent tous deux une page et toutes ses sous-ressources, un préchargement ne récupère que la page et toutes ses ressources, tandis qu'un prérendu va plus loin en affichant la page entière en arrière-plan jusqu'à ce que l'utilisateur y accède.
Bonne réponse !
Elles sont presque identiques : seul un prérendu dispose de toutes les sous-ressources d'une page, contrairement à un préchargement.
Réessayez.

Le cache du service worker et le cache HTTP sont identiques.

Vrai
Réessayez.
Faux
Bonne réponse !

À suivre: Présentation des Web workers

Maintenant que vous savez à quel point le préchargement, le prérendu et la mise en cache par les service workers peuvent être bénéfiques pour accélérer la navigation vers les pages futures, vous êtes en mesure de prendre des décisions éclairées sur la façon dont cela peut être bénéfique pour votre site Web et ses utilisateurs.

Ensuite, une présentation des nœuds de calcul Web est fournie et explique comment ils peuvent éliminer des tâches coûteuses du thread principal et laisser au thread principal plus d'espace pour les interactions utilisateur. Si vous vous êtes déjà demandé ce que vous pouviez faire pour donner plus d'espace au thread principal, les deux prochains modules valent la peine d'être pris en compte.