Ton navigateur est un exécutant zélé mais aveugle. Il lit ta page de haut en bas, et il découvre tes ressources dans l'ordre où il tombe dessus, pas dans l'ordre où elles comptent. L'image de héros que ton visiteur attend, s'il la rencontre tard dans le code, il la charge tard. La connexion vers le domaine qui sert ta police, il ne l'ouvre qu'au moment où il en a besoin, jamais avant. Résultat, tu perds des centaines de millisecondes non pas à télécharger, mais à découvrir trop tard ce qu'il fallait télécharger tôt.
Les indications de chargement, ce que le web appelle les resource hints, existent pour corriger ça. Ce sont de petites instructions que tu poses dans ta page pour dire au navigateur, avant qu'il ne le devine, ce qu'il faut anticiper, chercher en priorité, ou préparer pour la suite. C'est le levier le plus tactique de toute ta performance, celui qui ne change rien à ta vraie vitesse de fond mais réordonne ce qui arrive quand. Voici pourquoi le navigateur se trompe de priorité tout seul, et les quatre indications pour reprendre la main.
Le navigateur découvre tard ce qu'il fallait chercher tôt
Quand le navigateur reçoit ta page, il ne connaît pas encore la liste de ce qu'il va devoir charger. Il l'apprend en lisant, ligne après ligne. Chaque fois qu'il rencontre une image, un script, une police, il déclenche alors seulement la demande. Et pour une ressource servie par un autre domaine, il doit d'abord ouvrir une connexion, résoudre le nom, négocier le chiffrement, avant même de télécharger le premier octet. Ce coût de connexion se paie au moment de la découverte, en plein chemin critique.
Le problème, c'est que l'ordre du code n'est pas l'ordre de l'importance. Ton image de héros, celle que le LCP récompense quand elle apparaît tôt, est souvent déclarée après des scripts et des styles qui, eux, comptent moins pour la première impression. Le navigateur les traite dans l'ordre où il les voit, donc il sert d'abord l'accessoire et découvre l'essentiel ensuite. Il ne fait pas d'erreur, il fait ce que tu lui as dit sans le vouloir : suis le fil du code.
Les indications de chargement renversent ce défaut. Au lieu de laisser le navigateur découvrir tes besoins au fil de sa lecture, tu les lui annonces d'entrée. Tu lui dis quelle connexion ouvrir avant même d'en avoir besoin, quel fichier chercher tout de suite parce qu'il est critique, quelle page préparer parce que le visiteur ira probablement là ensuite. Tu ne changes pas la vitesse de ton réseau ni la puissance de sa machine, tu changes l'ordre, et l'ordre décide de ce qui apparaît en premier.
Tu connais tes priorités mieux que le navigateur, alors dis-les
Le navigateur a des heuristiques de priorité correctes en moyenne, et catastrophiques sur les cas qui comptent. En moyenne, mettre les scripts avant l'image de héros est raisonnable. Sur ta page d'accueil précise, où l'élément que le visiteur attend est justement cette image, la moyenne te dessert. Tu es le seul à savoir ce qui, sur cette page-là, décide de la première impression. Le navigateur ne le devine pas, alors dis-le lui.
C'est là que la plupart des gens font l'erreur inverse, et je veux la couper tout de suite. Indiquer une priorité à tout, c'est n'en indiquer à rien. Si tu précharges dix ressources, tu recrées exactement le désordre que tu voulais corriger, dix choses qui se disputent la tête de file. La valeur d'une indication vient de sa rareté. Tu désignes le petit nombre d'éléments qui font vraiment la première seconde, un, peut-être deux, et tu laisses le navigateur gérer le reste avec ses heuristiques, qui sont bonnes pour le tout-venant.
Cette discipline rejoint celle des tags tiers qu'on trie au lieu d'empiler. Dans les deux cas, le réflexe naïf est d'ajouter, et la vraie compétence est de hiérarchiser. Une page rapide n'est pas une page qui charge tout en priorité, c'est une page qui a choisi ce qui passe devant.
La latence de connexion retirée du chemin de Zovalide
Sur Zovalide, le gros du gain a été serveur. Un temps de réponse au 95e centile qui est passé de 32 secondes à 1,2 seconde, parce que le coupable principal était en profondeur, dans le backend. Mais une fois ce mur tombé, il restait des frottements côté navigateur, dont un classique : le temps perdu à ouvrir tardivement les connexions vers les domaines qui servaient des ressources critiques.
Le principe du correctif est exactement celui des indications de chargement. Ouvrir tôt les connexions vers les origines qui comptent, pour que le coût de la poignée de main ne se paie pas en plein chemin critique, au moment où le visiteur attend. Ce n'est pas ce qui a fait le gros du chiffre, le serveur l'avait déjà fait, mais c'est le genre de frottement résiduel qui sépare une page correcte d'une page qui répond au quart de tour. La leçon vaut au-delà de Zovalide : une fois les grosses fuites bouchées, ce qui reste à gagner est souvent une affaire d'ordre, pas de puissance.
Les quatre indications et quand chacune sert
Quatre outils, du plus large au plus ciblé. Utilise le bon, pas tous.
- preconnect, ouvrir la porte à l'avance. Quand une ressource critique vient d'un autre domaine, une police, une image servie par un CDN, un point de collecte, dis au navigateur d'ouvrir la connexion tout de suite, avant d'en avoir besoin. Le coût de résolution et de chiffrement est alors déjà payé quand la ressource est demandée. Réserve-le au petit nombre d'origines qui servent quelque chose d'important tôt.
- preload, chercher maintenant l'essentiel. Quand un fichier est indispensable à la première impression mais déclaré tard, ou découvert tard parce qu'il est appelé depuis un autre fichier, force le navigateur à le chercher tout de suite. C'est le levier typique pour la police qui bloque ton titre : tu la précharges pour qu'elle n'arrive plus en retard.
- prefetch, préparer la suite. Quand tu sais où ton visiteur ira probablement ensuite, la page suivante d'un tunnel, l'étape d'après d'un formulaire, demande au navigateur de la préparer pendant qu'il est au repos. Au clic, elle est déjà là. C'est le socle technique de la vitesse perçue par anticipation, l'attente transformée en apparition immédiate.
- fetchpriority, réordonner la file. Quand deux ressources sont chargées mais que l'une compte plus que l'autre, ajuste leur priorité relative. Monte celle de ton image de héros, baisse celle d'un visuel sous la ligne de flottaison. C'est le complément direct de servir tôt l'image que l'oeil attend, au lieu de la laisser dans la moyenne.
Le garde-fou vaut pour les quatre : mesure avant et après. Une indication mal placée peut voler la priorité à un élément plus important et empirer ta page. Ouvre l'onglet Réseau, regarde l'ordre réel de chargement et les priorités attribuées, pose une seule indication à la fois, et vérifie que l'élément qui compte est bien remonté. Une indication qui n'améliore rien de mesurable n'a rien à faire dans ta page.
Ce qu'il faut retenir
Le navigateur découvre tes ressources dans l'ordre du code, pas dans l'ordre de leur importance, et pour tout ce qui vient d'un autre domaine, il paie le coût de connexion au pire moment, en plein chemin critique. Les indications de chargement te rendent la main sur cet ordre : ouvrir tôt les connexions qui comptent avec preconnect, chercher tout de suite l'essentiel avec preload, préparer la suite avec prefetch, réordonner la file avec fetchpriority. La compétence n'est pas d'en poser partout, c'est d'en poser peu, sur les rares éléments qui font ta première seconde. Ouvre l'onglet Réseau sur ta page la plus importante, repère l'élément que ton visiteur attend, et regarde à quel rang le navigateur le charge aujourd'hui. S'il est en retard sur des accessoires, tu tiens un gain qui ne coûte ni serveur plus cher ni code réécrit, seulement le bon ordre. Si tu veux que je repère ce qui, sur ta page, se charge dans le désordre au détriment de ta conversion, c'est tout l'objet d'un diagnostic.