Qu'est-ce que le chargement des ressources ?

Qu'est-ce que le chargement des ressources ?

Le chargement des ressources est la façon dont le navigateur trouve, demande, priorise et traite les fichiers dont une page a besoin : HTML, CSS, JavaScript, polices, images, vidéos et appels d'API. L'ordre et le moment de ces requêtes déterminent quand le contenu apparaît et quand la page répond. Une page est souvent lente non pas parce que ses fichiers sont énormes, mais parce qu'un fichier important commence à se télécharger trop tard.

Comment le navigateur charge les ressources

Le navigateur télécharge d'abord le HTML et découvre d'autres fichiers en le lisant : un lien de feuille de style, une balise script, une image. Certains ne sont découverts que plus tard, comme une police citée dans une feuille de style ou une image définie en arrière-plan CSS. Chaque fichier d'une nouvelle origine paie en plus la résolution DNS, la connexion et le TLS avant que le premier octet ne circule. En chemin, le navigateur attribue une priorité à chaque requête. Par défaut, les images démarrent en priorité basse et ne sont relevées que lorsque la mise en page les trouve dans la fenêtre d'affichage (web.dev, « Optimize resource loading with the Fetch Priority API »). Les feuilles de style et les scripts classiques du head peuvent retarder le premier affichage : c'est le chemin de rendu critique.

Quatre façons de l'améliorer

• Découvrir plus tôt les fichiers importants. Utilisez les resource hints : preload pour une image principale ou une police clé, preconnect pour une origine tierce que vous utiliserez à coup sûr.
• Charger plus tard ce qui n'est pas critique. Ajoutez defer ou async aux scripts (voir le chargement asynchrone) et utilisez le chargement différé (lazy loading) pour les images et iframes situées sous la ligne de flottaison.
• Relever ou abaisser la priorité. L'attribut fetchpriority (high, low, auto) fonctionne sur img, script et link. C'est une indication, pas un ordre, et il ne fait pas trouver le fichier plus tôt. Selon web.dev, il est pris en charge par Chrome et Edge 102, Firefox 132 et Safari 17.2.
• Charger moins, de plus près. Supprimez le code inutilisé, compressez les fichiers et servez-les depuis un CDN pour raccourcir chaque aller-retour. De bons en-têtes de cache évitent le téléchargement aux visites suivantes.

Exemple

Une fiche produit comporte une grande image principale, six images de galerie en dessous, un script d'analytique et un widget de chat. Chargé sans réflexion, tout démarre en même temps et l'image principale se dispute la bande passante avec le chat. Mieux vaut marquer l'image principale fetchpriority="high", mettre loading="lazy" sur la galerie, ajouter defer au script d'analytique et charger le chat une fois la page interactive.

<img src="/hero.webp" fetchpriority="high" alt="Produit">
<img src="/gallery-1.webp" loading="lazy" alt="Détail">
<script src="/analytics.js" defer></script>

web.dev rapporte un test de Google Flights où marquer l'image LCP en fetchpriority="high" a fait passer le LCP de 2,6 s à 1,9 s. C'est un seul site avec une configuration donnée : mesurez votre propre page.

Erreurs courantes

• Charger l'image principale en différé. Cela dit au navigateur d'attendre quelque chose que le visiteur voit immédiatement, et retarde le Largest Contentful Paint.
• Tout précharger. Les hints se font concurrence et, au-delà de quelques-uns, n'aident plus. Gardez-les pour les fichiers qui conditionnent le premier rendu.
• Beaucoup d'origines tierces. Chacune demande sa propre connexion et peut bloquer la page si elle est lente.
• Des scripts async qui dépendent les uns des autres. Avec async, l'ordre n'est pas garanti ; utilisez defer.
• Ignorer les visites répétées. Sans en-têtes de cache, les visiteurs qui reviennent retéléchargent tout.

Lien avec les tests et la surveillance

L'outil principal est la cascade réseau : elle montre ce qui a démarré quand, ce qui a attendu quoi et quelles requêtes ont été bloquées. Examinez-la avec une connexion bridée et depuis plusieurs lieux, car la distance change le coût de la connexion. LoadFocus Page Speed Monitoring lance des audits Google Lighthouse planifiés depuis 25 régions cloud, pour voir si un changement de chargement a aidé partout ou seulement près de votre serveur. Le vérificateur gratuit de Core Web Vitals affiche le LCP, l'INP et le CLS d'utilisateurs réels à partir des données CrUX de Google. Pour une liste plus large d'améliorations, lisez le guide en 10 étapes pour accélérer un site.

Questions fréquentes : chargement des ressources

Quelle différence entre chargement des ressources et lazy loading ?

Le chargement des ressources est tout le processus de téléchargement des fichiers d'une page. Le lazy loading est une technique à l'intérieur : il retarde des fichiers, en général des images et des iframes, jusqu'au moment où ils vont être vus.

Dans quel ordre un navigateur charge-t-il les ressources ?

Il commence par le HTML, puis demande les fichiers trouvés pendant l'analyse, chacun avec une priorité. Les fichiers cités dans le CSS, comme les polices et les images de fond, sont découverts plus tard : c'est pourquoi des hints comme preload existent.

À quoi sert fetchpriority ?

Il demande au navigateur de télécharger une ressource avec une priorité plus haute ou plus basse que d'habitude. Le navigateur peut l'ignorer, et il ne fait pas découvrir un fichier plus tôt.

Le chargement de JavaScript bloque-t-il le rendu ?

Un script classique sans async, defer ni type module bloque l'analyse du HTML pendant son téléchargement et son exécution. Avec defer ou async, ce n'est plus le cas.

Comment voir comment mes ressources se chargent ?

Ouvrez le panneau Réseau des DevTools du navigateur, ou lancez un audit Lighthouse et lisez sa cascade et sa liste de ressources bloquant le rendu.