5 niveaux de priorité JavaScript et comment les utiliser

Tous les scripts ne sont pas créés égaux

Une chose a toujours été claire : tous les JavaScript ne se valent pas. Certains scripts gèrent des interactions critiques comme une « interaction de menu » ou un « ajout au panier », tandis que d'autres scripts sont beaucoup moins importants. Prenez votre script de popup « d'intention de sortie » qui invite les visiteurs sur le point de quitter votre site à remplir un questionnaire. Je suis sûr que nous pourrions tous vivre sans ces derniers, mais il serait vraiment difficile de naviguer sur un site Web sans le premier.

Pourtant, sur « votre site Web moyen », au niveau technique, cette distinction n'est presque jamais faite. Tous les JavaScript sont « simplement ajoutés » à la page et le navigateur doit se débrouiller. C'est un problème car votre navigateur n'a aucune idée de ce qui est important et de ce qui ne l'est pas. Nous, en tant que développeurs, le savons. Alors réglons ça !

Dernière révision par Arjen Karel en mars 2026

La page mobile médiane charge 646 Ko de JavaScript sur 22 requêtes, selon le Web Almanac 2025. Environ 44 % de ce JavaScript n'est même jamais exécuté. Seules 13 % des pages passent l'audit de Lighthouse sur les ressources bloquant le rendu. Le problème n'est pas seulement la quantité de JavaScript que vous chargez. C'est quand et dans quel ordre.

Comment la priorité JavaScript peut impacter les Core Web Vitals

Le simple fait d'ajouter des scripts à la page sans la bonne considération peut impacter les 3 Core Web Vitals. Le Largest Contentful Paint, l'Interaction to Next Paint et le Cumulative Layout Shift.

Exemple : la ressource réseau du LCP est retardée par des JavaScript bloquant le rendu

Le Largest Contentful Paint est sujet à la concurrence de la bande passante et du processeur. Lorsqu'un trop grand nombre de scripts se disputent les premières ressources réseau, cela retarde la ressource réseau du Largest Contentful Paint et le travail initial du processeur retardera le LCP en bloquant le thread principal.

L'Interaction to Next Paint peut être affectée par l'exécution de scripts juste avant une interaction. Lorsque les scripts s'exécutent, ils bloquent le thread principal et retarderont toute interaction pendant ce temps d'exécution.

Les scripts peuvent également causer un Cumulative Layout Shift si les scripts « changent l'apparence de la page ». Les scripts publicitaires qui injectent des bannières dans la page et les sliders sont connus pour faire cela.

5 types de priorités JavaScript

J'aime distinguer 5 types de priorités JavaScript.

• Critiques pour le Rendu : ces scripts font partie des pires à avoir. Ils modifient la mise en page et sans le chargement de ces scripts, la mise en page sera complètement différente. Exemple : certains scripts de slider ou un test A/B.
• Scripts Critiques : Ces scripts gèrent des fonctionnalités critiques de la page et sans eux, des tâches critiques comme l'ajout d'un produit au panier, la recherche sur le site ou la navigation ne sont pas possibles.
• Scripts Importants : Ces scripts gèrent une logique métier importante et votre site en dépend. Par exemple : l'Analytics.
• Scripts Optionnels (Nice-to-Have) : Ces scripts sont un plus, mais en cas de besoin absolu, nous n'en avons pas vraiment besoin pour que la page fonctionne. Par exemple, un widget de chat ou une intention de sortie.
• Scripts Futurs : Ces scripts pourraient être critiques ou optionnels, mais nous n'en avons pas besoin pour le moment car « d'autres étapes » doivent être franchies avant de pouvoir réellement utiliser ces scripts. Par exemple, un script de paiement en plusieurs étapes.

Avant d'examiner chaque niveau de priorité, voici comment Chrome attribue la priorité réseau à différents types de scripts :

Comprendre ces valeurs par défaut est la clé de la priorisation des ressources.

1. Scripts Critiques pour le Rendu

Ces scripts modifient directement la mise en page. Sans eux, la page a un aspect complètement différent de sa conception prévue. Les exemples incluent les scripts pour les sliders ou les frameworks de tests A/B qui modifient la mise en page tôt dans le processus de chargement.

