Le préchargement de ressources : quand il aide, quand il nuit

Parmi les optimisations que l'on recommande volontiers, le préchargement occupe une place à part : il est facile à mettre en place, son effet est immédiatement visible dans les outils, et il produit une dégradation nette lorsqu'il est mal employé. La raison tient à sa nature même. Précharger ne rend pas le réseau plus rapide, cela indique simplement au navigateur qu'une ressource compte plus que les autres. Ce qui gagne en priorité en fait perdre à quelque chose d'autre, et sur une page qui déclare huit préchargements, plus rien n'est prioritaire. Nous détaillons ici le mécanisme, les situations où la déclaration produit un gain réel, celles où elle nuit, et la façon de vérifier le résultat plutôt que de le supposer.

Ce que fait réellement une déclaration de préchargement

Le navigateur découvre les ressources d'une page au fil de sa lecture, et cet ordre de découverte détermine l'ordre de téléchargement. Les différentes déclarations disponibles pour influencer ce comportement sont présentées dans notre article sur les directives preload et preconnect pour le chargement des ressources.

Le problème de la découverte tardive

Certaines ressources ne sont découvertes qu'après le téléchargement et l'analyse d'une autre. Une police déclarée dans une feuille de style n'est connue qu'après l'arrivée de cette feuille, soit plusieurs centaines de millisecondes après le début du chargement. Une image de fond déclarée en style suit le même parcours. Une ressource appelée par un script n'est découverte qu'après l'exécution de ce script. Cette découverte en cascade constitue le vrai problème que le préchargement résout. Il permet au navigateur de démarrer le téléchargement sans attendre l'étape intermédiaire.

Le mécanisme de priorité

Le navigateur attribue à chaque ressource un niveau de priorité qui détermine l'ordre d'utilisation de la bande passante disponible. Une déclaration de préchargement élève ce niveau, ce qui place la ressource devant les autres dans la file. La bande passante totale n'augmente pas, elle est simplement répartie différemment. Sur une connexion mobile où plusieurs ressources se disputent quelques mégabits, cette redistribution a un effet mesurable. Elle est donc à somme nulle : ce que gagne l'une, une autre le perd. Cette évidence explique tous les échecs du préchargement mal employé.

La différence avec les autres directives

Une directive voisine se contente d'établir la connexion vers un domaine sans télécharger quoi que ce soit, ce qui économise la résolution de nom et la négociation de sécurité. Elle coûte beaucoup moins cher et elle convient parfaitement aux domaines externes dont on ignore le contenu exact. Une troisième directive suggère un téléchargement de faible priorité pour une navigation future, ce qui relève d'un autre besoin. Confondre ces trois mécanismes conduit à des configurations incohérentes. Choisir celui qui correspond au problème constaté demande de savoir ce que l'on cherche à corriger. Cette clarté préalable évite l'essentiel des erreurs.

L'obligation d'utiliser la ressource

Une ressource préchargée mais jamais employée est téléchargée pour rien, ce qui consomme de la bande passante au détriment du reste. Le navigateur signale d'ailleurs cette situation dans sa console par un avertissement explicite. Cette erreur survient fréquemment après une refonte, la déclaration restant en place alors que la ressource a changé de nom. Un contrôle de la console sur chaque gabarit détecte le problème en quelques secondes. Il mérite d'être fait périodiquement. Ces déclarations orphelines s'accumulent avec le temps.

Le rôle du type déclaré

La déclaration doit indiquer la nature de la ressource, faute de quoi le navigateur ne peut lui attribuer la bonne priorité ni la placer dans le bon cache. Une police déclarée sans son type sera téléchargée deux fois, une fois par le préchargement et une fois par la feuille de style. Cette erreur double le coût au lieu de le réduire, résultat exactement contraire à l'intention. Le cas des polices impose en outre une mention supplémentaire liée à leur mode de chargement. Ces détails de syntaxe ne sont pas facultatifs. Ils font la différence entre un gain et une perte.

La limite du nombre de déclarations

Une page qui précharge deux ressources donne à ces deux ressources un avantage réel. Une page qui en précharge dix ne fait que reproduire l'ordre normal avec un surcoût de traitement. Le nombre utile se situe entre un et trois sur la grande majorité des pages. Cette règle est simple, elle est constamment violée, et son respect suffit à corriger la plupart des configurations défaillantes. Chaque ajout doit être justifié par une mesure. La discipline compte ici davantage que la technique.

Les cas où le préchargement apporte un gain

Quelques situations précises produisent un bénéfice net et elles se reconnaissent facilement.

L'image principale de la page

L'élément le plus grand affiché dans la zone visible détermine la mesure d'affichage du contenu principal, et il s'agit très souvent d'une image. Lorsque cette image est déclarée en style plutôt qu'en balise, sa découverte est tardive et le préchargement produit un gain de plusieurs centaines de millisecondes. Les causes habituelles de dégradation de cette mesure sont détaillées dans notre article sur le problème de LCP et ses origines. Une image déclarée normalement en balise, en haut du document, n'a en revanche pas besoin d'être préchargée. Distinguer les deux cas évite une déclaration inutile. L'observation dans l'onglet réseau tranche immédiatement.

