Comment fonctionne un navigateur ?

 (howbrowserswork.com)
67 points par GN⁺ 2026-01-06 | 1 commentaires | Partager sur WhatsApp
  • Guide d’apprentissage interactif conçu pour permettre aux ingénieurs web comme aux utilisateurs ordinaires de comprendre intuitivement le fonctionnement interne d’un navigateur
  • Visualise étape par étape le processus, depuis la saisie dans la barre d’adresse jusqu’à la création de la requête HTTP, la résolution DNS, la connexion TCP, l’analyse du HTML, la construction du DOM et le pipeline de rendu
  • Chaque étape est composée d’exemples que l’on peut saisir ou manipuler directement, afin d’expérimenter concrètement la communication réseau et le processus de rendu
  • Montre clairement le rôle du DOM et la différence entre les étapes Layout–Paint–Composite, tout en permettant de voir visuellement les facteurs qui influencent les performances
  • Une ressource structurée pour assimiler les concepts clés à destination des développeurs qui veulent comprendre l’architecture des navigateurs ou l’optimisation des performances web

Vue d’ensemble

  • Ce guide a été conçu pour les personnes qui utilisent le web au quotidien mais ne comprennent pas clairement comment fonctionne un navigateur
    • Il comble les limites des ressources existantes, souvent soit trop techniques, soit trop superficielles
    • Il a été pensé pour permettre un apprentissage intuitif des détails techniques à travers de petits exemples interactifs
  • Les versions HTTP, SSL/TLS, les détails du fonctionnement de DNS, etc. sont volontairement omis, et le contenu est présenté de façon concise autour des concepts essentiels
  • Le projet est publié en open source, et des propositions d’amélioration peuvent être faites via GitHub

Navigateur et URL

  • Toute chaîne saisie par l’utilisateur dans la barre d’adresse est convertie en interne au format URL
  • Après avoir appuyé sur Entrée, une interface pratique permet d’observer directement le processus de conversion

Conversion de l’URL en requête HTTP

  • Après avoir déterminé l’URL exacte à visiter, le navigateur envoie une requête HTTP au serveur
  • Exemple d’en-têtes de requête : 
    Host: example.com
Accept: text/html
  • L’en-tête Host sert d’identifiant du serveur auquel la requête est envoyée

Résolution de l’adresse du serveur (DNS)

  • Le navigateur ne peut pas utiliser directement un nom de domaine comme example.com
    • Il faut le convertir en adresse IP via le système DNS pour pouvoir communiquer avec le serveur
  • En saisissant un domaine dans le champ prévu, on peut voir le résultat de la résolution DNS (adresse IP)

Établissement de la connexion TCP

  • Une fois l’adresse IP obtenue via DNS, le navigateur établit une connexion fiable avec le serveur à l’aide du protocole TCP
  • La connexion est établie grâce au processus de handshake en trois étapes
    1. SYN : le client demande la connexion
    2. SYN-ACK : le serveur répond et confirme
    3. ACK : le client confirme à son tour
  • TCP maintient une communication stable grâce à la garantie de l’ordre des données et au mécanisme de retransmission
  • Il est possible de couper le réseau ou de manipuler les paquets pour expérimenter la fiabilité de la transmission

Requête et réponse HTTP

  • Après l’établissement de la connexion TCP, le navigateur envoie une requête HTTP, et le serveur renvoie une réponse HTTP
  • Le trajet de la requête et de la réponse est affiché visuellement, ce qui permet d’observer le flux des paquets
  • Quand la réponse arrive, le navigateur sépare les en-têtes et le corps puis commence le rendu du HTML

Analyse du HTML et création de l’arbre DOM

  • Le navigateur transmet les octets HTML au parseur (parser) pour construire l’arbre DOM
  • En saisissant un exemple de HTML, on peut voir visuellement le processus de transformation des balises comme et en nœuds DOM
  • L’analyse se fait en streaming, ce qui permet de créer des nœuds avant même l’arrivée complète du document
  • Lorsqu’une balise `` apparaît, l’analyse est temporairement interrompue pour exécuter le script
  • Une fois terminé, le DOM est combiné avec le CSS pour former l’arbre de rendu (render tree)

Importance du DOM

  • Le DOM (Document Object Model) est le modèle du document en mémoire dans le navigateur, une structure centrale partagée par le parseur HTML, le moteur de sélecteurs CSS et le runtime JavaScript
  • Toute modification du DOM est immédiatement répercutée sur la mise en page, le style et les interactions utilisateur
  • Une fonction d’aperçu permet de voir les changements du DOM se refléter en temps réel lorsqu’on modifie le code JavaScript

Layout, Paint, Composite

  • Quand le DOM et le CSS sont prêts, le navigateur exécute le pipeline de rendu
    • Layout (Reflow) : calcul de la taille et de la position des éléments
    • Paint : remplissage des pixels
    • Composite : assemblage des couches sur le GPU
  • Un changement de couleur relance seulement Paint, tandis qu’un changement de taille relance à la fois Layout et Paint
  • Il est possible de vérifier d’un clic si chaque étape est relancée ou non
  • Le guide montre visuellement qu’une page avec beaucoup d’opérations de Layout se rend plus lentement

