Corriger "Avoid Chaining Critical Requests" dans Lighthouse

Comment la priorité de téléchargement est déterminée

Les requêtes critiques sont les ressources téléchargées avec une priorité élevée lors du chargement initial de la page. Comment cette priorité est-elle déterminée ?

La priorité de téléchargement est déterminée par le navigateur lui-même. Le navigateur suit un ensemble de règles pour déterminer la priorité de chaque ressource. Les éléments qui reçoivent finalement la plus haute priorité dépendent de la structure de la page. Les éléments que votre navigateur juge nécessaires pour le premier rendu de la page reçoivent la priorité la plus élevée.

Votre navigateur fait d'abord une estimation éclairée des éléments les plus importants. En général, la priorité de téléchargement fonctionne ainsi : le HTML a toujours la priorité la plus élevée, puis les feuilles de style, le JavaScript synchrone, les polices, les requêtes AJAX, les images en haut de la page, les images plus bas dans la page, et ensuite le JavaScript asynchrone.

Vous pouvez outrepasser ces priorités avec l'attribut fetchpriority. Définir fetchpriority="high" indique au navigateur qu'une ressource est plus importante qu'il ne le supposerait normalement. Définir fetchpriority="low" fait l'inverse. Cet attribut bénéficie désormais d'une prise en charge par 93 % des navigateurs. Pour un guide complet, consultez Resource Prioritization and the Core Web Vitals.

Vous pouvez voir quelles ressources reçoivent une priorité élevée sur votre page. Ouvrez DevTools avec Ctrl+Shift+J. Accédez à l'onglet Network, faites un clic droit sur les noms de colonnes et sélectionnez 'Priority'.

Comment la chaîne de requêtes critiques affecte-t-elle le temps de chargement de la page ?

Lors du chargement d'une page, un navigateur démarre en mode "blocage de l'affichage". Dans ce mode, les ressources les plus importantes sont téléchargées avec une priorité élevée. Ce sont les ressources critiques.

Un navigateur ne commencera pas (pleinement) le rendu de la page tant que toutes les ressources critiques n'auront pas été téléchargées. Ainsi, toute ressource critique peut bloquer le premier rendu d'une page.

Moins une page contient de ressources critiques, moins le navigateur a de travail pour afficher le premier contenu à l'écran, et moins il y a de concurrence pour le processeur et d'autres ressources.

Selon le Web Almanac 2025, seulement 15 % des pages mobiles passent l'audit des ressources bloquant le rendu. Cela signifie que 85 % du web a encore des problèmes de chaînes critiques à résoudre. C'est l'une des principales raisons pour lesquelles seules 55 % des origines mobiles obtiennent un score "bon" pour le First Contentful Paint. Sur les sites surveillés par CoreDash, les origines avec moins de 3 requêtes dans la chaîne critique ont un FCP médian de 1,2 seconde, contre 2,4 secondes pour les origines avec 8 requêtes en chaîne ou plus.

Note : Depuis Lighthouse 13 (octobre 2025), cet audit a été renommé en "Network Dependency Tree". Le concept est le même : Lighthouse analyse la chaîne de requêtes réseau à haute priorité et signale lorsqu'elle est trop profonde.

Comment corriger "Avoid Chaining Critical Requests" dans Lighthouse

Vous pouvez réduire l'impact des requêtes critiques de trois manières :

1. Réduire le nombre de ressources critiques. Convertissez les ressources critiques en ressources non critiques en les supprimant ou en les différant.
2. Réduire le nombre d'octets critiques. Réduire la taille des ressources du chemin critique permet de les télécharger plus rapidement. La compression Gzip ou Brotli, le tree shaking JavaScript, l'optimisation des images et le sous-ensemble de polices (font subsetting) sont tous utiles.
3. Améliorer l'ordre de téléchargement du chemin critique. Utilisez des indications de ressources comme le préchargement pour ignorer la découverte de ressources et vous assurer que les ressources critiques sont téléchargées le plus rapidement possible. Utilisez HTTP 103 Early Hints pour commencer à précharger les ressources avant même que le HTML n'arrive.

La meilleure option dépend du type de fichier de la ressource :

1. HTML

Le HTML lui-même est toujours téléchargé avec la priorité la plus élevée. La page fait toujours partie de la chaîne de requêtes critiques. C'est pourquoi la page elle-même est la première chose à considérer lors de l'optimisation.

Chargement différé du contenu : De nombreux grands sites, comme Google lui-même, utilisent cette technique pour réduire la chaîne de requêtes critiques. Sur la page de résultats de recherche, par exemple, les parties du contenu qui ne sont pas immédiatement nécessaires ne sont chargées que plus tard via une requête AJAX.

