L’attribut fetchpriority, petit mais puissant

Sur le web moderne, le navigateur décide en permanence quelles ressources charger en priorité. CSS, JS, images, polices : tout entre en concurrence sur le réseau. Le problème : ce que le navigateur déduit n’est pas toujours ce que nous savons (nous humains) être critique. Fetchpriority permet d’ajuster finement cet arbitrage.

Ce que fait réellement `fetchpriority`

L’attribut fetchpriority permet au développeur d’exprimer une intention : signaler qu’une ressource a une importance plus élevée ou plus faible pour l’expérience utilisateur que celle estimée automatiquement par le navigateur.

En pratique, le navigateur attribue déjà une priorité interne aux requêtes réseau. Avec fetchpriority, on vient ajuster cette estimation. Selon la valeur fournie, le navigateur peut décider de lancer le téléchargement plus tôt ou au contraire de le reléguer derrière d’autres ressources.

Cet attribut peut être utilisé sur les éléments :

img
link
script

Il existe également un équivalent dans le contexte SVG pour appliquer la même logique aux ressources graphiques vectorielles.

Trois valeurs possibles :

high
low
auto (par défaut)

Important : c’est un hint, pas un ordre. Le navigateur conserve la décision finale.

Cas concret : optimiser le LCP

Par défaut, une image est souvent chargée avec une priorité moyenne ou basse jusqu’à ce que le layout soit établi. Si l’image correspond au contenu principal (hero, bannière, visuel clé), elle peut arriver trop tard.

Exemple :

<img src="/hero.webp" fetchpriority="high" width="1200" height="800" alt="">

Effet attendu :

Téléchargement démarré plus tôt
LCP amélioré
Moins de compétition réseau inutile

Pas de magie, mais sur des pages tendues côté performance, le gain peut être très significatif.

Application côté sobriété

La sobriété numérique ne consiste pas uniquement à réduire le poids total. Elle consiste aussi à charger les éléments de la page dans le bon ordre.

Deux leviers simples :

1. Baisser la priorité de ce qui n’est pas critique

Exemple :

<script src="/analytics.js" fetchpriority="low"></script>

Utile pour laisser “respirer” le réseau pour le contenu stratégique avant les scripts secondaires.

2. Éviter la surenchère de preload

Ajouter des rel="preload" un peu partout est assez souvent une facilité mais dès qu’un élément devient vraiment stratégique, fetchpriority peut-être plus subtil :

Il n’impose pas un téléchargement immédiat.
Il ajuste la priorité dans la file existante.

Moins brutal. Plus propre.

Mais à éviter

Indiquer `high` partout

Si chaque ressource est marquée high, le navigateur se retrouve avec une file d’attente uniformément élevée, ce qui annule toute bonne intention, sans aucun gain.

<!-- Contre-exemple -->
<img src="/hero.webp" fetchpriority="high" ...>
<img src="/thumbnail-1.webp" fetchpriority="high" ...>
<img src="/thumbnail-2.webp" fetchpriority="high" ...>
<img src="/thumbnail-3.webp" fetchpriority="high" ...>

Dans l’exemple ci-dessus, l’image hero ne bénéficie d’aucun avantage réel. La priorisation n’a de sens que si elle est sélective.

Le considérer comme un substitut systématique à `preload`

fetchpriority et preload répondent à des besoins différents :

preload déclenche un téléchargement anticipé, avant que le parser ne rencontre la ressource.
fetchpriority ajuste la priorité d’une ressource déjà dans la file.

Pour une police critique non découverte tôt dans le HTML, preload reste indispensable. fetchpriority="high" seul ne suffira pas à compenser une découverte tardive.

Optimiser sans mesurer

fetchpriority agit sur des heuristiques navigateur qui varient selon le contexte réseau, le device et la composition de la page. Un attribut ajouté “à l’intuition” peut n’avoir aucun effet, voire perturber un ordonnancement déjà efficace.

Avant d’intervenir : mesurer le LCP, observer la colonne “Priority” dans DevTools Network, identifier la ressource réellement en compétition. Après intervention : re-mesurer.

Interaction avec le navigateur

Les navigateurs attribuent une priorité interne à chaque requête réseau en fonction du type de ressource, de sa position dans le document et de son caractère bloquant ou non.

Chrome (Blink)

Dans Chrome, l’impact de fetchpriority est observable dans DevTools → Network → colonne “Priority”.

