Guide Core Web Vitals pour la priorisation des ressources

Guide Core Web Vitals pour la priorisation des ressources

Le moteur de priorisation par défaut du navigateur fonctionne sur des heuristiques : des estimations imparfaites basées sur les types de fichiers et leur position dans le document. Les ressources sont mises en file d'attente en fonction du moment où elles sont découvertes, soit par le preload scanner, soit par le parseur DOM.

Dernière révision par Arjen Karel en Février 2026

Cela peut devenir un problème quand on considère que la bande passante réseau et le CPU ne sont pas des ressources illimitées. Par exemple : chaque octet transféré pour un script de tracking à basse priorité, téléchargé en même temps, entre directement en compétition avec les octets nécessaires pour votre Largest Contentful Paint (LCP).

Ce n'est pas la faute du navigateur : dans le HTML de notre exemple, le navigateur n'avait aucun moyen de savoir qu'il avait priorisé les mauvaises ressources, ce qui a retardé le rendu critique.

C'est vous qui savez ce qui est important et vous contrôlez ce calendrier à travers deux mécanismes : la Priorisation (amplifier les signaux critiques) et la Dépriorisation (planifier les ressources non critiques pour un moment où elles sont moins intrusives).

Limitations des heuristiques du navigateur

Les navigateurs attribuent une priorité basée sur un score de "priorité calculée". Ce score dérive du type de ressource (CSS, Script, Image) et de sa position dans le HTML/DOM. Bien que généralement efficace pour les documents simples, ce système échoue lorsque les ressources ne sont pas reconnues tôt (par le preload scanner) ou que les mauvaises ressources sont déclenchées pour un téléchargement anticipé.

Niveaux de priorité par défaut de Chrome

Chrome utilise cinq niveaux de priorité internes : Highest, High, Medium, Low et Lowest. Voici comment il les attribue par défaut :

L'attribut fetchpriority est supporté sur les éléments <img>, <link> et <script>. Il a un support navigateur global de 93% (Chrome 102+, Firefox 132+, Safari 17.2+, Edge 102+) et constitue une amélioration progressive : les navigateurs qui ne le supportent pas l'ignorent simplement. Selon le Web Almanac 2025, 17% des pages mobiles utilisent désormais fetchpriority="high", mais seulement 0,3% utilisent fetchpriority="low". Cela signifie que la dépriorisation est une optimisation massivement sous-utilisée.

La limitation du Preload Scanner

Pour accélérer la découverte, les navigateurs emploient un "preload scanner", un parseur léger qui progresse plus rapidement que le parseur HTML principal pour trouver les URLs de ressources. Ce scanner a des limitations (qui le rendent rapide et efficace) : il ne parse que le HTML. Il ne peut pas voir à l'intérieur des fichiers CSS, il n'exécute pas le JavaScript, et il ne fait pas de rendu (il ne peut donc pas déterminer si les ressources sont visibles dans le viewport).

En conséquence, toute ressource référencée dans une feuille de style (comme une image de fond ou une police web), injectée par un script, ou chargée en lazy loading, est ignorée jusqu'à ce que le parseur principal télécharge et traite l'intégralité de la page web. Cela crée un "délai de découverte," où le navigateur ne sait effectivement pas que des ressources critiques existent.

Contention des ressources

Lorsque le navigateur découvre des ressources, il tente souvent de les télécharger simultanément avec d'autres requêtes en attente. Si une image LCP importante est en compétition avec un script de priorité moyenne ou des images non importantes (comme des icônes de réseaux sociaux dans le footer), elles se partagent la bande passante disponible. Cette contention prolonge le temps de chargement des deux, poussant la métrique LCP dans la zone "À améliorer".

Stratégies de priorisation manuelle

Pour construire un chemin de rendu rapide, vous devez intervenir manuellement. L'objectif est de maximiser la bande passante pour le LCP et de la minimiser pour tout le reste. Parmi les sites surveillés par CoreDash, 82% des sites qui utilisent fetchpriority="high" sur leur image LCP passent le LCP, contre 61% des sites qui ne le font pas.

1. Corriger la découverte avec le Preloading

Vous devez exposer manuellement les ressources cachées au preload scanner. En déplaçant les ressources critiques dans le <head> HTML en utilisant rel="preload", vous forcez le navigateur à les reconnaître immédiatement, éliminant le délai de découverte. Pour un guide complet, consultez notre guide pour précharger l'image LCP.

L'implémentation :

<!-- Expose the font to the scanner immediately -->
<link rel="preload" as="font" type="font/woff2" href="/fonts/inter-bold.woff2" crossorigin>