Minifier : Plus c'est petit, plus c'est rapide. Utilisez la minification HTML pour supprimer les commentaires, les espaces et les lignes vides de la page.

Compression : Compressez votre HTML avec Brotli ou Gzip. Brotli permet généralement d'obtenir une compression de 15 à 20 % supérieure à celle de Gzip.

2. Feuilles de style

Les feuilles de style dans la section head de la page sont toujours critiques. Sans styles, un navigateur ne sait pas à quoi ressemblera la page. Les feuilles de style sont donc une partie standard de la chaîne de requêtes critiques.

CSS critique : Le moyen le plus efficace de briser la chaîne CSS est d'intégrer directement votre CSS critique en ligne (inline) dans une balise <style> au sein de <head>. Cela élimine entièrement la requête réseau bloquant le rendu. Vous pouvez générer du CSS critique via des outils NodeJS ou via le Critical CSS Generator. Placez le CSS critique en ligne et chargez le reste avec une priorité moindre :

<link rel="preload"
      href="css.css"
      type="text/css"
      as="style"
      onload="this.onload=null;this.rel='stylesheet';"/>

Observez ce qui se passe alors d'étrange sur la page. D'abord, la page s'affiche sans styles, et ce n'est qu'après le chargement du CSS que le style est appliqué. Tout le contenu passera d'un état non stylé à un état stylé (flash). C'est pourquoi vous avez besoin du CSS critique : les règles CSS pour la partie visible de la page sont en ligne, de sorte que la page s'affiche correctement immédiatement, et le reste du CSS se charge sans bloquer le rendu.

Éviter les chaînes CSS @import : Si vos fichiers CSS utilisent @import pour charger d'autres fichiers CSS, vous créez une chaîne où le navigateur doit télécharger le fichier A avant même de découvrir qu'il a besoin du fichier B. Remplacez les déclarations @import par des balises <link> séparées ou concaténez les fichiers lors de la compilation. C'est l'une des causes les plus fréquentes de chaînes critiques inutilement profondes.

Requêtes multimédias (Media queries) : Ne chargez que les styles dont votre appareil a besoin. Si un visiteur est sur mobile, il n'a pas besoin de télécharger les styles de bureau ou d'impression. Utilisez l'attribut media pour rendre les feuilles de style non bloquantes pour les appareils qui ne correspondent pas :

<link href="all.css" rel="stylesheet" media="all">
<link href="print.css" rel="stylesheet" media="print">
<link href="desktop.css" rel="stylesheet" media="screen and (min-device-width: 1024px)">

Le navigateur ne télécharge avec une priorité élevée que les feuilles de style dont l'attribut media correspond à l'appareil actuel. Les feuilles de style ne correspondant pas sont téléchargées avec une faible priorité et ne bloquent pas le rendu.

Minifier : Supprimez le CSS inutilisé. De nombreux sites utilisent des bibliothèques CSS telles que Bootstrap. Ces bibliothèques sont souvent trop complètes et toutes les déclarations de style ne sont pas utilisées. Modifiez ces bibliothèques via un préprocesseur CSS (tel que Sass) pour supprimer les groupes de styles inutilisés. Les préprocesseurs minifient également votre CSS en supprimant tous les espaces et les retours à la ligne. Consultez également comment corriger 'remove unused CSS'.

Compression : Compressez les feuilles de style avec la compression Brotli ou Gzip.

3. JavaScript

Les fichiers JavaScript dans la section head de la page sont téléchargés avec une priorité élevée par défaut et bloquent le rendu de la page pendant qu'ils sont téléchargés et exécutés. Le JavaScript est donc une partie standard de la chaîne de requêtes critiques.

Defer et Async : Ajustez la priorité des fichiers JavaScript en les chargeant de manière asynchrone via l'attribut async ou defer. Les scripts async sont téléchargés en parallèle avec une priorité inférieure. Les scripts différés (defer) sont également téléchargés en parallèle et leur exécution est retardée jusqu'à ce que le HTML ait été analysé. Pour une comparaison complète, voir async vs defer et comment ils affectent les Core Web Vitals.

// bloque le chargement et l'exécution
<script src="normalscript.js"></script>
// async ne bloque pas pendant le chargement, mais bloque pendant l'exécution
<script async src="asyncscript.js"></script>
// defer ne bloque pas pendant le chargement ni l'exécution
<script defer src="deferscript.js"></script>

Pour plus de techniques permettant de différer le JavaScript, consultez 16 méthodes pour différer ou planifier le JavaScript. Si vous avez du JavaScript inutilisé qui ne peut pas être différé, consultez comment réduire le JavaScript inutilisé.

