Faut-il vraiment utiliser le preload pour toutes vos ressources critiques ?

Qu'est-ce que l'attribut preload et pourquoi Google en parle maintenant ?

L'attribut preload existe depuis plusieurs années dans les navigateurs modernes. Il permet de signaler au navigateur qu'une ressource spécifique (police, image, script, CSS) doit être récupérée immédiatement après le parsing du HTML, avant même que le navigateur ne découvre naturellement cette ressource dans le code.

Contrairement au prefetch qui prépare des ressources pour une navigation future, le preload travaille sur la page en cours. Le navigateur télécharge la ressource en haute priorité et la met en cache, prête à être utilisée dès que le code l'appelle. Cette déclaration de Google valide une pratique déjà répandue dans l'optimisation des Core Web Vitals.

Quelle différence avec le chargement normal des ressources ?

Sans preload, le navigateur suit un ordre de découverte séquentiel : il parse le HTML, découvre les CSS, les télécharge, parse les CSS, découvre les polices ou images de fond, puis les télécharge. Chaque étape attend la précédente. Ce waterfall peut retarder le rendu de plusieurs centaines de millisecondes.

Avec preload, vous court-circuitez cette cascade. Vous indiquez explicitement : « Cette police Montserrat est critique pour mon hero, charge-la maintenant ». Le navigateur la récupère en parallèle du parsing au lieu d'attendre la fin du téléchargement et du parsing du CSS. Le gain sur le Largest Contentful Paint peut atteindre 200-500ms sur des connexions moyennes.

Quelles ressources Google considère-t-il comme « critiques » ?

Google reste volontairement flou sur cette définition. Dans la pratique terrain, les ressources critiques sont celles nécessaires au rendu above-the-fold : polices custom utilisées dans le hero, CSS critique, images LCP, scripts synchrones bloquants si inévitables.

Les fonts web représentent le cas d'usage le plus fréquent. Une police non preloadée crée un FOIT (Flash of Invisible Text) ou FOUT (Flash of Unstyled Text) qui dégrade visuellement le chargement et retarde le LCP. Les images hero peuvent aussi bénéficier du preload, surtout si elles sont appelées via CSS et non directement dans le HTML.

• Polices web custom utilisées dans le contenu above-the-fold (priorité maximale)
• Images LCP chargées via CSS background-image ou découvertes tardivement
• CSS critique si votre architecture impose plusieurs fichiers et que certains bloquent le rendu
• Scripts essentiels au premier rendu (rare, généralement à éviter)
• Fichiers vidéo poster si la vidéo est l'élément LCP de votre page

Cette recommandation est-elle cohérente avec les observations terrain ?

Totalement. Les audits PageSpeed Insights signalent régulièrement les polices et images non preloadées comme opportunités d'optimisation. Les gains mesurés sont réels : entre 150ms et 600ms sur le LCP selon la latence réseau et le poids des ressources. Les sites e-commerce qui ont preloadé leurs polices hero et images produit ont vu leur LCP chuter sous la barre des 2,5 secondes.

Cela dit, Google simplifie dangereusement le message. Le preload n'est pas une baguette magique : mal utilisé, il crée une congestion de la bande passante qui retarde tout le reste. Preloader 8 ressources simultanément sur une connexion 3G sature le réseau et dégrade les performances globales. L'attribut doit être réservé aux 1-3 ressources réellement bloquantes pour le first paint.

Quels risques si on abuse du preload ?

Le premier risque, c'est la saturation de la queue de téléchargement. Chaque ressource preloadée passe en haute priorité. Si vous en avez 6, elles se battent toutes pour la bande passante disponible. Résultat : le navigateur peut retarder le téléchargement du CSS principal ou du JavaScript critique qui ne sont pas preloadés, dégradant finalement le TTI (Time to Interactive).

Second risque : le gaspillage de bande passante. Preloader une police qui ne s'affiche que dans le footer, c'est forcer le téléchargement d'une ressource inutile au premier rendu. Sur mobile avec un data cap, c'est problématique. Google ne mentionne jamais cette contrepartie dans sa déclaration, ce qui est typique de leur communication simplifiée. [A vérifier] : aucune donnée publique de Google sur le seuil optimal de ressources à preloader simultanément.

Dans quels cas le preload ne sert strictement à rien ?

Si votre ressource est déjà découverte tôt dans le HTML (une image directement dans un <img> en haut de page), le navigateur la charge automatiquement en haute priorité. Le preload n'apporte rien. Idem pour un CSS inline critique : pas besoin de preloader ce qui est déjà dans le DOM.

Les ressources non bloquantes pour le rendu ne doivent jamais être preloadées : scripts analytics, polices utilisées uniquement dans le footer, images below-the-fold. Pour ces cas, utilisez plutôt le lazy loading ou le prefetch si vous anticipez une navigation. Le preload doit rester l'exception, pas la règle générale pour toutes vos ressources.

Comment identifier les ressources à preloader sur mon site ?

Ouvre Chrome DevTools, onglet Network, et charge ta page en throttling 3G Fast. Identifie visuellement quel élément constitue ton LCP (généralement un hero image ou un bloc de texte avec police custom). Regarde dans le waterfall à quel moment cette ressource commence à se télécharger. Si elle démarre après 2-3 secondes, c'est un candidat parfait.

Pour les polices, cherche dans le waterfall les fichiers .woff2. S'ils se chargent tard (après le CSS), c'est qu'ils sont découverts tardivement. Preloader uniquement les polices visibles above-the-fold : si tu utilises 4 graisses de Roboto, preload seulement Regular et Bold si ce sont les seules dans le hero. Les autres peuvent attendre.

Quelle syntaxe utiliser et où placer le preload ?

La syntaxe correcte dans le <head> est : <link rel="preload" href="/fonts/montserrat-bold.woff2" as="font" type="font/woff2" crossorigin>. L'attribut as est obligatoire pour que le navigateur applique la bonne priorité. Pour les polices, crossorigin est requis même si la ressource est sur le même domaine, sinon elle sera téléchargée deux fois.

Place les preloads le plus haut possible dans le <head>, idéalement avant les CSS et scripts. L'ordre compte : le navigateur traite les preloads dans l'ordre de découverte. Si ton LCP est une image, son preload doit être le premier. Pour les images, utilise as="image" et ajoute fetchpriority="high" pour renforcer la priorité.

Quelles erreurs éviter absolument ?

Erreur classique : preloader une ressource puis ne jamais l'utiliser dans les 3 secondes. Chrome affiche un warning console « The resource was preloaded using link preload but not used within a few seconds ». Cela signifie que tu gaspilles de la bande passante. Vérifie que chaque ressource preloadée est réellement critique pour le first paint.

Autre piège : oublier le type="font/woff2" pour les polices. Sans cet attribut, le navigateur ne peut pas optimiser le téléchargement et peut ignorer le preload. Pour les CSS, n'utilise jamais as="style" avec un media query différent de celui du fichier : le navigateur téléchargera deux fois la ressource. Enfin, ne preload jamais une ressource servie avec un Cache-Control trop court : tu forces un téléchargement qui sera immédiatement invalidé.

• Auditer le waterfall Network en throttling 3G pour identifier les ressources critiques découvertes tardivement
• Limiter le preload à 2-3 ressources maximum par page (police hero + image LCP typiquement)
• Utiliser la syntaxe complète avec as, type, et crossorigin pour les fonts
• Placer les balises preload en haut du <head>, avant les CSS et scripts
• Vérifier dans la console qu'aucun warning « preload not used » n'apparaît
• Tester l'impact réel sur LCP avec Lighthouse avant/après pour valider le gain