Web Performance

Preload, prefetch et preconnect : quand chacun aide vraiment

Les indications de ressources sont utiles lorsqu’elles correspondent à de vrais goulots d’étranglement du navigateur. Utilisées à l’aveugle, elles brouillent les priorités et peuvent parfois ralentir les pages.

The Wux Webtools Team The Wux Webtools Team 13 min de lecture Assisté par l'IA, revu par des humains
A simplified browser loading waterfall showing early resource hints for a web page.
Table des matières
  1. Les indications de ressources ne sont pas magiques
  2. Ce que le navigateur fait déjà bien
  3. Preload : pour les ressources de la page courante découvertes trop tard
  4. Preload et les images LCP
  5. Prefetch : pour la page suivante, pas celle-ci
  6. Preconnect : pour les connexions coûteuses vers des origines importantes
  7. DNS-prefetch : le cousin plus léger
  8. Comment décider : un workflow pratique
  9. 1. Identifier le goulot d’étranglement
  10. 2. Ajouter une indication à la fois
  11. 3. Vérifier les effets secondaires sur les priorités
  12. 4. Vérifier les en-têtes et la mise en cache
  13. Erreurs courantes
  14. Trop précharger
  15. Utiliser prefetch pour des ressources requises
  16. Faire preconnect vers chaque tiers
  17. Oublier les conditions mobiles
  18. Un tableau de décision simple
  19. La règle calme

Les indications de ressources ne sont pas magiques

preload, prefetch et preconnect sont souvent traités comme une liste de vérification de performance. Ajouter quelques balises dans le <head>, relancer Lighthouse, se sentir mieux. Ce n’est pas comme cela qu’ils fonctionnent.

Ces indications sont des instructions pour le pipeline de chargement du navigateur. Elles peuvent aider lorsque vous savez quelque chose que le navigateur ne peut pas découvrir assez tôt. Elles peuvent nuire lorsque vous devinez, sur-priorisez du travail non critique ou préparez des connexions dont les utilisateurs n’auront jamais besoin.

La version courte :

  • Utilisez preload pour les ressources requises par la page courante, mais découvertes trop tard.
  • Utilisez prefetch pour les ressources de navigation future probables, pas pour les éléments essentiels de la page courante.
  • Utilisez preconnect pour les origines tierces importantes lorsque l’établissement de la connexion est un vrai délai.

La question pratique n’est pas « quelle indication est la plus rapide ? ». C’est « qu’attend le navigateur, et cette indication peut-elle supprimer cette attente ? »

Ce que le navigateur fait déjà bien

Les navigateurs modernes ne sont pas de simples téléchargeurs de fichiers passifs. Ils analysent le HTML, explorent à l’avance les ressources, attribuent des priorités, réutilisent les connexions, retardent le travail qui n’est pas visible et s’adaptent aux conditions réseau.

Cela signifie que les indications de ressources doivent être sélectives. Si une feuille de style, un script, une image ou une police est déjà découvert tôt et reçoit la bonne priorité, ajouter une indication peut ne rien faire. Pire, elle peut concurrencer des ressources plus importantes.

Avant d’ajouter des indications, examinez une cascade dans DevTools ou un rapport de laboratoire. Si vous utilisez Lighthouse, commencez par les diagnostics plutôt que par le score ; nous avons un guide séparé sur la lecture d’un rapport Lighthouse sans paniquer — mais notez que l’URL correcte est sensible à la casse, utilisez donc l’article lié depuis la navigation de votre site si nécessaire.

La preuve réelle est généralement visible à trois endroits :

  1. Une ressource critique démarre tard parce que le navigateur la découvre tard.
  2. Une connexion vers une origine importante prend un temps notable avant la première requête.
  3. Une ressource de la page suivante est très prévisible et peu coûteuse à récupérer pendant les périodes d’inactivité.

Si rien de tout cela n’est vrai, une indication est probablement décorative.

Preload : pour les ressources de la page courante découvertes trop tard

preload dit au navigateur : « Récupère cette ressource maintenant, car la page courante en aura besoin. »

Un exemple typique est une police web référencée dans du CSS. Le navigateur doit télécharger le HTML, découvrir le CSS, télécharger le CSS, l’analyser, découvrir la police, puis demander la police. Si cette police est importante pour le texte au-dessus de la ligne de flottaison, sa découverte peut être assez tardive pour provoquer des décalages de mise en page ou retarder le rendu du texte.

Un preload peut avancer cette requête :

<link rel='preload' href='/fonts/inter-var.woff2' as='font' type='font/woff2' crossorigin>

