Performance de chargement : defer, async, preload et prefetch

Ordonnez l'exécution de vos scripts avec defer et async, puis pilotez le réseau avec preload, preconnect et prefetch.

10 min · 3 questions

Un <script src> classique bloque le parsing du HTML : le navigateur s'arrête, télécharge, exécute, puis reprend. Deux attributs changent la donne. defer télécharge en parallèle du parsing et exécute les scripts dans l'ordre du document, juste avant DOMContentLoaded : c'est le choix par défaut pour votre code applicatif, qui peut dépendre du DOM et d'autres scripts. async télécharge aussi en parallèle mais exécute dès que le fichier arrive, sans ordre garanti : réservez-le aux scripts autonomes comme l'analytics, qui ne dépendent de rien.

HTML

<script src="/js/analytics.js" async></script>
<script src="/js/vendor.js" defer></script>
<script src="/js/app.js" defer></script>

vendor.js s'exécutera toujours avant app.js

Le navigateur ne découvre certaines ressources critiques que très tard : une police référencée dans un fichier CSS, une image chargée en JavaScript. <link rel="preload"> corrige cette découverte tardive en déclarant la ressource dès le <head>, avec l'attribut as obligatoire pour que le navigateur applique la bonne priorité et le bon cache. Cas d'école : les webfonts, sinon demandées seulement après téléchargement et analyse du CSS.

HTML

<link rel="preload" as="font" type="font/woff2"
      href="/fonts/inter-var.woff2" crossorigin>
<link rel="preload" as="image"
      href="/img/hero-1600.jpg" fetchpriority="high">

Découverte anticipée d'une police et de l'image LCP

Deux pièges. Un : les polices exigent crossorigin sur le preload même en same-origin, car elles sont toujours demandées en mode CORS ; sans lui, le navigateur télécharge le fichier deux fois. Deux : chaque preload consomme de la bande passante prioritaire ; en abuser retarde vos ressources réellement critiques. Si la console affiche « preloaded but not used », supprimez-le.

Dernière famille : les indices réseau à priorité basse. <link rel="preconnect"> établit à l'avance la connexion complète (DNS, TCP, TLS) vers une origine tierce que vous utiliserez à coup sûr : jusqu'à 300 ms gagnées sur la première requête. dns-prefetch est sa version allégée (résolution DNS seule), utile en repli pour les origines moins certaines. Et prefetch télécharge pendant les temps morts une ressource destinée à la navigation suivante : la page de paiement depuis le panier, par exemple. Le compromis est clair : preload sert la page courante, prefetch parie sur la prochaine.

HTML

<link rel="preconnect"
      href="https://api.example.com">
<link rel="dns-prefetch"
      href="https://cdn.example.com">
<link rel="prefetch" href="/checkout.html">

Connexions anticipées et pari sur la navigation suivante

Les scripts type="module" sont différés par défaut : inutile d'ajouter defer. Et pour vérifier l'effet réel de vos optimisations, ouvrez l'onglet Réseau des DevTools et observez les colonnes priorité et cascade : c'est là que se lisent les vraies files d'attente, pas dans le code source.

Quiz de validation

Vérifiez que vous avez bien retenu les points clés de cette leçon.

Quelle garantie defer offre-t-il que async n'offre pas ?
- Un téléchargement en parallèle du parsing HTML
- L'exécution dans l'ordre du document, avant DOMContentLoaded
- Une exécution avant tout rendu de la page
Pourquoi crossorigin est-il requis sur un preload de police same-origin ?
- Les polices sont toujours demandées en mode CORS ; sans lui, le fichier est téléchargé deux fois
- C'est une exigence de sécurité du format WOFF2
- Sans lui, le preload est bloqué par la CSP par défaut
Quel est le bon usage de rel="prefetch" ?
- Accélérer une ressource critique de la page courante
- Précharger à basse priorité une ressource probable de la navigation suivante
- Forcer la mise en cache permanente d'un fichier