<!-- Expose the LCP background image immediately -->
<link rel="preload" as="image" href="/images/hero-banner.jpg" fetchpriority="high">

Pour une découverte encore plus précoce, envisagez les 103 Early Hints, qui envoient des signaux de preload au navigateur avant que la réponse HTML n'arrive.

2. Remplacer les heuristiques LCP

Les navigateurs attribuent souvent une priorité "Low" ou "Medium" aux images car ils ne connaissent pas les dimensions finales de mise en page lors du fetch initial. Le navigateur ne peut pas déterminer si une image est le LCP avant que l'arbre de rendu ne soit construit, ce qui est trop tard.

L'implémentation :

Forcez le statut de priorité "High" sur l'élément LCP en utilisant fetchpriority="high". Cela contourne les heuristiques internes et place l'image en tête de la file de téléchargement. Google Flights a amélioré son LCP de 2,6 secondes à 1,9 seconde (une amélioration de 0,7 seconde) en ajoutant ce seul attribut.

<!-- Force immediate high-priority fetch -->
<img src="hero.jpg" alt="Hero Product" fetchpriority="high">

La pire erreur ici est de charger l'image LCP en lazy loading, ce qui dépriorise activement l'élément le plus important de la page.

3. Déprioriser les images non importantes

Libérer de la bande passante est souvent plus efficace que d'augmenter la priorité. Vous devez explicitement retarder les ressources non essentielles pour dégager le canal réseau pour les ressources critiques.

L'implémentation :

• Sous le pli : Utilisez loading="lazy" pour différer les images hors écran jusqu'au scroll de l'utilisateur.
• Au-dessus du pli, secondaire : Utilisez fetchpriority="low" pour les slides de carrousel ou les visuels secondaires qui s'affichent initialement mais sont moins importants que le LCP.
• Au-dessus du pli, visuellement non important : Contournez le preload scanner en utilisant loading="lazy" et attribuez une faible priorité de bande passante. Pratique pour les petites images comme les drapeaux ou icônes qui n'attirent jamais l'oeil lors du premier rendu mais peuvent déclencher beaucoup de requêtes de bande passante précoces.

<!-- LCP Image: Highest Priority -->
<img src="slide-1.jpg" fetchpriority="high">

<!-- Secondary Carousel Image: Immediate fetch, low bandwidth usage -->
<img src="slide-2.jpg" fetchpriority="low">

<!-- Translation flags: while in the viewport hide them from the preload scanner -->
<img src="dutch-flag.jpg" loading="lazy" fetchpriority="low">

<!-- Off-screen Image: Deferred fetch -->
<img src="footer-promo.jpg" loading="lazy">

4. Contrôler l'exécution des scripts

JavaScript bloque le parseur DOM. Si vous utilisez des balises <script> standard, le navigateur interrompt le parsing HTML pour télécharger et exécuter le fichier. L'exécution non contrôlée des scripts nuit aussi directement à Interaction to Next Paint (INP) en bloquant le main thread.

L'implémentation :

• defer : À utiliser pour la logique applicative. Il télécharge en parallèle (priorité Low) et ne s'exécute qu'après le parsing complet du HTML, en préservant l'ordre des dépendances.
• async : À utiliser pour les scripts tiers indépendants (comme les analytics). Il télécharge en parallèle et s'exécute immédiatement à la fin du téléchargement, sans respecter l'ordre.
• async + fetchpriority="high" : À utiliser pour les scripts async critiques (comme les tests A/B) qui nécessitent un téléchargement rapide sans bloquer le parsing. Cela augmente la priorité de téléchargement de Low à High tout en gardant l'exécution non bloquante.
• Injection : Contourne le preload scanner pour ne pas entrer en compétition avec la bande passante précoce. Les scripts injectés sont traités comme async.
• Planification + Injection : Injectez les scripts à un moment ultérieur, par exemple quand l'événement load a été déclenché.

<!-- Application Logic: Non-blocking, preserves execution order -->
<script src="app.js" defer></script>

<!-- Third-party Consent: Non-blocking, independent execution -->
<script src="consent.js" async></script>

<!-- Critical async: fast download, non-blocking execution -->
<script src="ab-test.js" async fetchpriority="high"></script>

<script>
  /* Inject example analytics */
  const script = document.createElement('script');
  script.src = 'analytics.js';
  script.async = true;
  document.head.appendChild(script);

  /* Inject + schedule example for chat */
  window.addEventListener('load', () => {
    const chatScript = document.createElement('script');
    chatScript.src = 'chat-widget.js';
    document.head.appendChild(chatScript);
  });
</script>