Le problème avec ces scripts est qu'ils ne peuvent pas être différés ou retardés. Tout retard entraînera un décalage de la mise en page du site Web, causant une mauvaise UX et un échec des Core Web Vitals.

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Page Title</title>
    <link href="styles.css" rel="stylesheet" />
    <script src="render-critical.js"></script>
  </head>
  <body></body>
</html>

Bonnes Pratiques :

• Évitez les scripts critiques pour le rendu autant que possible. Réécrivez votre code pour supprimer la dépendance à ces types de scripts.
• Si cela est inévitable, intégrez (inline) ou chargez uniquement les parties absolument nécessaires de ces scripts.
• N'utilisez pas defer ou async sur ces scripts et placez-les en haut du head pour déclencher un téléchargement « aussi tôt que possible ».

2. Scripts Critiques

Ces scripts permettent des interactions fondamentales. Sans eux, les tâches critiques telles que la navigation sur le site, l'ajout d'articles au panier, l'avis sur les cookies ou l'exécution d'une recherche deviennent impossibles. Ils sont indispensables pour la fonctionnalité principale du site.

Ces scripts doivent être placés dans le head de la page avec l'attribut async ou defer. Pour une comparaison complète de ces deux approches, voir async contre defer et comment ils affectent les Core Web Vitals.

<script defer src="critical.js"></script>
<script async src="critical.js"></script>

Bonnes Pratiques :

• Gardez les scripts de ce type au minimum et ne combinez pas cette fonctionnalité avec d'autres fonctionnalités moins critiques.
• Chargez ces scripts tôt en utilisant async ou defer, selon leurs dépendances.
• Utilisez le Real User Monitoring pour identifier les goulots d'étranglement dans l'exécution et assurez-vous que leurs performances correspondent aux besoins des utilisateurs.

3. Scripts Importants

Ces scripts soutiennent votre entreprise, mais ils ne sont pas nécessaires au fonctionnement de la page. Les scripts Analytics, par exemple, fournissent des données essentielles, mais n'ont pas besoin de se charger avant des éléments visuels plus importants. La distinction entre les scripts critiques et importants peut faire l'objet de débats, alors assurez-vous de parler à toutes les parties prenantes avant de définir cette priorité !

Il existe 2 moyens fiables de réduire la priorité de script pour ces types de scripts.

<html>
<head>
<!-- method 1: inject after DOMContentLoaded -->
<script>
  document.addEventListener('DOMContentLoaded', function() {
    var script = document.createElement('script');
    script.src = 'important.js';
    document.body.appendChild(script);
  });
</script>
</head>
<body>

<!-- method 2: place at the bottom of the page -->
<script defer src="important.js"></script>
</body>
</html>

1 : Injecter après DOMContentLoaded

En injectant le script après l'événement DOMContentLoaded, vous vous assurez que le script commence à se télécharger juste après que le HTML a été entièrement analysé. Cela permet aux ressources découvrables, telles que les images et les polices, d'avoir la priorité. Cette méthode offre un équilibre : le script commence à se charger assez tôt pour éviter les retards de fonctionnalité, mais n'entre pas en concurrence avec les premières ressources qui sont cruciales pour le rendu initial de la page.

2 : Placer en bas de la page

Cette technique classique diffère le chargement du script jusqu'à ce que le navigateur ait traité l'ensemble du document et obtient à peu près le même résultat que la technique 1. La seule différence est que la technique 1 contourne le preload scanner de votre navigateur, ce qui n'est pas le cas de cette technique. Le preload scanner est un scanner rapide et léger que votre navigateur utilise pour identifier et mettre en file d'attente rapidement les ressources critiques. Ignorer le preload scanner peut être une bonne idée s'il y a une possibilité d'images chargées en différé (lazy loaded) dans le viewport, tandis que l'utilisation du preload scanner accélérera le chargement pour ce script.

