À l’occasion du Web2day, Anthony Le Goas, directeur du cabinet de conseil en informatique Zenika à Brest, a tenu la conférence intitulée : « Sous le capot des navigateurs web ». Pour introduire son sujet, l’intervenant a pris soin de rappeler la définition d’un navigateur web, selon Wikipédia : « C’est un logiciel conçu pour consulter et afficher le World Wild Web. »

Je note deux choses intéressantes ici : l’action de consulter et d’afficher. Cela nous donne une idée du rôle du navigateur. Avec cette première action, il va aller chercher des ressources web (HTML, CSS, une image, un fichier PDF…), pour ensuite afficher le contenu afin de proposer un rendu à l’utilisateur.

Au niveau des principaux acteurs, Chrome, le navigateur web de Google, reste le plus utilisé dans le monde avec 66,22 % de parts de marché en avril 2023 (59,98 % en France), selon les données de StatCounter. Il devance Safari (11,89 %), le navigateur web d’Apple, et Edge (10,95 %), celui de Microsoft. En France, c’est Firefox qui prend la 2e place (14,13 %) devant Edge (12,33 %).

La structure des navigateurs web

Selon le directeur de l’agence Zenika Brest, un navigateur web est composé de différentes briques, dont certaines sont reliées entre elles au sein de sa structure globale (voir l’image de Une) :

• L’UI Browser : c’est l’interface du navigateur, qui est affichée à l’écran avant d’accéder à la ressource web (barre de recherche, boutons précédent/suivant, etc.).
• Le moteur browser : il est considéré comme « la tête pensante du navigateur », qui va piloter et synchroniser les différents éléments associés. « Lorsqu’on va cliquer par exemple sur le bouton précédent, c’est le moteur browser qui va interpréter cette action pour répondre à la requête. »
• Le moteur de rendu : il représente « le cœur du navigateur », qui va chercher la ressource web pour afficher le rendu au niveau du navigateur. Au sein du moteur de rendu figurent 3 autres composants, à savoir le réseau, le moteur JavaScript qui permet d’animer les pages web, et l’UI Backend.
• L’UI Backend : il est à la fois lié au moteur de rendu et à l’UI Browser. Sur ce point, Anthony Le Goas précise que « c’est là où l’on va piocher tous les éléments natifs qui vont être utilisés par le navigateur pour faire des composants basiques, pour dessiner une fenêtre à l’écran par exemple, ou encore pour trouver les menus ou les boutons à afficher ».
• La persistance des données : cette couche est pilotée par le moteur du navigateur et permet de stocker des ressources pour faire fonctionner les applications web ou encore pour gérer les cookies.

Focus sur le moteur de rendu : son rôle et son fonctionnement en 3 étapes

Il existe 3 principaux moteurs de rendu pour les navigateurs web phares du marché : Gecko (Firefox), Blink (Google Chrome, Chromium, Brave, Opera, Microsoft Edge) et WebKit (Safari). Son rôle est essentiel car il va permettre d’afficher le code HTML et les feuilles de style en vue de « dessiner », c’est-à-dire « afficher visuellement » la ressource demandée aux utilisateurs.

Un moteur de rendu HTML est le composant logiciel de tous les navigateurs permettant d’afficher une page web : il transforme un document HTML, ainsi que toutes les autres ressources associées, en une représentation visuelle interactive pour l’utilisateur. Il est de ce fait le cœur d’un navigateur web (source : Wikipédia).

Le parsing

Concrètement, plusieurs opérations sont nécessaires pour assurer le fonctionnement d’un moteur de rendu. La première opération est celle du parsing, qui consiste à « traduire les éléments à afficher en une structure que le code peut comprendre et utiliser ». Il se base sur des règles de syntaxe ainsi qu’un vocabulaire, qui vont constituer ce que l’on appelle la grammaire du langage. Anthony Le Goas rappelle que 2 types de grammaire sont possibles, contextuelle ou non contextuelle, en fonction de la complexité du parsing.

Une grammaire contextuelle, c’est quoi ? Quand on va chercher à interpréter un mot clé qu’on a identifié dans la chaîne de caractères que l’on souhaite parser, l’interprétation de ce mot clé peut différer en fonction du contexte dans lequel il est utilisé, selon ce qui se trouve avant et après. À l’inverse, une grammaire dite non contextuelle consiste à prendre un mot clé et, peu importe ce qu’il y a avant ou après, son interprétation restera toujours la même.

Une action de parsing se décompose de la manière suivante :

• l’analyse lexicale : c’est-à-dire le processus de séparation de l’entrée en mots clés,
• l’analyse syntaxique : c’est-à-dire le processus d’application des règles de syntaxe.

Du côté du HTML et du CSS, le parsing va se baser sur les spécifications du W3C, qui contiennent l’ensemble des balises HTML et l’ensemble des mots clés CSS qui peuvent être utilisés. Le CSS requiert une grammaire sans contexte, relativement simple à parser, contrairement au HTML qui fonctionne avec une grammaire avec contexte.

À l’issue de ces opérations de parsing, des arbres de syntaxe vont être obtenus : la plus connue étant le DOM (Document Object Model) en HTML, et son équivalent CSS est le CSSOM (CSS Object Model).

Le render tree

Une fois les actions de parsing réalisées sur le HTML et le CSS, les mots clés identifiés, les règles de syntaxe appliquées, vient ensuite l’étape du render tree. Il s’agit de la représentation visuelle du document. Le render tree doit permettre de dessiner le contenu dans l’ordre correct tout en contenant l’ensemble des éléments visibles.

Il faut faire ici attention avec l’utilisation de « display: none », qui ne place pas l’élément concerné dans le render tree. En utilisant cette propriété, cela va entraîner un recalcul du render tree, qui va être trop gourmand pour le navigateur, avec le risque que cela puisse dégrader les performances de votre application. À la place, il convient d’utiliser la propriété « visibility » du CSS, qui va cacher l’élément et le laisser dans le render tree.

Sur le render tree, l’intervenant précise également que sa construction va nécessiter le calcul des propriétés visuelles de chaque objet. Ce calcul représente une opération complexe, et peut être « sujet à de potentielles problématiques de performances ».

Évitez les sélecteurs CSS trop complexes, qui vont impacter trop de balises HTML et complexifier le calcul du render tree. Les bonnes pratiques les plus courantes consistent à appliquer du CSS avec un identifiant mis sur un élément HTML ou par des class CSS, plutôt qu’en passant par des sélecteurs.

La partie « dessin »

Lorsque le render tree contient l’ensemble des éléments qui doivent être affichés, et que les propriétés CSS ont été calculées pour pouvoir être appliquées, place à la partie « dessin » ! Selon le directeur de l’agence Zenika Brest, elle se compose des 3 éléments suivants :

• Le layout : c’est le processus de définition de la position et de la taille des éléments, avec un style global ou incrémental (basé sur le principe de « dirty bit »).
• Le paint : c’est le processus de parcours du render tree pour dessiner chacun des éléments, avec également un style global ou incrémental (basé lui aussi sur le principe de « dirty bit »). À noter que l’ordre du processus de painting est : background color, background image, border, children et outline.
• Le composite : c’est le processus qui va permettre de gérer l’empilement des calques, l’opacité et les transformations.

C’est lors de cette étape du composite que l’on va intervenir pour optimiser des animations CSS, et éviter les lenteurs au niveau de vos performances.