Pour une analyse complète de toutes les techniques disponibles, consultez 16 méthodes pour différer JavaScript et async vs defer JavaScript. Pour des conseils sur la catégorisation des scripts par criticité, consultez les niveaux de priorité JavaScript.

5. Débloquer le rendu CSS

Le CSS bloque le rendu par conception : le navigateur ne sait pas à quoi ressemble la page sans CSS. Il télécharge et parse donc les feuilles de style en premier.

Stratégies d'optimisation :

• Éviter @import : Il crée des chaînes de dépendances séquentielles qui dévastent la performance.
• Optimiser la taille du bundle : Évitez les fichiers CSS inférieurs à 3kB (surcharge) et supérieurs à 20kB (bloquants). Idéalement, visez des fichiers d'environ 15kB.
• Chargement asynchrone : Chargez les styles hors écran de manière asynchrone pour débloquer le chemin critique.
• Compromis du Critical CSS : Bien que l'insertion du Critical CSS en inline améliore la première vue de page, elle contourne le cache du navigateur, ce qui peut retarder les vues de page suivantes.

L'implémentation :

Éliminez @import entièrement. Utilisez des balises <link> pour un chargement parallèle. Pour le CSS non critique (comme les styles d'impression), utilisez l'attribut media pour débloquer le main thread. Pour en savoir plus sur l'optimisation CSS, consultez la suppression du CSS inutilisé.

<!-- Critical CSS: Blocks rendering (Correct) -->
<link rel="stylesheet" href="main.css">

<!-- Print CSS: Non-blocking until print event occurs -->
<link rel="stylesheet" href="print.css" media="print">

<!-- Async Pattern: Loads with low priority, applies on load -->
<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'">

6. Stabiliser le rendu des polices

Les polices sont des ressources lourdes et bloquantes. Une priorisation efficace nécessite des limites strictes sur ce qui est téléchargé et un contrôle sur le rendu.

Stratégies d'optimisation :

• Limites strictes de preload : Ne préchargez que les 1 à 2 fichiers de police les plus importants (généralement le texte LCP). Précharger 5+ polices sature la bande passante.
• Self-hosting : Hébergez vos polices web vous-même au lieu de les charger depuis un CDN tiers. Cela élimine la configuration de connexion supplémentaire.
• Réduire le payload : Utilisez des Variable Fonts (un fichier pour toutes les graisses) et le Subsetting (supprimez les caractères inutilisés) pour minimiser la taille du fichier.
• Stratégie de rendu :
  • Utilisez swap pour un rendu rapide (évite le texte invisible). Voir comment garantir que le texte reste visible pendant le chargement des polices web.
  • Utilisez optional pour prévenir le CLS (évite les décalages de mise en page sur les réseaux lents).

L'implémentation :

<!-- Preload ONLY the critical subset (e.g. Header + Body) -->
<link rel="preload" href="/fonts/inter-var.woff2" as="font" type="font/woff2" crossorigin>

<style>
  @font-face {
    font-family: 'Inter Variable';
    src: url('/fonts/inter-var.woff2') format('woff2-variations');
    /* Choose based on stability requirements: */
    font-display: optional; /* No layout shift, but font might stay fallback */
    /* font-display: swap;     Fastest text visibility, but risks layout shift */
  }
</style>

7. Accélérer les connexions

Avant qu'un navigateur puisse télécharger une ressource depuis une origine tierce, il doit effectuer une résolution DNS, établir une connexion TCP et négocier le chiffrement TLS. Cela prend du temps. Vous pouvez éliminer ce délai en indiquant au navigateur de configurer les connexions à l'avance.

L'implémentation :

• preconnect : À utiliser pour les origines tierces critiques dont vous savez que le navigateur aura besoin. Il effectue le handshake complet (DNS + TCP + TLS) à l'avance.
• dns-prefetch : À utiliser pour les origines moins critiques. Il n'effectue que la résolution DNS, ce qui est plus léger mais économise tout de même 20 à 120ms.

<!-- Critical third-party: full early connection -->
<link rel="preconnect" href="https://cdn.example.com">

<!-- Fallback for older browsers -->
<link rel="dns-prefetch" href="https://cdn.example.com">

Limitez le preconnect à 2 à 4 origines. Chaque connexion consomme du CPU et de la bande passante. Trop de preconnects entrent en compétition avec les téléchargements de ressources réels et peuvent nuire à la performance au lieu de l'aider. Selon le Web Almanac 2025, 22% des pages utilisent preconnect et 24% utilisent dns-prefetch. Placez les deux aussi tôt que possible dans le <head>, avant toute ressource bloquante.