Comment fonctionne JavaScript dans le navigateur

Vous écrivez du JavaScript, vous rechargez la page et quelque chose se produit. Mais que fait réellement le navigateur entre le moment où il reçoit votre fichier et celui où un bouton réagit au clic ? Comprendre ce cycle évite beaucoup de bugs mystérieux : script exécuté trop tôt, interface qui se fige, ordre d’exécution surprenant.

Cet article décrit le modèle d’exécution de JavaScript dans le navigateur, de façon simple et sans jargon inutile.

Ce que le navigateur apporte à JavaScript

Le langage JavaScript seul ne sait ni afficher une page, ni écouter un clic, ni appeler un serveur. Dans le navigateur, il s’appuie sur trois ensembles :

• le moteur JavaScript, qui lit, compile et exécute votre code (chaque navigateur a le sien) ;
• les API Web, fournies par le navigateur : DOM, événements, fetch, minuteries, stockage local… ;
• le rendu, qui transforme HTML et CSS en pixels.

Ces API ne font pas partie du langage lui-même. Par exemple, document et fetch n’existent pas dans le langage standard : c’est le navigateur qui les expose. C’est pourquoi un même code ne se comporte pas toujours de la même façon dans Node.js et dans une page web. La présentation de JavaScript sur MDN apporte le contexte général.

Du fichier reçu à la page affichée

Voici la séquence simplifiée :

1. le navigateur télécharge le HTML et commence à l’analyser ;
2. il construit le DOM (l’arbre des éléments) et découvre les feuilles de style, images et scripts ;
3. il construit un modèle de style à partir du CSS, puis calcule la mise en page ;
4. il affiche le résultat ;
5. les scripts s’exécutent et peuvent modifier le DOM, ce qui peut déclencher un nouveau calcul et un nouvel affichage.

JavaScript peut donc intervenir à plusieurs moments, et sa position dans la page change son effet. Pour manipuler concrètement les éléments, voyez DOM JavaScript : manipuler la page correctement.

Charger un script : defer, async ou module

Un script classique placé dans le head bloque l’analyse du HTML : le navigateur doit le télécharger et l’exécuter avant de continuer. Trois attributs changent ce comportement :

<!-- Bloquant : à éviter dans le head -->
<script src="/js/app.js"></script>

<!-- Téléchargé en parallèle, exécuté après l'analyse du HTML, dans l'ordre -->
<script src="/js/app.js" defer></script>

<!-- Téléchargé en parallèle, exécuté dès qu'il est prêt, sans ordre garanti -->
<script src="/js/analytics.js" async></script>

<!-- Module : différé par défaut -->
<script type="module" src="/js/app.js"></script>

En pratique :

• defer convient à la plupart de vos scripts d’application, car l’ordre est respecté et le DOM est disponible ;
• async convient aux scripts indépendants (mesure d’audience, par exemple) ;
• type="module" active les modules, détaillés dans Modules JavaScript : import, export et ESM.

La page MDN sur l’élément script décrit précisément ces attributs.

Fil principal, boucle d’événements et événements

Un seul fil principal, une pile d’appels

JavaScript exécute votre code sur un fil principal unique : une seule instruction à la fois. Le moteur suit les appels de fonctions avec une pile d’appels (call stack) : quand une fonction en appelle une autre, celle-ci est empilée ; quand elle se termine, elle est dépilée.

function a() {
  b();
}
function b() {
  c();
}
function c() {
  console.log('Dans c');
}

a(); // la pile contient successivement a, b, c, puis se vide

Une conséquence directe : si une fonction tourne longtemps (grosse boucle, calcul lourd), rien d’autre ne peut s’exécuter sur ce fil, ni les clics, ni le défilement fluide, ni les animations. C’est la cause classique d’une page qui « fige ».

Un message d’erreur en console affiche d’ailleurs cette pile : lisez-le de haut en bas pour retrouver l’enchaînement d’appels qui a mené au problème.

La boucle d’événements : comment le navigateur reste réactif

Alors comment faire pour qu’un fetch, un setTimeout ou un clic ne bloquent pas ce fil unique ? Grâce à la boucle d’événements (event loop).

Le principe, simplifié :

1. le code synchrone s’exécute jusqu’à ce que la pile soit vide ;
2. les opérations asynchrones (minuteries, réseau, événements) sont gérées par le navigateur, en dehors de votre code ;
3. quand l’une d’elles est terminée, sa fonction de rappel est placée dans une file d’attente ;
4. lorsque la pile est vide, la boucle d’événements prend la prochaine tâche de la file et l’exécute.

console.log('A');

setTimeout(() => console.log('B'), 0);

Promise.resolve().then(() => console.log('C'));

console.log('D');
// Ordre affiché : A, D, C, B

Pourquoi C avant B ? Les fonctions de rappel des promesses passent par une file de microtâches, traitée avant la prochaine tâche (celle de la minuterie). Vous n’avez pas besoin de maîtriser tous les détails au quotidien, mais ce schéma explique la plupart des ordres d’exécution surprenants. Pour passer à la pratique, lisez Promesses et async/await en JavaScript.

Et le rendu dans tout ça ?