Les niveaux visibles sont généralement :

Highest
High
Medium
Low
Lowest

Lorsque fetchpriority="high" est appliqué à une image critique (par exemple celle correspondant au LCP), Chrome élève effectivement sa priorité réseau par rapport au comportement par défaut. Inversement, fetchpriority="low" abaisse la priorité et peut retarder le téléchargement si d’autres ressources concurrentes sont présentes.

L’attribut agit sur la priorité de téléchargement, mais ne transforme pas une ressource non bloquante en ressource bloquante (et inversement).

Firefox (Gecko)

Firefox implémente également fetchpriority, mais l’interface DevTools n’expose pas une colonne de priorité aussi explicite que Chrome.

L’effet reste néanmoins réel :

high augmente le poids de la requête dans l’ordonnancement réseau.
low la rétrograde par rapport aux ressources concurrentes.

Comme dans Chrome, il s’agit d’un indice, non d’une instruction impérative. Le moteur Gecko conserve la décision finale selon le contexte réseau, le nombre de connexions ouvertes et les contraintes internes.

En résumé, fetchpriority influence concrètement la file d’attente réseau dans Chrome et Firefox, mais son impact doit être validé par mesure (notamment sur le LCP et le temps de démarrage des requêtes critiques).

Pourquoi c’est un levier pertinent pour la performance sobre

L’optimisation ne porte plus uniquement sur le poids total d’une page. Elle porte sur la distribution intelligente des ressources dans le temps. Beaucoup d’ interfaces web “modernes” sont :

découpées en composants,
partiellement rendues côté serveur puis hydratées côté client,
chargées en modules ES,
enrichies d’images haute résolution, de polices variables et de médias optimisés.

Même lorsqu’une page est « légère » en volume global, elle reste soumise à une contrainte structurante :
la concurrence réseau initiale.

Au moment critique du chargement :

les CSS bloquants,
les modules JavaScript,
les images visibles,
les requêtes API initiales,
les scripts tiers

entrent en compétition dans une file d’attente limitée.

Le navigateur arbitre. Mais cet arbitrage repose sur des heuristiques génériques. Or, dans un contexte moderne (SSR partiel, islands architecture, streaming HTML, images responsives), l’heuristique ne correspond pas toujours à l’intention produit.

Là où `fetchpriority` devient stratégique

fetchpriority ne modifie ni l’architecture, ni la stack, ni le pipeline de build.
Il intervient au niveau le plus bas possible : le HTML livré au navigateur.

Il permet :

d’accélérer explicitement une ressource critique (image LCP, police clé),
de rétrograder une ressource secondaire (analytics, widget non visible),
d’affiner la hiérarchie sans multiplier les preload.

Ce n’est pas un outil spectaculaire.
C’est un outil d’ajustement.

Pertinence côté sobriété

La sobriété ne consiste pas uniquement à réduire les kilooctets. Elle consiste aussi à éviter la concurrence inutile au mauvais moment.

Un script non critique téléchargé trop tôt, peut :

retarder une image structurante,
augmenter la contention TCP,
rallonger le temps avant rendu stable,
prolonger l’activité CPU initiale.

En hiérarchisant plus finement les requêtes :

le contenu principal apparaît plus tôt,
la phase critique est raccourcie,
la charge initiale est mieux distribuée.

Il s’agit d’une optimisation qualitative, non volumétrique.

Un levier minimaliste

fetchpriority présente des caractéristiques rares dans l’écosystème performance actuel :

aucune dépendance,
aucun plugin,
aucun runtime,
aucun impact structurel,
aucune dette technique supplémentaire.

Un simple attribut HTML.

Dans un environnement où chaque optimisation passe par une couche supplémentaire (loader, plugin, proxy, CDN, bundler), disposer d’un levier natif, standardisé et déclaratif est stratégique.

Décision explicite là où le navigateur ne peut qu’estimer.

En bref

fetchpriority ne change pas la quantité de données chargées. Il change le moment où elles arrivent.

Dans un web saturé de composants, de scripts et de médias, la priorité réseau devient un levier aussi important que le poids total.

Accélérer le contenu réellement visible
Retarder ce qui peut attendre
Réduire la concurrence initiale

Aucune dépendance. Petit attribut.
Aucune complexité supplémentaire. Effet mesurable.
Juste une intention explicite dans le HTML.

Un ajustement discret, mais cohérent avec une approche performance orientée sobriété.