Priority Hints : prioriser les ressources critiques sans dégrader le LCP

Priority Hints peut améliorer le chargement d’une image LCP en indiquant au navigateur qu’elle est plus importante que des ressources secondaires. Utilisez en général fetchpriority="high" sur une seule image hero, visible dès le chargement et confirmée comme élément Largest Contentful Paint (LCP).

L’attribut ne garantit ni un téléchargement immédiat ni un meilleur référencement. Il complète les heuristiques du navigateur : son effet dépend notamment de la découverte de la ressource, du cache, du réseau et des requêtes déjà en cours.

Choisir la bonne ressource

Le LCP correspond au moment où le plus grand élément visible est rendu. Il s’agit souvent d’une image principale sur les pages e-commerce ou éditoriales ; si elle attend derrière des ressources moins importantes, son affichage peut être retardé.

La candidate doit être présente dans le HTML initial, ne pas utiliser le lazy loading et avoir des dimensions explicites. Vérifiez d’abord qu’elle est bien l’élément LCP réel : une image hero supposée critique ne l’est pas toujours.

<img
  src="/images/guide-crawl.webp"
  width="1600"
  height="900"
  alt="Analyse de logs de crawl"
  fetchpriority="high">

Les valeurs prévues sont high, low et auto. auto laisse le navigateur décider ; les deux autres valeurs orientent son choix sans le remplacer.

Ne donnez pas une priorité élevée à toutes les images visibles. Plusieurs ressources en high se disputent la bande passante et peuvent annuler le bénéfice attendu pour l’image LCP.

Images de carrousel, vignettes et recommandations : laissez le comportement automatique ou utilisez low si elles ne contribuent pas au rendu initial.
Images sous la ligne de flottaison : low ne remplace pas loading="lazy".
Polices et scripts : ne les priorisez que s’ils sont indispensables au rendu initial. Les tags publicitaires, widgets sociaux, outils d’A/B test et scripts d’analytics ne devraient pas concurrencer le contenu principal.

Gérer la découverte tardive

Une priorité élevée ne rend pas un fichier plus léger et ne corrige ni un serveur lent, ni un CSS bloquant, ni une image découverte trop tard. Si l’image hero est injectée tardivement par JavaScript, l’attribut seul ne supprime pas ce retard.

Un preload peut être pertinent si la ressource est connue dans le HTML initial :

<link
  rel="preload"
  as="image"
  href="/images/guide-crawl.webp"
  fetchpriority="high">

Le preload doit viser exactement l’image affichée, y compris ses variantes responsives. Sinon, il télécharge un fichier inutile et peut concurrencer le CSS, les polices ou l’image réellement utilisée.

Le support doit être vérifié sur les navigateurs de votre audience. La documentation MDN sur fetchPriority indique que cette fonctionnalité n’est pas disponible de manière homogène dans tous les navigateurs.

Vérifier le résultat

Dans Chrome DevTools, identifiez l’élément LCP avec le panneau Performance ou Lighthouse. Dans l’onglet Network, rechargez avec le cache désactivé et vérifiez que sa ressource est découverte tôt, démarre sans attente évitable et n’est pas bloquée par des images, scripts ou ressources tierces.

La colonne Priority de Chrome est un indice, non une preuve de gain. Comparez surtout le waterfall, le moment de rendu du LCP et les ressources concurrentes.

Confirmez ensuite avec les données terrain, par exemple le Chrome UX Report (CrUX) lorsque des données sont disponibles. CrUX ne peut pas attribuer directement une variation de LCP à fetchpriority : pour isoler l’effet, comparez des pages similaires et utilisez aussi vos données RUM si elles remontent l’élément LCP et son URL.