Une note sur fetchpriority : vous pourriez vous attendre à ce que fetchpriority="low" sur un script différé diminue sa priorité. Ce n'est pas le cas. Les scripts defer et async se chargent déjà avec une priorité Low dans Chrome. L'ajout de fetchpriority="low" sur ces scripts n'a aucun effet. L'attribut fetchpriority ne fait de différence que sur les scripts bloquants, où il peut faire chuter la priorité de Highest à High. Pour plus de moyens de différer le JavaScript, consultez notre guide complet.

4. Scripts Optionnels (Nice-to-Have)

Ces scripts améliorent l'UX, mais ne sont pas nécessaires au fonctionnement du site. Les exemples incluent les widgets de chat, les popups de retours clients ou les animations facultatives.

Ces scripts sont des candidats idéaux pour un modèle appelé « lazy on load ». Cela signifie : attendez l'événement load de la page, puis, pendant un temps inactif (idle time), injectez le script. Attendre l'événement load garantit que le script ne rivalise pas pour la bande passante et le processeur avec des ressources précoces plus importantes. Attendre un moment inactif garantit que le navigateur ne gère pas de tâches plus importantes comme l'entrée de l'utilisateur.

Voici un exemple fonctionnel :

window.addEventListener("load", () => {
  const idle = window.requestIdleCallback || ((cb) => setTimeout(cb, 1));
  idle(() => {
    const script = document.createElement("script");
    script.src = "/path/to/script.js";
    document.head.appendChild(script);
  });
});

Le fallback setTimeout est nécessaire car Safari ne supporte pas requestIdleCallback. Pour les scripts qui ont également besoin de diviser leur exécution en morceaux plus petits, envisagez d'utiliser scheduler.yield() pour garder le thread principal réactif et protéger votre score INP.

Bonnes Pratiques :

• Chargez ces scripts de manière différée (lazy-load) une fois la page chargée et attendez un moment inactif.
• Comprenez que les scripts chargés avec ce modèle ne sont pas garantis de se charger rapidement.

Sur les sites surveillés par CoreDash, les pages qui diffèrent les scripts non critiques après l'événement load obtiennent un score de 84 % « bon » sur l'INP, contre 61 % pour les pages qui chargent tous les scripts de manière anticipée.

5. Scripts Futurs

Les scripts futurs sont ceux qui ne seront pas nécessaires tant que des conditions spécifiques ne seront pas remplies. Par exemple, un script de paiement en plusieurs étapes ne devient pertinent qu'après qu'un utilisateur a ajouté des articles à son panier. Ces scripts peuvent attendre beaucoup plus tard dans le parcours de l'utilisateur.

Jetez un œil à cet exemple. Il utilise l'IntersectionObserver pour charger la logique JS uniquement lorsque c'est nécessaire : lorsque le formulaire est dans le viewport visible.

<!DOCTYPE html>
<html>
  <head>
    <script>
      document.addEventListener("DOMContentLoaded", function () {
        const form = document.querySelector("form");
        const observer = new IntersectionObserver(function (entries) {
          entries.forEach((entry) => {
            if (entry.isIntersecting) {
              const script = document.createElement("script");
              script.src = "/sign-up.js";
              document.head.appendChild(script);
              observer.unobserve(form);
            }
          });
        });
        observer.observe(form);
      });
    </script>
  </head>
  <body>
    <form action="/sign-up" method="post">
      <label for="email">Email:</label>
      <input type="email" id="email" name="email" required />
      <button type="submit">Sign Up</button>
    </form>
  </body>
</html>

Bonnes Pratiques :

• Chargez ces scripts à la demande, déclenchés par les actions de l'utilisateur.
• Utilisez des techniques de division du code (code-splitting) pour ne fournir que les parties requises à chaque étape.
• Injectez-les dynamiquement uniquement lorsque nécessaire, par exemple lorsqu'un utilisateur fait défiler vers une section spécifique.

La plupart des sites n'ont besoin que de deux modèles : defer pour tout ce qui est fonctionnel et le modèle load+idle pour tout le reste. Si vous passez du temps à peaufiner fetchpriority sur les scripts, vous compliquez probablement trop les choses. Obtenez d'abord les gros gains : différez ce que vous pouvez, retardez ce que vous pouvez, et supprimez ce dont vous n'avez pas besoin.