Le navigateur met à jour l’affichage entre les tâches, pas pendant l’exécution d’une fonction synchrone. Si votre code modifie dix fois le DOM dans une même boucle, l’écran ne s’actualise qu’après. Conséquence : une longue tâche empêche aussi l’affichage de se rafraîchir. Découpez le travail, ou déléguez-le (par exemple à un Web Worker pour un calcul lourd).

Les événements : le navigateur vous prévient

Une page interactive repose sur des événements : clic, saisie, soumission de formulaire, fin de chargement, redimensionnement.

const bouton = document.querySelector('#envoyer');

bouton.addEventListener('click', () => {
  console.log('Clic reçu');
});

Lorsqu’un événement se produit, le navigateur place la fonction de rappel correspondante dans la file ; elle s’exécutera quand le fil principal sera libre. Un écouteur doit donc rester court, sans quoi l’interface devient poussive. Les événements se propagent aussi dans l’arbre du DOM (phase de capture puis de bulle), ce qui permet la délégation : un écouteur sur le parent pour gérer ses enfants.

Ce qui est possible, et ce qui est cloisonné

Pour protéger l’utilisateur, le navigateur impose des limites à votre code :

• politique de même origine : un script ne lit pas librement les ressources d’un autre site, sauf autorisation explicite (CORS) ;
• pas d’accès libre au disque : les fichiers passent par des actions de l’utilisateur ;
• autorisations pour la géolocalisation, la caméra, les notifications ;
• contextes sécurisés (HTTPS) exigés par plusieurs API.

Côté sécurité, retenez aussi qu’insérer du texte non maîtrisé avec innerHTML expose à des injections de script (XSS) ; privilégiez textContent quand vous n’avez pas besoin de balisage.

Déboguer avec les outils de développement

Les outils intégrés du navigateur sont votre meilleur allié.

• Console : messages, erreurs et expérimentations rapides.
• Éléments : le DOM courant et les styles appliqués.
• Sources : points d’arrêt et exécution pas à pas.
• Réseau : requêtes, statuts, durées, en-têtes.
• Performance : où le temps est passé, repérage des longues tâches.

Quelques réflexes efficaces :

• placez un point d’arrêt plutôt que dix console.log ;
• lisez le message d’erreur en entier, avec la ligne et le fichier concernés ;
• vérifiez l’onglet Réseau quand une donnée n’arrive pas : mauvaise URL, statut 404 ou 500, blocage CORS ;
• testez avec la navigation au clavier : c’est un excellent révélateur de problèmes d’accessibilité.

Erreurs fréquentes

• Script exécuté avant que l’élément existe : le sélecteur renvoie null. Utilisez defer ou type="module".
• <script> bloquant dans le head : le rendu est retardé.
• Code synchrone trop long : l’interface se fige. Découpez ou déléguez.
• Confondre le DOM et le HTML source : le DOM change après exécution des scripts.
• Supposer un ordre d’exécution avec des appels asynchrones : seul ce qui suit un await, ou ce qui se trouve dans un .then(), est garanti d’arriver après la fin de l’opération.
• Se fier uniquement à JavaScript pour le contenu essentiel : les utilisateurs et robots qui ne l’exécutent pas ne le verront pas. Servez le contenu critique dans le HTML.

Si votre page est lente ou se comporte mal selon les navigateurs, un audit de site aide à repérer les causes techniques.

Pour aller plus loin

Une fois ce modèle en tête, enchaînez avec :

1. les variables, fonctions et objets pour écrire du code clair ;
2. les conditions ternaires en JavaScript pour écrire des conditions plus lisibles ;
3. npm ou pnpm pour gérer les dépendances de vos projets JavaScript ;
4. les fondamentaux HTML et CSS pour bien structurer la page que JavaScript manipule ;
5. la sémantique HTML pour un DOM clair et accessible.

Si vous préférez être accompagné, découvrez Academy Yunt et son blog.

Conclusion

Dans le navigateur, JavaScript s’exécute sur un fil principal, avec une pile d’appels, une boucle d’événements et des API Web fournies par le navigateur. Le chargement des scripts (defer, async, module), la brièveté des tâches et la compréhension de l’ordre d’exécution expliquent la majorité des problèmes rencontrés au début.

Retenez ce réflexe : quand quelque chose ne se passe pas comme prévu, demandez-vous à quel moment votre code s’exécute et ce qui occupe le fil principal à cet instant. Les outils de développement vous donnent la réponse.

FAQ

JavaScript est-il vraiment monothread ?

Votre code s’exécute sur un fil principal unique dans la page. Le navigateur, lui, effectue d’autres travaux en parallèle (réseau, rendu), et des Web Workers permettent de lancer des calculs sur d’autres fils.

Quelle différence entre JavaScript et Node.js ?

JavaScript est le langage. Node.js est un environnement d’exécution hors navigateur, avec ses propres API (fichiers, réseau), sans DOM.

Pourquoi setTimeout(fn, 0) ne s’exécute-t-il pas immédiatement ?

Parce que la fonction passe par la file de tâches : elle attend que le code synchrone en cours soit terminé et que la pile soit vide.

Faut-il toujours utiliser defer ?

Pour vos scripts d’application qui touchent au DOM, c’est généralement le bon choix. Pour un script totalement indépendant, async peut convenir.

Comment savoir si une page fige à cause de mon JavaScript ?

Ouvrez l’onglet Performance des outils de développement, enregistrez une interaction et repérez les longues tâches sur le fil principal.