Preload, prefetch, preconnect : les différences expliquées

Preload, prefetch, preconnect : de quoi parle-t-on ?

Ouvrez une page : le navigateur lit son HTML de haut en bas et découvre les fichiers à charger au fil de la lecture (feuilles de style, scripts, images, polices). Résultat ? Certains fichiers essentiels arrivent tard, parce qu'ils dorment au fond d'un CSS ou d'un script. Les indices de chargement, ou resource hints en anglais, existent pour rattraper ce retard.

Dans la pratique, tout passe par une balise link placée dans le head. L'attribut link rel fixe le type d'indice : preload, prefetch, preconnect ou dns-prefetch. Avec href, on donne l'adresse du fichier ou du serveur visé. Le navigateur dispose ainsi d'une consigne claire avant même d'avoir parcouru le reste du code.

La vitesse ressentie en dépend directement, et donc vos Core Web Vitals, ces indicateurs que Google surveille pour juger l'expérience qu'offre une page. Côté dirigeant, le calcul est vite fait. Une page rapide garde ses visiteurs. Celle qui rame les perd, et convertit moins.

Les quatre indices à connaître

• preload : récupérer immédiatement, en priorité haute, une ressource de la page affichée.
• prefetch : télécharger plus tard, sans urgence, une ressource de la prochaine page.
• preconnect : ouvrir toute la connexion vers un domaine tiers.
• dns-prefetch : se contenter de résoudre le nom de domaine, version allégée du preconnect.

Preload : charger tout de suite ce qui compte

Tout se joue sur la page affichée. Avec un preload, vous dites au navigateur : ce fichier compte, va le chercher maintenant. La ressource passe alors devant les autres au lieu d'attendre qu'il tombe dessus par lui-même. Le gain est bien réel pour un fichier dont la page se sert à coup sûr dans les premières secondes.

Comment l'écrire

Une ligne suffit. Voici un example de link tag pour une police : <link rel='preload' href='/fonts/inter.woff2' as='font' type='font/woff2' crossorigin>. La plupart des documentations l'écrivent avec des guillemets doubles, sous la forme rel=« preload » href. En HTML, les deux syntaxes sont valides.

Ne zappez surtout pas l'attribut as : il indique le type de fichier (font, style, script, image). Sans lui, le navigateur ne sait pas quelle priorité appliquer, et il risque de télécharger la ressource deux fois ! Pour les fonts, crossorigin est requis lui aussi, même quand la police est hébergée chez vous.

Les cas d'usage typiques

C'est sur les polices de caractères que le preload brille vraiment : comme elles sont appelées depuis le CSS, le navigateur les repère souvent tard. Il rend aussi service pour l'image principale, celle qui occupe tout le haut de l'écran. Pour elle, je préfère d'ailleurs fetchpriority='high', plus fin : l'attribut relève la priority de l'image sans ajouter de balise.

Preload : l'essentiel

• Usage : ressource critique de la page affichée, polices et image principale en tête.
• Prise en main : une seule ligne, à condition de régler juste as et crossorigin.
• Limites : chaque fichier préchargé freine les autres ; deux ou trois ressources, pas davantage.
• Pour qui : tout site dont l'affichage attend une police ou une grande image.

Prefetch : préparer la page suivante

Ici, on regarde vers l'avenir. Pas la page actuelle, donc, mais celle que l'utilisateur ouvrira probablement ensuite. Le téléchargement se fait en priorité basse, quand le navigateur n'a rien de plus urgent sur le feu. Une fois récupéré, le fichier attend dans le cache du navigateur, prêt pour la next page.

Comment l'écrire

Même logique côté syntaxe : <link rel='prefetch' href='/tarifs/'>. Les guides anglophones affichent souvent la forme link rel=« prefetch », suivie de prefetch » href puis de l'adresse. Une page HTML entière, un script, une feuille de style utilisée plus loin dans le parcours : tout peut être ciblé.

Attention, ce n'est qu'une suggestion. Connexion lente, mode économie de données activé… le navigateur a le droit de l'ignorer, et le support change d'un navigateur à l'autre. Ne bâtissez donc jamais une fonctionnalité qui en dépend.

