Preconnect, preload, dns-prefetch : préparer les connexions avant que le navigateur en ait besoin

Une landing page qui charge une police Google Fonts, un widget de chat, une vidéo YouTube en fond de hero et un script de paiement Stripe appelle, la plupart du temps, quatre domaines différents en plus du sien. Pour chacun, avant même de télécharger le premier octet utile, le navigateur doit résoudre le nom de domaine (DNS), ouvrir une connexion TCP, puis négocier le chiffrement TLS si le site est en HTTPS — ce qui est systématiquement le cas aujourd'hui. Ces trois étapes cumulées peuvent représenter plusieurs centaines de millisecondes sur une connexion mobile, et elles se répètent, en silence, pour chaque nouveau domaine découvert au fil du chargement. Les resource hints (dns-prefetch, preconnect, preload) permettent de déclencher tout ou partie de ce travail avant que le navigateur n'en ait explicitement besoin.

Trois hints, trois niveaux d'anticipation

<link rel="dns-prefetch"> ne fait que résoudre le nom de domaine à l'avance — l'opération la moins coûteuse des trois, quelques dizaines de millisecondes gagnées, sans effet de bord notable. On peut l'appliquer largement, sur tous les domaines tiers connus de la page, sans risque. <link rel="preconnect"> va plus loin : DNS, poignée de main TCP et négociation TLS, les trois d'un coup. Le gain est plus net — on retire du chemin critique jusqu'à deux allers-retours réseau complets — mais le coût aussi : la connexion reste ouverte, mobilise de la mémoire et du CPU côté navigateur, et si aucune requête ne l'utilise dans les quelques secondes qui suivent, tout ce travail est perdu. <link rel="preload"> est différent dans sa nature : il ne prépare pas une connexion, il télécharge une ressource précise (un fichier de police, une image, un script) en lui donnant une priorité élevée, avant que le navigateur ne la découvre normalement dans le HTML ou le CSS.

Ce que dit la recherche sur le chemin critique du chargement

Une étude de référence de Xiao Sophia Wang, Aruna Balasubramanian, Arvind Krishnamurthy et David Wetherall, présentée à la conférence USENIX NSDI en 2013, a construit WProf, un profileur capable de reconstituer le graphe de dépendances complet d'un chargement de page — réseau, analyse du HTML, exécution JavaScript, mise en page, rendu — pour identifier précisément ce qui se trouve sur le chemin critique, c'est-à-dire les étapes qui, si elles étaient plus rapides, accéléreraient réellement l'affichage final. Sur 350 pages web analysées, les auteurs montrent que l'établissement des connexions réseau (DNS, TCP, TLS) occupe une part significative de ce chemin critique, aux côtés du calcul JavaScript synchrone qui bloque l'analyse du HTML (Wang, Balasubramanian, Krishnamurthy & Wetherall, 2013). Autrement dit : retirer une connexion du chemin critique en l'établissant à l'avance n'est pas une micro-optimisation cosmétique, c'est agir directement sur l'un des postes qui déterminent le temps d'affichage réel — et donc, sur une landing page, le LCP.

Où ça compte vraiment sur une landing page