Les polices du texte principal

Une police est découverte après la feuille de style, ce qui retarde son arrivée et provoque un affichage en police de repli puis un remplacement. Précharger la ou les deux variantes utilisées dans la zone visible réduit sensiblement cette fenêtre. Les techniques complémentaires, notamment la réduction du poids des fichiers, sont exposées dans notre article sur les polices auto-hébergées et leur préchargement. Précharger cinq variantes, dont trois n'apparaissent qu'en bas de page, produit l'effet inverse. La sélection doit porter exclusivement sur ce qui s'affiche immédiatement. Deux déclarations constituent un maximum raisonnable.

La feuille de style critique

Sur une architecture où les styles sont découpés en plusieurs fichiers, celui qui gouverne l'affichage de la zone visible mérite une priorité maximale. Le préchargement s'applique bien à ce cas, particulièrement lorsque le fichier est appelé par un import depuis une autre feuille. Cette configuration en cascade est fréquente et coûteuse. La corriger en supprimant l'import vaut mieux que de la compenser par un préchargement. Lorsque la suppression n'est pas possible, la déclaration limite les dégâts. C'est un exemple de correction qui traite le symptôme faute de pouvoir traiter la cause.

Les ressources appelées par script

Une police, une image ou un fichier de données chargé par un programme n'est découvert qu'après l'exécution de ce programme. Le préchargement permet de lancer le téléchargement en parallèle, ce qui économise le temps d'exécution du script. Cette situation se rencontre sur les interfaces construites côté navigateur, où le fichier de données conditionne tout l'affichage. Le gain peut atteindre une seconde sur une connexion moyenne. C'est probablement le cas où le préchargement apporte le plus. Il suppose de connaître à l'avance l'adresse de la ressource.

La connexion aux domaines externes

Pour les ressources hébergées ailleurs, établir la connexion à l'avance produit un gain sans consommer de bande passante. Cette directive légère convient parfaitement aux services de paiement, aux outils de mesure et aux lecteurs vidéo. Elle doit rester limitée à trois ou quatre domaines, chaque connexion ouverte consommant des ressources. Elle constitue souvent une meilleure réponse que le préchargement complet pour les tiers. Elle ne présente presque aucun risque de dégradation. Elle est également plus simple à maintenir.

La page suivante probable

Sur un parcours dont l'étape suivante est prévisible, un tunnel de commande par exemple, une directive de plus faible priorité permet de préparer la page suivante pendant que le visiteur lit la page courante. Cette technique donne une impression de navigation instantanée. Elle ne doit être employée que lorsque la probabilité de la navigation est élevée, faute de quoi elle gaspille des données. Sur un forfait mobile limité, ce gaspillage n'est pas anodin. Elle relève d'un usage avancé qui mérite d'être mesuré. Son effet perçu est néanmoins spectaculaire lorsqu'elle est bien ciblée.

Les cas où le préchargement nuit

La dégradation est réelle et elle passe souvent inaperçue, faute d'avoir mesuré avant et après.

Trop de déclarations

Au delà de trois ou quatre préchargements, l'effet de priorité disparaît et la page se charge comme si aucune déclaration n'existait, avec un surcoût de traitement. Cette situation se produit quand chaque intervenant ajoute la sienne sans concertation. Le symptôme est un temps d'affichage stable malgré des optimisations successives. Le remède consiste à tout retirer, puis à réintroduire une déclaration à la fois en mesurant. Cette remise à zéro est souvent la seule façon de sortir d'une configuration accumulée. Elle prend une heure et elle clarifie durablement la situation.

Précharger ce que le navigateur trouve déjà

Une image déclarée en balise dans les premières lignes du document est découverte immédiatement et reçoit déjà une priorité élevée. La précharger n'apporte rien et consomme une place dans le budget de priorité. Cette erreur est fréquente car la déclaration paraît toujours bénéfique. Le contrôle consiste à comparer l'ordre de téléchargement avec et sans la déclaration. Un ordre identique signale une déclaration superflue. Elle doit alors être retirée plutôt que conservée par précaution.

Précharger des ressources hors écran

Une image située en bas de page, un script d'un module rarement utilisé ou une police d'un pied de page ne doivent jamais être préchargés. Leur donner la priorité retarde ce que le visiteur voit immédiatement. Cette erreur produit une dégradation nette de la mesure d'affichage principal. Elle survient lorsqu'on précharge par famille de ressources plutôt que par usage. La question à se poser est toujours la même : cette ressource est-elle nécessaire à ce que le visiteur voit dans la première seconde. Une réponse négative interdit la déclaration.

Précharger sur toutes les pages

