Utilisez preload lorsqu’une ressource critique serait découverte trop tard
`preload` demande au navigateur de commencer tôt le téléchargement d’une ressource que vous savez importante pour le rendu initial. Il peut être utile pour une police nécessaire au premier écran, une image LCP découverte tardivement ou une autre ressource critique qui n’apparaît pas assez tôt dans la chaîne de découverte normale.
Ce n’est pas un accélérateur universel. Précharger trop de ressources peut créer de la concurrence pour la bande passante et ralentir ce qui compte vraiment. Le bon usage commence donc par une question : « cette ressource est-elle critique maintenant et est-elle actuellement découverte trop tard ? »
Observez d’abord quand la requête démarre sans preload
Ouvrez la chronologie réseau et repérez la ressource candidate. Si elle est déjà demandée très tôt avec une priorité adaptée, preload apporte peu de valeur. Si sa requête commence seulement après le téléchargement d’un CSS, l’exécution d’un script ou une autre dépendance, vous avez un cas plus intéressant à tester.
Notez également l’élément qui dépend de cette ressource. Une police utilisée seulement sous la ligne de flottaison n’a pas le même rôle qu’une police nécessaire au titre principal. La criticité vient de l’expérience utilisateur, pas simplement de la taille ou du type de fichier.
Pour une image critique, vérifiez d’abord sa découvrabilité dans le HTML
Une image importante peut souvent être rendue directement découvrable sans preload. Si l’image LCP est déjà un `` présent dans le document initial, le navigateur peut la détecter rapidement. Avant d’ajouter une balise supplémentaire, vérifiez donc si la structure HTML elle-même peut être améliorée.
Le preload devient plus pertinent lorsque l’image est découverte via une ressource indirecte ou trop tard dans le processus. Même dans ce cas, testez le résultat : ajouter preload et `fetchpriority` sans mesurer peut simplement déplacer la priorité au détriment d’un CSS ou d’une police également critique.
Pour les polices, tenez compte de crossorigin et du véritable usage initial
Les polices web sont un cas fréquent parce qu’elles peuvent être découvertes après le CSS. Si une police est indispensable au contenu initial et que son téléchargement démarre tard, un preload ciblé peut être envisagé. Mais précharger toutes les graisses et tous les styles transforme rapidement une optimisation en surcharge réseau.
Vérifiez les attributs nécessaires, notamment la configuration `crossorigin` selon le cas, afin d’éviter qu’un téléchargement préchargé soit inutilisable et qu’une seconde requête parte ensuite. Une ressource préchargée mais non consommée est un signal clair que la stratégie doit être revue.
Déclarez correctement le type de ressource attendu
L’attribut `as` aide le navigateur à comprendre le type de ressource et à appliquer les règles appropriées. Une mauvaise déclaration peut nuire à la priorité ou au réemploi de la réponse. Utilisez donc le type qui correspond réellement à l’image, la police, le script ou la ressource concernée.
Ne copiez pas une balise preload depuis un exemple sans adapter URL, type, format et politique cross-origin. Les erreurs de configuration peuvent entraîner des avertissements de console ou des téléchargements inutiles qui augmentent le coût de la page au lieu de réduire le délai critique.
Le principal risque est de précharger trop de ressources
Le navigateur dispose d’une bande passante et de connexions limitées. Si vous lui dites que dix ressources sont toutes prioritaires, elles peuvent se concurrencer et retarder le CSS, l’image principale ou d’autres éléments essentiels. web.dev avertit explicitement contre le préchargement excessif de ressources.
Gardez donc une liste courte et justifiée. Pour chaque preload, écrivez la raison : « cette police est nécessaire au titre initial et découverte après le CSS », ou « cette image LCP est injectée tardivement ». Si vous ne pouvez pas expliquer le bénéfice attendu, retirez le preload du test.
Testez avant et après en regardant le réseau et le rendu
Comparez le démarrage de la requête, sa priorité, le moment où la ressource est utilisée et les métriques de rendu associées. Si preload avance le téléchargement mais n’améliore pas l’affichage utile, le problème se situe peut-être ailleurs. Si une autre ressource critique devient plus lente, vous avez créé un nouvel arbitrage.
Testez également sur une connexion plus lente. Sur un réseau rapide, plusieurs préchargements peuvent sembler inoffensifs alors qu’ils se disputent fortement la bande passante sur mobile. L’objectif est de rendre la page plus robuste, pas seulement d’améliorer un test local très favorable.
Conservez uniquement les preloads dont l’effet reste démontrable
Une fois le correctif déployé, surveillez les performances réelles et vérifiez que la ressource reste critique au fil des évolutions du template. Un preload utile aujourd’hui peut devenir inutile si l’image change, si une police est supprimée ou si le rendu serveur découvre la ressource plus tôt.
Limpi peut aider à repérer les ressources et à documenter les corrections. Lancer un audit Limpi permet de contrôler la page, tandis que notre méthode privilégie les changements vérifiables. preload n’améliore pas automatiquement les Core Web Vitals et ne garantit aucun classement.
Références utilisées pour cette page
Continuer à comprendre votre visibilité
À lire ensuite