L’attribut as est important. Il indique au navigateur de quel type de ressource il s’agit, ce qui affecte la priorité, la mise en cache, la politique de sécurité du contenu et les en-têtes de requête. Les polices ont aussi généralement besoin de crossorigin, même lorsqu’elles sont servies depuis le même site, car la récupération des polices utilise le mode CORS.

De bons candidats pour preload incluent :

  • La principale police web utilisée pour le texte visible.
  • Une image héro qui est l’élément Largest Contentful Paint et qui n’est pas découvrable tôt.
  • Un fichier CSS critique chargé indirectement.
  • Un module ou un script nécessaire très tôt, mais masqué derrière un autre script.

De mauvais candidats pour preload incluent :

  • Toutes les graisses de police du design system.
  • Les images sous la ligne de flottaison.
  • Les scripts qui ne sont pas nécessaires au rendu initial.
  • Les ressources que le navigateur découvre déjà dans le premier fragment HTML.

Preload est puissant parce qu’il affecte la priorité de la page courante. C’est aussi pourquoi il est facile d’en faire mauvais usage. Si vous préchargez cinq gros assets, vous n’aidez plus le navigateur. Vous vous disputez avec lui.

Les polices sont le cas classique. Précharger un fichier de police principal peut aider. Précharger six graisses et italiques aggrave généralement les choses. Si les polices sont votre goulot d’étranglement, corrigez d’abord l’ensemble de polices ; notre guide expliquant pourquoi les polices web restent le gain de performance le plus facile sur la plupart des sites couvre ce nettoyage plus en détail.

Preload et les images LCP

Précharger une image LCP peut être utile lorsque l’image n’est pas visible dans le HTML initial. Les causes courantes incluent les images d’arrière-plan CSS, les composants rendus côté client ou une logique d’image responsive qui apparaît tard.

Mais si votre image héro est déjà dans le HTML sous forme de <img> avec des srcset, sizes, dimensions et sans lazy loading raisonnables, le navigateur peut probablement la trouver rapidement. Dans ce cas, ajouter fetchpriority='high' peut être plus approprié que preload, selon la page.

Un bon test : si la requête de l’image démarre tard dans la cascade et devient l’élément LCP, envisagez preload. Si elle démarre tôt mais se télécharge lentement, le problème vient de la taille, du format, du comportement du CDN ou de la latence serveur — pas de la découverte. Pour les décisions de format d’image, consultez quand AVIF bat WebP et quand ce n’est pas le cas.

Prefetch : pour la page suivante, pas celle-ci

prefetch dit au navigateur : « Cette ressource pourrait être nécessaire bientôt, mais elle n’est pas requise maintenant. »

Cette distinction est importante. Prefetch est intentionnellement à basse priorité. Le navigateur peut la récupérer pendant les périodes d’inactivité et la stocker pour une utilisation ultérieure. Il peut aussi l’ignorer sur de mauvaises connexions, en mode économie de données ou sous pression mémoire.

Utilisez prefetch lorsque l’intention de l’utilisateur est assez forte pour rendre la ressource suivante probable.

De bons candidats pour prefetch incluent :

  • L’étape suivante d’un paiement en plusieurs pages.
  • Les résultats de recherche après qu’un utilisateur commence à saisir une requête, si la route suivante est prévisible.
  • Les pages de documentation liées depuis une table des matières lorsque l’utilisateur lit activement du contenu voisin.
  • Les chunks de route dans une single-page app après qu’un utilisateur survole ou focalise un élément de navigation.

De mauvais candidats pour prefetch incluent :

  • Toute votre arborescence de navigation.
  • De grosses vidéos ou galeries d’images.
  • Des scripts tiers « au cas où ».
  • Des pages que les utilisateurs visitent rarement ensuite.

Prefetch est l’endroit où la retenue paie. Une ressource récupérée et jamais utilisée n’est pas gratuite. Elle consomme de la bande passante, de la capacité serveur, de l’énergie et peut-être les données de l’utilisateur. Sur les réseaux mobiles, la récupération spéculative peut être franchement peu amicale.

Pour de nombreux sites, la meilleure stratégie de prefetch est basée sur l’intention. Ne préchargez pas la page des tarifs dès que la page d’accueil se charge. Préchargez-la lorsque l’utilisateur ouvre le menu des tarifs, survole le lien des tarifs ou fait défiler jusqu’à proximité d’un call-to-action qui prédit fortement une navigation.

Rappelez-vous aussi que le comportement varie selon les navigateurs. Certains navigateurs sont conservateurs avec prefetch ; certains réglages de confidentialité réduisent ou désactivent le chargement spéculatif. Traitez prefetch comme une amélioration opportuniste, pas comme un mécanisme de fiabilité.