Une déclaration placée dans l'en-tête commun s'applique à l'ensemble du site, y compris aux pages où la ressource n'est pas utilisée. Le navigateur télécharge alors un fichier inutile sur chaque page concernée. Cette configuration est extrêmement courante, la déclaration ayant été ajoutée pour la page d'accueil puis oubliée. Le préchargement doit être conditionné au gabarit, ce qui demande quelques lignes de logique. Cette conditionnalité est le principal facteur de qualité d'une configuration. Elle distingue une optimisation réfléchie d'un réglage global appliqué au hasard.

Précharger des tiers volumineux

Donner la priorité au script d'un outil de mesure ou d'une publicité revient à retarder le contenu au profit d'un élément qui n'intéresse pas le visiteur. Cette configuration se rencontre lorsque le fournisseur du service recommande le préchargement dans sa documentation. Cette recommandation sert son intérêt et non celui du site. Une connexion anticipée constitue la réponse appropriée pour ces ressources. Le préchargement complet doit leur être refusé. Cette distinction demande parfois d'argumenter face à un prestataire.

Oublier de retirer après refonte

Les déclarations survivent aux refontes alors que les ressources changent de nom ou disparaissent. Le navigateur télécharge alors des fichiers inexistants ou inutilisés, ce qu'il signale dans sa console. Ce nettoyage doit figurer dans la liste des vérifications de toute refonte. Il prend deux minutes et il est presque toujours oublié. Le contrôle de la console sur trois gabarits représentatifs suffit. Cette habitude évite l'accumulation de déclarations mortes.

Méthode de mise en place et de contrôle

La démarche efficace tient en quelques étapes et elle repose entièrement sur la mesure.

Identifier l'élément qui détermine l'affichage

Les outils d'audit indiquent précisément quel élément constitue le plus grand contenu affiché dans la zone visible. Cette information est le point de départ obligatoire de toute optimisation de ce type. Elle varie selon les gabarits, ce qui impose de la relever pour chacun. Un titre en texte n'a besoin que de sa police, une image de couverture appelle un traitement différent. Cette identification prend cinq minutes par gabarit. Elle évite d'optimiser un élément qui ne compte pas.

Observer la file de téléchargement

La vue en cascade de l'onglet réseau montre l'ordre et le moment de chaque téléchargement, ainsi que les temps d'attente. Repérer une ressource critique qui démarre tardivement identifie une candidate au préchargement. Cette lecture doit se faire avec un ralentissement de connexion activé, faute de quoi tout paraît instantané. Elle demande un peu d'habitude et elle devient rapide. Elle constitue la compétence de base pour ce type de travail. Aucun outil automatique ne la remplace complètement.

Ajouter une déclaration à la fois

Chaque ajout doit être suivi d'une mesure comparative, sur la même page et dans les mêmes conditions. Ajouter trois déclarations simultanément empêche de savoir laquelle produit un effet et laquelle en annule un autre. Cette progression paraît lente et elle est la seule qui produise un résultat maîtrisé. Trois mesures suffisent généralement à converger. Le temps investi se récupère en évitant les configurations accumulées. Il produit également une compréhension durable du comportement de la page.

Mesurer sur des conditions réalistes

Une mesure effectuée sur une connexion filaire depuis un ordinateur récent ne révèle jamais l'effet d'un préchargement. Le ralentissement de la connexion et du processeur doit être activé, avec des valeurs représentatives du public réel. Répéter la mesure trois fois et retenir la médiane évite les conclusions tirées d'un essai aberrant. Cette discipline de mesure vaut pour toute optimisation de performance. Elle demande quelques minutes de plus par essai. Elle évite des heures passées à optimiser dans le vide.

Vérifier la console après chaque changement

Les avertissements du navigateur signalent les ressources préchargées non utilisées, les types manquants et les doubles téléchargements. Cette vérification coûte quelques secondes et détecte les erreurs de syntaxe les plus courantes. Une console sans avertissement constitue le premier critère de validation. Elle ne garantit pas le gain, elle garantit l'absence d'erreur grossière. Ce contrôle doit être systématique. Il évite de publier une configuration qui dégrade la page.

Documenter chaque déclaration

Chaque préchargement conservé doit être accompagné d'un commentaire indiquant la ressource visée, le gabarit concerné et le gain mesuré. Sans cette trace, personne n'osera retirer la déclaration lors d'une refonte future, et elle sera reconduite indéfiniment. Ce commentaire tient en une ligne et il change la maintenabilité de la configuration. Il permet également de rejouer la mesure pour vérifier que le gain existe toujours. Les conditions évoluent, une déclaration bénéfique il y a deux ans pouvant être devenue inutile. Cette revue périodique demande un quart d'heure par an. Ce quart d'heure se planifie au même moment que la revue annuelle des performances, faute de quoi il ne sera jamais pris et les déclarations s'accumuleront sans que personne n'ose en retirer une.