preload demande au navigateur de télécharger tout de suite une ressource précise dont la page actuelle aura besoin, avant qu’il ne la découvre dans le CSS ou le JavaScript. Ce n’est pas une connexion anticipée vers un domaine : ça, c’est preconnect, traité dans préconnexion aux domaines externes. Un preload de trop vole de la bande passante à l’image ou à la feuille qui affiche vraiment la page.
La balise, et l’attribut as
``html
<link rel="preload" href="/fonts/texte.woff2" as="font" type="font/woff2" crossorigin>
<link rel="preload" href="/img/hero-1200.jpg" as="image" fetchpriority="high">
``
as est obligatoire pour que le navigateur classe la requête : font, image, style, script ou fetch. Sans lui, vous téléchargez un fichier que le navigateur peut refuser de réutiliser, et vous le téléchargez une seconde fois.
Pour une police, crossorigin est requis même si le fichier est sur votre domaine. Les polices sont toujours demandées en mode CORS. Un preload sans crossorigin n’est pas réutilisé : la police part deux fois, et le gain disparaît.
type évite de précharger un format que le navigateur ne sait pas lire (font/woff2).
Le seul cas qui paie presque toujours : l’élément LCP
L’image la plus grande au-dessus de la ligne de flottaison (LCP) est souvent découverte tard : elle est dans une feuille CSS en background-image, ou le navigateur ne la voit qu’après avoir lu beaucoup de HTML. Un preload as="image" sur cette URL, et pas sur la galerie, l’avance dans la cascade.
Si l’image est responsive, préchargez le même fichier que celui que le navigateur choisira, avec imagesrcset et imagesizes. Précharger le JPEG bureau de 2500 pixels sur un mobile télécharge la mauvaise ressource : vous empirez le LCP que vous vouliez aider. Le cadre LCP est dans Core Web Vitals.
Ne mettez pas loading="lazy" sur cette image. Le lazy-load et le preload se contredisent. Le lazy-load reste adapté aux images basses, comme décrit dans lazy-loading des images.
Les polices du texte visible viennent en second : un ou deux fichiers woff2 réellement utilisés au premier écran, pas les graisses italiques du pied de page.
Ce qu’il ne faut pas précharger
- Tout le CSS du site « pour aller plus vite » : le preload entre en concurrence avec lui-même.
- Un script tiers dont vous n’êtes pas sûr qu’il s’exécute (bannière de consentement qui le bloque).
- Les images sous la ligne de flottaison, les vidéos, les PDF.
- Une ressource déjà dans le HTML tout en haut, avec une priorité haute : le preload n’apporte rien, il duplique la découverte.
modulepreload concerne les modules JavaScript, pas une image. prefetch télécharge pour une navigation future, au ralenti, quand le réseau est libre. Ce n’est pas un outil pour le LCP de la page en cours.
Vérifier que le preload est utilisé
- Ouvrez la page en navigation privée, outils de développement, onglet Réseau.
- Rechargez. La ressource preload doit apparaître tôt, une seule fois.
- Dans la console, cherchez l’avertissement du type « preloaded but not used ». S’il est là, supprimez la balise.
- Comparez le film du chargement (Lighthouse ou WebPageTest) avant et après, sur la même URL, le cache ignoré. Vous regardez l’instant où l’image LCP ou le texte s’affiche, pas un score global isolé.
Si la police préchargée n’est appliquée qu’après un JavaScript qui construit la page, le fichier arrive tôt et attend. Dans ce cas, réduisez le JavaScript plutôt que d’ajouter un second preload.
Posez le preload dans le <head>, côté serveur ou dans le thème, pas via un plugin qui l’injecte après coup dans le pied de page : trop tard, la ressource critique est déjà découverte autrement, ou pas encore.
Un preload utile tient en une ou deux balises, relues quand le modèle de page change. Le mois suivant, l’image hero a souvent une autre URL : l’ancienne balise précharge alors un fichier mort.