Preconnect : pour les connexions coûteuses vers des origines importantes

preconnect dit au navigateur : « Commence à établir une connexion vers cette origine maintenant. »

Cela peut inclure la résolution DNS, la connexion TCP et la négociation TLS. Pour les origines tierces, cette configuration peut prendre des centaines de millisecondes, surtout sur des réseaux à forte latence. Si la page a bientôt besoin d’une requête critique depuis cette origine, preconnect peut accélérer la requête ultérieure.

Exemple :

<link rel='preconnect' href='https://fonts.gstatic.com' crossorigin>

De bons candidats pour preconnect incluent :

  • Une origine de polices utilisée pour du texte bloquant le rendu.
  • Une origine d’API critique nécessaire pendant l’interaction initiale.
  • Une origine CDN servant des assets au-dessus de la ligne de flottaison.
  • Un fournisseur de paiement ou d’identité nécessaire immédiatement après une action utilisateur.

De mauvais candidats pour preconnect incluent :

  • Les points de terminaison d’analytics et de publicité qui ne sont pas critiques pour l’utilisateur.
  • Les origines utilisées seulement dans certaines sessions.
  • De longues listes de tiers.
  • Les ressources de même origine, pour lesquelles le navigateur possède déjà ou ouvrira bientôt la connexion.

Preconnect a un coût de maintien. Les sockets ouvertes consomment de la mémoire et des ressources réseau. Les navigateurs fermeront les connexions inutilisées, mais cela ne rend pas les preconnect inutiles inoffensifs.

Une règle utile : faites preconnect vers au plus une ou deux origines tierces à forte confiance sur une page. Si vous êtes tenté d’en ajouter davantage, votre architecture tierce a probablement davantage besoin d’être revue que vos indications d’être étendues.

DNS-prefetch : le cousin plus léger

Vous pouvez aussi voir dns-prefetch :

<link rel='dns-prefetch' href='https://example-cdn.com'>

Cela résout uniquement le nom de domaine. Cela n’ouvre pas de connexion TCP ou TLS. C’est moins coûteux que preconnect, mais aussi moins utile.

DNS-prefetch peut être raisonnable pour des origines tierces moins certaines, lorsque preconnect complet semble trop agressif. En pratique, si une origine est critique et sera certainement utilisée bientôt, préférez preconnect. Si elle est seulement possible, utilisez DNS-prefetch ou ne faites rien.

Comment décider : un workflow pratique

Commencez par la mesure, pas par les balises.

1. Identifier le goulot d’étranglement

Ouvrez une trace de performance et cherchez les découvertes tardives. La requête de police, d’image héro ou de script a-t-elle démarré seulement après qu’un autre fichier a été téléchargé et analysé ? C’est un candidat pour preload.

Si une requête démarre seulement après une longue configuration DNS/TCP/TLS vers une origine tierce, c’est un candidat pour preconnect.

Si la page courante va bien mais que la navigation suivante est prévisiblement lente, prefetch peut aider.

2. Ajouter une indication à la fois

Les indications de ressources interagissent. Ajoutez-en une, testez-la et ne la conservez que si la cascade s’améliore et si les métriques visibles par l’utilisateur ne régressent pas.

Pour preload, vérifiez si la ressource indiquée est réellement utilisée rapidement. Chrome peut avertir lorsqu’une ressource préchargée n’est pas utilisée peu après le chargement. Prenez cet avertissement au sérieux.

3. Vérifier les effets secondaires sur les priorités

Un preload peut détourner de la bande passante du CSS, du JavaScript ou d’images plus importants. Un preconnect peut occuper un emplacement de connexion. Un prefetch peut ajouter du trafic en arrière-plan.

Le bon résultat n’est pas « le fichier indiqué démarre plus tôt ». Le bon résultat est « la page devient significativement meilleure pour les utilisateurs ». Examinez LCP, INP, CLS et, lorsque possible, la supervision des utilisateurs réels.

4. Vérifier les en-têtes et la mise en cache

Les indications peuvent être envoyées dans le HTML ou dans des en-têtes HTTP Link. Les en-têtes sont utiles lorsque le serveur sait tôt ce dont la page aura besoin, mais ils sont plus difficiles à inspecter rapidement. Si vous déboguez la présence réelle d’une indication en production, les en-têtes bruts comptent ; c’est exactement le type de situation couvert dans notre guide de débogage des redirections et des en-têtes HTTP.

