Most of us have seen the numbers: according to benchmarks, Firefox is faster than Chrome. Sadly, that is sometimes hard to believe, as our eyes often indicate the opposite. The good news is that Firefox really is very, very fast. However, this is misleading: what our eyes notice is not speed (an indication of how much time an operation takes to complete) but smoothness (an indication of how often we have refreshed the screen in the meantime). And on that domain, on many pages, we are still lagging behind Chrome.

In this series of blog entries about the subject, I plan to introduce the issues and discuss the solutions that are envisioned.

How browsers work

Let’s start by a short refresher about how browsers work. All current browser engines (except Servo) share the same overall behavior:

function browser() { while (true) { handleEvents(); // <-- Your code goes here updateDisplay(); } }

Function handleEvents() handles all the system-specific event handling (“oh, it looks like the mouse has moved”, “some time has passed”, “the http request is complete”) and dispatches this to all higher-level code designed to provide the user experience (“call onmousemove “, “add something to the history menu”, “capture thumbnail”, “call XMLHttpRequest callback”, …). Whether you are writing back-end code, front-end code, an add-on or even web-side JavaScript, unless you are part of the Layout team, chances are that your C++ or JavaScript code is executed somewhere in handleEvents() and your CSS is executed in updateDisplay() .

To ensure perfect smoothness, updateDisplay() must be called at least 30 times per second, preferably 60. This means that the whole loop should be executed in roughly 15ms, which is pretty short. This is a problem that hits all browsers and we have a number of techniques to fit our code in this limit. As I am not a member of the Layout team, I will concentrate on the code that runs in handleEvents() .

So, we need to make handleEvents() faster. Can we optimize it? Certainly we can. However, recall that benchmarks suggest that Firefox is already the fastest browser around, and this is not sufficient. Perhaps we can improve that speed by a few percents, but that is not the best course of action.

We need to go the other way: handleEvents() must do less things.

In the following parts of this series, I will explore several options: going multi-process, multi-thread, or interruptible. If I have time, I will also discuss Servo, Mozilla’s next-generation rendering engine.