• Une police Google Fonts non auto-hébergée — chaque visite déclenche une connexion vers fonts.googleapis.com puis fonts.gstatic.com ; un preconnect vers ces deux domaines réduit le délai avant que le fichier de police ne commence à se télécharger (l'auto-hébergement, que nous détaillons dans notre article sur Google Fonts et le RGPD, supprime carrément le problème).
• Un bouton ou un widget Stripe embarqué — le script de paiement charge depuis js.stripe.com ; un dns-prefetch discret évite au visiteur d'attendre la résolution DNS au moment précis où il clique sur le bouton d'achat.
• Une vidéo YouTube ou Vimeo en fond de hero — plusieurs domaines tiers (lecteur, CDN vidéo, tracking) s'ajoutent d'un coup ; ici, mieux vaut souvent différer le chargement de l'iframe elle-même plutôt que de multiplier les preconnect, comme nous le développons à propos de la vitesse de chargement.
• Un widget de chat en direct — Crisp, Intercom ou équivalent chargent leur propre script depuis un domaine distinct ; utile à préconnecter si le widget doit apparaître rapidement, comme nous le couvrons dans notre article sur le chat en direct.
• Le pixel de tracking Meta ou GA4 — ces scripts n'ont presque jamais besoin d'un preconnect : ils ne bloquent rien de visible, et leur exécution différée n'a aucun impact sur le LCP, comme nous le détaillons pour le pixel Meta et le tracking GA4.

L'erreur la plus fréquente : préconnecter à tout

Une connexion preconnect reste ouverte plusieurs secondes en attendant d'être utilisée ; si elle ne sert à rien, le navigateur l'a maintenue pour rien, au prix d'un peu de mémoire et de CPU — et la plupart des navigateurs limitent de fait le nombre de connexions préparées simultanément, ce qui signifie qu'ajouter un cinquième ou sixième preconnect peut simplement évincer les deux ou trois qui comptaient vraiment. PageSpeed Insights signale explicitement les preconnect inutilisés dans son audit « Préconnecter aux origines requises » : s'il apparaît en avertissement, c'est le signal qu'il faut réduire la liste plutôt que l'étoffer. La règle pratique : deux à quatre preconnect maximum, réservés aux domaines qui interviennent réellement dans le premier écran ; tout le reste passe en dns-prefetch, bien moins coûteux.

Preload : puissant, mais à réserver au vraiment critique

preload force le navigateur à télécharger une ressource en priorité, avant même qu'il ne l'ait découverte en analysant le HTML ou le CSS — utile pour un fichier de police utilisé dans le titre principal, ou pour une image de fond CSS qui, sans cela, ne serait découverte qu'après le téléchargement complet de la feuille de style. Le piège : chaque ressource préchargée consomme de la bande passante et de la priorité réseau dès les premières millisecondes du chargement, en concurrence directe avec l'image hero ou le script principal. Précharger une police qui ne sert qu'au pied de page, ou une image qui n'apparaît qu'après un clic, retire des ressources à ce qui compte vraiment pour l'affichage initial — et peut, paradoxalement, dégrader le LCP que l'on cherchait à améliorer.

Implémenter proprement sur une landing page Next.js

Sur un site Next.js, comme les 10 templates LanderKit, le composant next/font gère déjà automatiquement le preload des polices auto-hébergées : aucune balise manuelle à ajouter, le fichier est injecté avec la bonne priorité dès le build. Pour les domaines tiers restants (Stripe, chat, vidéo), la méthode la plus simple consiste à ajouter les balises <link rel="preconnect"> ou <link rel="dns-prefetch"> directement dans le <head> généré par app/layout.tsx, en limitant la liste aux domaines effectivement appelés par la page. Pour les scripts eux-mêmes, next/script avec une stratégie lazyOnload ou afterInteractive évite qu'un script tiers ne bloque le rendu initial — nous détaillons la configuration complète du déploiement dans notre article sur Next.js et Vercel.

Vérifier l'effet réel plutôt que de le supposer

L'onglet Réseau de Chrome DevTools affiche, pour chaque requête, le détail des phases (DNS, connexion, TLS, attente, téléchargement) : c'est là qu'on voit concrètement si un preconnect a effectivement retiré une attente du chemin critique, ou si la connexion, une fois ouverte, n'a jamais été réutilisée. PageSpeed Insights et Lighthouse complètent ce diagnostic avec des audits dédiés — nous expliquons pourquoi ces deux outils peuvent afficher des scores différents dans notre article sur PageSpeed, Lighthouse et GTmetrix. Comme pour toute optimisation technique, mieux vaut mesurer avant et après chaque ajout plutôt que d'empiler des balises par précaution : un preconnect inutile n'est jamais neutre, il coûte toujours un peu de ressources au navigateur.