# fetchpriority dans WordPress 6.3 : accélérer le LCP sans plugin

> WordPress 6.3 ajoute automatiquement l'attribut fetchpriority sur l'image LCP. Explications techniques et mesures avant/après sur plusieurs sites clients.

- Auteur : Clément Hadrot
- Publié le : 2023-09-28
- Mis à jour le : 2023-09-28
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/fetchpriority-wordpress-6-3-images/

## L’essentiel

- WordPress 6.3 détecte l'image probable du LCP et lui ajoute fetchpriority=high
- Le gain mesuré tourne autour de 5 à 15 % sur le LCP mobile
- Aucune configuration nécessaire, le cœur gère tout automatiquement

WordPress 6.3, sorti début août 2023, embarque une petite amélioration qui passe presque inaperçue dans le changelog mais qui a un effet direct et mesurable sur la performance : l'ajout automatique de l'attribut `fetchpriority="high"` sur l'image susceptible d'être le Largest Contentful Paint (LCP) de la page. Pas de réglage à activer, pas de plugin à installer : le cœur s'en charge tout seul dès la mise à jour.

C'est le genre d'optimisation qui mérite qu'on s'y arrête, parce qu'elle corrige un défaut structurel du chargement lazy généralisé introduit par WordPress depuis la version 5.5 : le lazy-loading par défaut sur toutes les images, y compris celle qui compte le plus pour la métrique la plus surveillée par Google. Voici comment ça fonctionne concrètement, et ce que ça change en pratique sur des sites réels.

## Rappel : le problème que WordPress 5.5 avait créé

Depuis WordPress 5.5, toutes les images du contenu reçoivent par défaut l'attribut `loading="lazy"`, via la fonction `wp_lazy_loading_enabled()`. C'est une bonne pratique pour les images situées bas dans la page : le navigateur ne les télécharge qu'au moment où elles approchent du viewport, ce qui économise de la bande passante.

Le problème, c'est que cette règle s'appliquait aussi à l'image mise en avant ou à la première image du contenu, celle qui est visible immédiatement au chargement et qui devient très souvent l'élément mesuré par le LCP. La retarder avec `loading="lazy"` revenait à ralentir volontairement la métrique la plus importante de la page. WordPress 5.5 avait déjà commencé à corriger le tir en excluant les premières images du lazy-loading dans certains contextes, mais sans optimisation active de leur priorité de chargement.

## Ce que fait fetchpriority dans WordPress 6.3

L'attribut HTML `fetchpriority` (valeurs `high`, `low`, `auto`) indique au navigateur l'ordre dans lequel prioriser le téléchargement des ressources. Chrome, Edge et les navigateurs basés sur Chromium le respectent pour accélérer le téléchargement d'une ressource critique, même si elle se trouve plus bas dans le HTML que d'autres.

> L'essentiel à retenir : WordPress 6.3 détecte l'image probable du LCP et lui ajoute fetchpriority=high ; Le gain mesuré tourne autour de 5 à 15 % sur le LCP mobile ; Aucune configuration nécessaire, le cœur gère tout automatiquement

WordPress 6.3 introduit la fonction `wp_get_loading_optimization_attributes()`, qui centralise la décision d'ajouter `loading="lazy"`, `fetchpriority="high"` ou rien du tout à une image, selon sa position estimée dans la page. Concrètement, pour l'image à la une d'un article et pour la première image détectée dans le contenu, WordPress :

- retire l'attribut `loading="lazy"`, pour ne pas retarder son téléchargement ;
- ajoute `fetchpriority="high"`, pour indiquer au navigateur de la télécharger en priorité, avant les scripts et feuilles de style non critiques.

Le rendu HTML ressemble à ceci pour une image à la une :

```
<img src="/wp-content/uploads/2023/09/hero.jpg"
     fetchpriority="high"
     width="1200" height="628"
     alt="Illustration de l'article" />
```

Le filtre `wp_img_tag_add_loading_optimization_attrs` permet, pour les développeurs qui en ont besoin, d'ajuster ce comportement au cas par cas — par exemple pour désactiver l'attribut sur un contexte précis où la détection automatique se trompe (page d'archive avec plusieurs images en tête, thème avec une mise en page atypique).

## Où WordPress applique la priorité automatiquement

La détection fonctionne pour :

1. L'image à la une (featured image) des articles et pages, affichée via `the_post_thumbnail()` ou les fonctions associées.
2. La première image de contenu insérée via le bloc Image dans l'éditeur de blocs, si elle apparaît tôt dans le flux HTML.
3. Certaines images de en-tête gérées par le thème, lorsque le thème utilise correctement les fonctions core plutôt que du HTML codé en dur.

C'est justement cette dernière limite qui explique pourquoi le gain n'est pas systématique : un thème qui insère son image de header directement en HTML brut, sans passer par les fonctions WordPress dédiées, ne bénéficie pas de la détection automatique. Pour un développeur de thème, la bonne pratique consiste désormais à toujours passer par `wp_get_attachment_image()` plutôt que par un simple tag `<img>`, précisément pour hériter de cette optimisation gratuitement.

## Mesures avant/après sur des sites clients

J'ai suivi le passage à WordPress 6.3 sur trois sites vitrine que je maintiens, tous construits avec des thèmes basés sur les blocs et sans plugin de lazy-loading tiers actif (ce qui aurait pu entrer en conflit avec la gestion native). Les mesures ont été prises avec WebPageTest, profil de connexion 4G, moyenne de 5 exécutions, avant et après mise à jour, sans autre changement entre les deux tests.

| Site | LCP avant 6.3 | LCP après 6.3 | Gain |
| --- | --- | --- | --- |
| Site vitrine A | 2,4 s | 2,1 s | -12,5 % |
| Site vitrine B | 3,1 s | 2,9 s | -6,5 % |
| Blog éditorial C | 1,9 s | 1,85 s | -2,6 % |

Le site A, qui affichait une grosse image hero non optimisée en poids, a profité le plus du changement : télécharger cette image plus tôt, en concurrence directe avec le CSS et les polices, a suffi à gagner plusieurs centaines de millisecondes. Le blog C, dont les images étaient déjà bien compressées et servies en WebP via un plugin d'optimisation, a vu un effet plus marginal : quand l'image n'est pas le facteur limitant, `fetchpriority` ne peut pas faire de miracle.

> Ne comptez pas sur `fetchpriority` pour compenser une image mal optimisée. Il change l'ordre de téléchargement, pas le poids du fichier. Continuez à compresser et à dimensionner correctement vos images à la une avant de vous reposer sur cette optimisation.

## En résumé

Le passage à WordPress 6.3 apporte un gain de LCP réel, mesurable, et surtout gratuit : aucune configuration, aucun plugin, aucun risque de conflit si le thème utilise correctement les fonctions core d'affichage d'image. L'ampleur du gain dépend directement de la situation de départ : plus l'image principale était pénalisée par le lazy-loading ou la concurrence avec d'autres ressources, plus l'effet se fait sentir. Pour les développeurs de thèmes, c'est aussi un rappel utile : passer par les fonctions natives de WordPress plutôt que par du HTML codé en dur reste le meilleur moyen de profiter automatiquement des futures optimisations du cœur.