Les cas d'usage typiques

Son intérêt saute aux yeux quand le parcours est prévisible. Sur une landing page, la suite logique, c'est souvent le formulaire ou le paiement. Et dans un tunnel de commande ? L'étape 2 suit presque toujours l'étape 1. Préchargez-la, et le clic suivant devient quasi instantané.

Prefetch : l'essentiel

• Usage : page ou fichier de la navigation suivante, sur un parcours prévisible.
• Prise en main : simple, une ligne par ressource.
• Limites : priorité low, le navigateur peut passer outre, et les données partent pour rien si l'utilisateur va ailleurs.
• Pour qui : sites au tunnel clair (e-commerce, prise de rendez-vous, inscription).

Preconnect : ouvrir la connexion avant la requête

Aucun fichier téléchargé ici : le preconnect prépare la route. Pour récupérer quoi que ce soit sur un autre serveur, le navigateur doit d'abord trouver son adresse via le DNS, puis établir la connexion et la sécuriser en HTTPS. Tout cela prend du temps, surtout sur mobile. Le preconnect déclenche ces étapes en avance.

Comment l'écrire

Forme courante : <link rel='preconnect' href='https://cdn.example.com' crossorigin>. La cible n'est pas un fichier mais un domaine, comme example.com ou le sous-domaine d'un service tiers. Là encore, crossorigin a son importance : les polices et certaines requêtes fetch empruntent une connexion distincte, qu'on n'ouvre qu'avec cet attribut.

Dns-prefetch, le petit frère

Lui se limite à la première étape, trouver l'adresse du serveur. Sa syntaxe : <link rel='dns-prefetch' href='https://cdn.example.com'>. Très peu coûteux, il convient bien aux domaines sollicités plus bas dans la page. Vous croiserez souvent rel=« dns » posé à côté du preconnect, comme solution de repli pour les vieux navigateurs.

Les cas d'usage typiques

Votre page dépend d'un domaine externe ? Pensez preconnect : un CDN, un service de polices, une vidéo intégrée, un module de paiement. Réservez-le toutefois aux domaines appelés en tout début de page. Une connexion ouverte pour rien se referme au bout de quelques secondes, et le travail part à la poubelle.

Preconnect : l'essentiel

• Usage : domaine tiers sollicité tôt dans la page (CDN, polices, paiement).
• Prise en main : une ligne par domaine, avec crossorigin si besoin.
• Limites : chaque connexion mobilise des ressources ; quelques domaines clés suffisent.
• Pour qui : sites qui affichent des contenus hébergés ailleurs que sur leur propre serveur.

Lequel choisir selon votre cas

Ne les voyez pas comme des rivaux. Chacun répond à sa propre question, et un site bien réglé en combine souvent plusieurs. Plutôt que de chercher le meilleur, demandez-vous à quel moment la ressource sert. Maintenant, sur cette page ? Preload. Plus tard, ailleurs ? Prefetch.

• Votre police s'affiche en retard ou clignote : preload sur le fichier de police.
• La grande image d'accueil traîne : fetchpriority='high' ou preload sur cette image.
• Un CDN ou un service tiers est appelé dès le haut de page : preconnect vers ce domaine.
• Un outil tiers se charge plus bas dans la page : dns-prefetch suffit.
• Le parcours mène presque toujours à la même page : prefetch vers elle.

Mon conseil, valable pour les trois : mesurez avant, mesurez après. Mal placé, un indice ralentit la page au lieu de l'accélérer, car il vole de la bande passante aux fichiers vraiment urgents. Et ces réglages ne remplacent pas les autres chantiers (réduction du render blocking, lazy loading des images) : ils les complètent.

Vous êtes sur WordPress ? Certaines extensions de performance proposent ces réglages sans toucher au code. Sur un site développé spécifiquement, tout se place dans le gabarit HTML. Et si votre projet démarre à peine, intégrez ces optimisations dès la création de site internet : vous n'aurez pas à les rattraper plus tard.

Questions fréquentes