Sous le capot de Google Chrome

Je ne vais pas en rajouter sur ce que chacun pourra constater de lui-même sur Google Chrome, je me contenterai de dire qu’il est désormais mon navigateur par défaut (hors développement). Je ne vais pas non plus parler de la stratégie de Google : la société l’explique assez clairement et j’ai pour ma part la naïveté de la croire.

Je veux vous parler de ce que Chrome a dans le ventre et de pourquoi ça marche si bien… et surtout si vite. Un navigateur web, c’est essentiellement 4 choses :

  • un moteur de rendu HTML pour afficher les pages, 
  • un moteur d’exécution Javascript,
  • une interface utilisateur pour permettre l’accès aux fonctionnalités du navigateur
  • une architecture qui fasse tenir le tout debout (y compris les plugins, comme Flash, qui s’y rattachent).

Or, sur chacun de ces points, Google a fait ce qu’il fallait, en appliquant simplement des recettes connues par à peu près tous les développeurs s’intéressant de près aux navigateurs. 

Le moteur HTML utilisé par Google n’est autre que Webkit (bon, le moteur en lui-même s’appelle « Webcore », mais comme tout le monde dit « Webkit », je vais pas me la jouer puriste…) . C’est le moteur de rendu de Safari, de l’iPhone, d’Android et de nombreux navigateurs pour mobile. Webkit est simple, rapide et léger : précisément ce que cherchait Google. 

Le moteur Javascript, V8, est lui une nouveauté : son principal atout est la reprise de l’idée de compilation juste-à-temps de Tracemonkey, le moteur utilisé par le futur Firefox 3.1. En d’autres termes, il a une longueur d’avance sur tous les autres (même si avec Brendan Eich, le concepteur de Javascript, chez Mozilla, la partie risque d’être serrée) ! En générant des pseudo-classes pour mieux mutualiser les comportements des objets et en mettant ou point un ramasse-miette efficace, les concepteurs de V8 ont dégagé de nouvelles marges de manoeuvre pour larguer la concurrence dans la course à la performance. 

L’interface utilisateur est dépouillée au maximum, ce qui limite bien entendu la consommation de ressources. De plus, Google a réalisé un kit graphique sur mesure afin de maitriser au mieux cet aspect (plutôt que d’en laisser la responsabilité à Windows ou à un kit graphique tiers comme le fait la majorité la majorité des applications). 

L’architecture qui tient le tout a un principe directeur : compartimentation ! Ce qui dans la BD de présentation de Chrome aux journalistes est résumé sous l’expression « un onglet, un processus » est en réalité plus complexe comme le montre le schéma ci-dessous : architecture chrome

Pour faire « simple » : un processus-maître coordonne des processus de rendu propre, chacun de ces processus étant lui-même multi-threads.  Cette architecture segmente parfaitement les responsabilités et évite qu’un problème ne bloque l’ensemble de l’application. Elle permet également de paralléliser les traitements ce qui peut s’avérer plus efficace dans certaines configurations.  

Ce même principe de compartimentation est appliqué en matière de plug-in : en utilisant astucieusement le motif de conception « proxy », Chrome parvient à isoler les plug-ins en dehors des processus de rendu de la page web. Une source de crashes et de ralentissement des plus importantes se trouve fixé par ce tour de passe-passe qui, espérons le, sera repris par la concurrence.

Pour aller plus loin, je vous recommande l’excellente documentation de Chromium (le projet libre derrière Chrome) ou encore un article de votre serviteur à paraître dans le numéro de Programmez qui sortira à la fin du mois… D’ici là, des questions ?