Résumé

  • Un guide qui permet d’apprendre par l’expérimentation directe tout le processus, de la saisie de l’adresse au rendu
  • En parcourant toutes les étapes, on peut se construire un modèle mental clair du fonctionnement d’un navigateur
  • Le projet est en open source, et des améliorations peuvent être proposées sur GitHub via des issues ou des Pull Requests

À lire aussi

1 commentaires

 
GN⁺ 2026-01-06
Avis sur Hacker News

  • Tous les navigateurs n’ont pas eu un DOM dès le départ
    Au début, il y avait WorldWideWeb (Nexus, 1990), Erwise (1992), ViolaWWW (1992), Lynx (1992), NCSA Mosaic (1993), Netscape 1.0 (1994), IE 1.0 (1995)
    Lynx reste encore aujourd’hui volontairement un navigateur sans DOM
    AOL 1.0–2.0 utilisait un moteur statique (AOLPress) sans objets programmables
    L’interaction avec le DOM n’est arrivée qu’avec Netscape 2.0 (1995), IE 3.0 (1996), AOL 3.0 (1996) et Opera 3.0 (1997)
    Ensuite, Netscape 4.0 (document.layers) et IE 4.0 (document.all) utilisaient chacun un modèle différent
    Le premier DOM standard a été le W3C DOM Level 1 (1998), avec un support partiel dans IE 5.0 (1999), puis un support complet à partir de Konqueror 2.0 (2000) et Netscape 6.0 (2000)
    Safari 1.0 (2003), Firefox 1.0 (2004) et Chrome 1.0 (2008) prenaient en charge le DOM standard dès le départ, et suivent aujourd’hui le WHATWG DOM Living Standard

    • Le navigateur Dillo conserve lui aussi une architecture sans DOM
      Comme il interprète et rend directement le texte HTML, sa consommation de RAM est très faible
    • Je me demande s’il ne serait pas plus exact de parler du « DOM dans les navigateurs modernes »

  • Super projet
    Pour les lecteurs de HN, cela vaut le coup de le lire avec High-Performance Browser Networking et Every Layout
    Ce sont deux excellentes ressources qui traitent en profondeur de la performance web et de la structure CSS

    • HPBN est vraiment un excellent livre
      Le chapitre 4 m’a permis de comprendre la structure des frames TLS, ce qui m’a aidé à déboguer des problèmes de latence dans mon ancien travail
      La partie sur les compromis liés à l’ajustement de la taille des frames TLS était aussi intéressante
      Je n’en aurai probablement pas souvent l’usage, mais j’ai découvert qu’un réglage fin au niveau réseau était possible
    • Merci pour le lien vers HPBN, c’est une ressource vraiment intéressante

  • C’est une approche intéressante qui donne l’impression d’essayer browser.engineering sans installation
    Quand vous montrez les exemples de navigateur et de serveur, ajouter des icônes visuelles (par exemple bureau/serveur) rendrait sans doute l’ensemble plus facile à comprendre

    • Je prévois d’ajouter davantage de sections et de détails
      Pour l’instant, je recueille surtout des retours, et la suggestion des icônes est une bonne idée que je vais examiner

  • J’aime beaucoup, je l’ai ajouté aux favoris
    Cela dit, il manque le processus de chargement des ressources comme les images, les feuilles de style et les scripts à partir du HTML/DOM
    C’est important pour comprendre pourquoi le style d’une page se casse ou pourquoi certaines images ne s’affichent pas

    • Je l’ai omis volontairement pour garder les choses simples
      Je réfléchis à une manière d’ajouter ces blocs sans trop compliquer l’ensemble

  • Quand la fenêtre du navigateur est étroite (moins de 1170 px), la section de la table des matières chevauche le corps du texte

    • C’est en cours de correction

  • La logique de parsing des URL pourrait être un peu peaufinée
    La plupart des utilisateurs n’auront sans doute aucun problème, mais les navigateurs traitent aussi spécialement les schémas de protocole autres que https:// ou http://
    Ce serait bien de prendre aussi ces cas en compte
    Référence : List of URI schemes

  • Excellent projet
    Je me demande si vous prévoyez, comme prochaine étape, d’ajouter plus de détails sur le processus de reflow

  • C’est un peu dommage que plus de la moitié de la page soit consacrée aux requêtes réseau
    En pratique, la partie vraiment complexe d’un navigateur se situe dans le pipeline de parsing et de rendu

    • Je compte traiter plus en détail la partie moteur de rendu
      Je ne savais pas encore dans quelle section aller plus en profondeur, donc j’ai d’abord publié le tout pour recueillir des retours
    • On peut aussi considérer le DOM comme faisant partie du pipeline de rendu

  • C’est peut-être une question farfelue, mais je me demande ce que ça donnerait si on supprimait complètement la résolution DNS pour ne fonctionner qu’avec des noms de domaine lisibles par les humains

    • Pensée encore plus farfelue : et si on faisait le routage avec des adresses Ethernet au lieu d’adresses IP ?
      L’idée serait de transformer tout Internet en un seul gigantesque switch
      J’ai déjà vu un article du fondateur de Tailscale qui évoquait une idée similaire

  • Beau travail