Division du code (Code splitting) et préchargement : Si la page ne permet pas au JavaScript de se charger de manière asynchrone, divisez le JavaScript en plusieurs fichiers. Placez la partie qui est critique lors du chargement de la page dans un petit fichier et préchargez-la. Placez le JavaScript non critique dans un autre fichier et laissez-le se charger en différé ou en asynchrone.

Minifier : Réduisez le nombre d'octets grâce à un minificateur JavaScript. Les bundlers modernes comme webpack, Rollup et Vite utilisent terser sous le capot pour analyser le JavaScript et le rendre aussi petit que possible.

Compression : Réduisez le nombre d'octets en compressant le JavaScript via Gzip ou Brotli.

4. Polices Web

Les polices Web sont généralement les derniers fichiers de la chaîne de requêtes critiques. En effet, les polices Web reposent sur la découverte : elles ne sont chargées que lorsqu'un navigateur découvre qu'elles sont nécessaires. Pour cela, un navigateur doit d'abord analyser le HTML et chercher dans la feuille de style quelle police est utilisée.

Préchargement : Lorsque vous savez que vous allez utiliser une police, il est plus rapide de précharger cette police. La police est alors téléchargée le plus tôt possible, minimisant ainsi l'influence sur la chaîne de requêtes critiques. Préchargez une police en ajoutant ce code le plus tôt possible dans le head de la page :

<link rel="preload" href="font.woff2" as="font" type="font/woff2" crossorigin>

Stratégie de polices : Il existe de nombreuses autres façons d'accélérer le chargement des polices. Consultez comment héberger vous-même Google Fonts et comment s'assurer que le texte reste visible pendant le chargement des polices web.

• Utilisez toujours des polices web auto-hébergées, jamais de polices hébergées à distance comme Google Fonts.
• Redimensionnez la police en utilisant le sous-ensemble de polices (font subsetting).
• Chargez les polices non critiques via la FontFace API.
• Utilisez font-display: swap pour éviter que les polices ne bloquent le rendu initial.
• Laissez les navigateurs générer leurs propres variantes de polices grâce à la synthèse de polices.

5. Images

Les images qui apparaissent dans la zone visible (viewport) lors du chargement de la page peuvent également recevoir une priorité élevée et peuvent interférer avec le chemin critique. Lorsque vous êtes sûr qu'une image apparaîtra toujours dans la partie visible du site web, préchargez cette image. Ajoutez fetchpriority="high" pour indiquer au navigateur que c'est l'image la plus importante de la page :

<link rel="preload" as="image" href="important-image.webp">

Pour toutes les images qui ne sont pas immédiatement visibles, chargez ces images en différé (lazy load). Utilisez loading="lazy" pour retarder le chargement de l'image jusqu'à juste avant qu'elle ne devienne visible :

<img loading="lazy" src="lazy-image.webp" width="20" height="20" alt="...">

6. Requêtes AJAX

Les requêtes AJAX reçoivent toujours une priorité élevée. Par conséquent, reportez les requêtes AJAX jusqu'à ce que la page ait fini de s'afficher. Attendez que la page ait envoyé l'événement "load" :

window.addEventListener('load', (event)=>{
  console.log('ceci est un bon moment pour une requête AJAX');
});

S'il n'est pas possible de reporter la requête AJAX, vous pouvez précharger la ressource pour la rendre disponible au navigateur plus tôt.

7. Iframes

Les iframes sont généralement téléchargées avec une priorité élevée. Parce qu'une iframe est en réalité une page dans une page, une iframe peut causer un retard important dans les temps de chargement de la page. Les ressources requises par l'iframe peuvent également être téléchargées avec une priorité élevée et former leur propre chaîne de requêtes critiques. L'utilisation d'iframes peut donc affecter considérablement vos Core Web Vitals.

Vous pouvez retarder le chargement d'une iframe via l'attribut loading="lazy". Cela fait souvent une grande différence lorsque l'iframe n'est pas immédiatement visible pendant le chargement. Pour plus de contrôle sur le timing, injectez l'iframe via JavaScript pour vous assurer qu'elle ne se retrouve pas dans la chaîne de requêtes critiques. Consultez comment intégrer Google Maps sans nuire à votre PageSpeed et comment intégrer YouTube avec des Core Web Vitals parfaits pour des exemples de cette technique.

Vérifier vos améliorations

Après avoir optimisé votre chaîne critique, vérifiez l'amélioration avec la Real User Monitoring. Votre FCP et votre LCP devraient tous deux s'améliorer. Les outils de laboratoire comme Lighthouse vous donnent un retour instantané, mais ce sont les données de terrain (field data) des utilisateurs réels qui comptent pour les Core Web Vitals.