La mise en cache compte aussi. Précharger une ressource avec des credentials incompatibles, un mauvais as ou des paramètres d’URL différents peut provoquer des téléchargements en double. C’est l’une des façons les plus courantes dont un preload bien intentionné devient un bug de performance.

Erreurs courantes

Trop précharger

Si tout est critique, rien ne l’est. Limitez preload aux ressources nécessaires au rendu initial ou à l’interactivité immédiate. Une page typique devrait avoir zéro à trois preloads, pas vingt.

Utiliser prefetch pour des ressources requises

Prefetch est à basse priorité et optionnel. Ne l’utilisez pas pour les assets requis par la page courante. Si la page en a besoin maintenant, envisagez preload ou la découverte HTML normale.

Faire preconnect vers chaque tiers

Les pages chargées en tiers ont souvent dix origines externes ou plus. Faire preconnect vers chacune crée du bruit. Choisissez celle ou les deux qui sont à la fois critiques et prévisiblement utilisées.

Oublier les conditions mobiles

Les indications de ressources sont plus précieuses sur les connexions lentes, mais aussi plus dangereuses dans ces conditions. Un prefetch gaspillé sur une connexion desktop rapide est une erreur d’arrondi. Sur un forfait mobile contraint, c’est un mauvais compromis.

Un tableau de décision simple

| Situation | Meilleure indication | Pourquoi | |---|---:|---| | Police critique découverte via CSS | preload | La page courante en a besoin, la découverte est tardive | | Image héro cachée derrière du CSS ou du rendu client | preload | Peut améliorer LCP si l’image démarre tard | | Route suivante probable après intention utilisateur | prefetch | Aide la navigation future sans bloquer la page courante | | Origine tierce critique pour police/API | preconnect | Retire l’établissement de connexion du chemin critique | | Origine tierce possible mais incertaine | dns-prefetch ou aucune | Coût plus faible, confiance plus faible | | Image sous la ligne de flottaison | aucune | Laissez le lazy loading et la priorité du navigateur fonctionner |

La règle calme

Les indications de ressources fonctionnent mieux lorsqu’elles sont ennuyeuses et spécifiques. Une police. Une image LCP. Une origine tierce importante. Une prochaine route probable après intention.

Elles fonctionnent mal lorsqu’elles sont utilisées comme de l’optimisme : peut-être que l’utilisateur aura besoin de ceci, peut-être que le navigateur devrait récupérer cela, peut-être que plus d’indications signifie plus de vitesse.

Les navigateurs optimisent déjà agressivement. Votre rôle n’est pas de microgérer chaque requête. Votre rôle est de corriger les quelques cas où le navigateur manque d’information au bon moment.

Questions fréquemment posées

Devrais-je précharger toutes mes polices ?
Non. Préchargez uniquement les fichiers de police nécessaires au texte visible tôt dans la page. Précharger chaque graisse et chaque style gaspille généralement de la bande passante et peut retarder des ressources plus importantes.
Prefetch est-il sûr à utiliser pour chaque lien interne ?
Généralement non. Il peut créer du trafic de fond inutile et gaspiller les données utilisateur. Préférez un prefetch basé sur l’intention, par exemple après un survol, un focus, l’ouverture d’un menu ou une étape suivante prévisible.
Quelle est la différence entre preconnect et dns-prefetch ?
Preconnect effectue la configuration DNS, TCP et TLS pour une origine. DNS-prefetch résout uniquement le nom de domaine. Preconnect est plus puissant mais plus coûteux, il doit donc être utilisé avec davantage de confiance.
Les indications de ressources peuvent-elles améliorer les Core Web Vitals ?
Oui, surtout LCP, lorsqu’elles corrigent une découverte tardive ou l’établissement de connexion pour une ressource critique. Elles n’aideront pas si le vrai problème est lié à des assets surdimensionnés, une réponse serveur lente, du code bloquant le rendu ou une mauvaise mise en cache.
Les indications de ressources doivent-elles être ajoutées dans le HTML ou dans les en-têtes HTTP ?
Les deux peuvent fonctionner. Le HTML est plus facile à raisonner pour les indications propres à une page. Les en-têtes HTTP Link peuvent être utiles lorsque le serveur connaît les ressources critiques avant que le HTML soit analysé, mais ils nécessitent des tests soigneux pour éviter les doublons ou les indications obsolètes.

Sources et lectures complémentaires

  1. MDN: rel=preload
  2. MDN: Resource hints
  3. web.dev: Preconnect and DNS-prefetch
  4. W3C: Resource Hints
#performance #resource-hints #html #browser #optimization
À propos de l'auteur
The Wux Webtools Team

Dernière mise à jour:

Continuez à lire