An adblocker doesn’t necessarily make your web browser load pages faster. The Brave browser introduced a shiny new and more performant adblocking system in late 2019. However, leftovers from its old system have remained in the browser and have quietly held back its performance potential.
I could spend time describing the change with numbers (I do at the end), but let’s look at the bigger picture first. The two flame graphs below show a 475 ms window during a page load with the current stable release build of Brave (top), compared to the new and improved nightly releases (bottom). The colored bars indicate work the browser has to complete to finish the page load. Ignore the minutia of the graphs, just look at the big differences.
Brave version 1.29.81 (current stable release); 475 ms to load a page. The red area at the top indicates how much time the page is unresponsive (e.g. it won’t scroll).
Brave version 1.32.17 (a preview release); showing the same 475 ms period as above. The page takes 81 % less time to load.
The improvement directly translates to faster page loads, less memory usage, more battery time, and a lower carbon footprint. By tiny amounts, of course. However, tiny amounts repeated hundreds of times a day multiplied by 36 million users (self-reported) equals a lot in aggregate.
I discovered the performance problem while I was looking into some performance problems on a project I was working on. I wasted hours optimizing my own code as I had not bothered analyzing the performance results. Once I took the time to analyze the performance results, it turned out — as has been the theme this month — my code performed fine. The problem was with my browser.
I felt kind of stupid for having wasted my own time. I then reported the issue to Brave. Brave’s developers looked into and addresses the performance issue within a few weeks of my initial report.
So, what caused all this extra work that slowed down page loads? The majority of the work came from JavaScript that the Brave browser injected into every page to help its adblocker. Specifically, it was the cosmetic filter — a component responsible for adjusting page layouts to correct for breakages caused by adblocking. Brave’s developers didn’t need to work on the script to improve its performance; they needed to delete it.
It turned out this was just forgotten left-overs of redundant code that slowed down every page load. Brave had already invested the time and resources to improve the performance of its adblocker. It published a blog post to brag about its new and performant adblocking engine (written in the Rust programming language) in late 2019. It had just forgotten to remove the old implementation when it introduced its newer and faster adblocker.
The Brave developers have also completed some other optimization work that contributed to the performance gains. However, the change detailed above is the biggest one. Some improvements have been back-ported to Brave version 31 (current beta), but others are only available in version 32 (nightly previews).
I’ve run 24 performance tests of Brave versions 1.29.81 and 1.32.17 using the built-in browser performance testing tools (48 test runs in total). I used an empty HTML document, and subtracted the network load times from the results. Here are the median results of the two test runs:
- Total blocking/unresponsive time improved from 1460 ms to 70 ms (a 95,21 % reduction).
- Script evaluation time improved from 399,13 ms to 38,27 ms (a 90,41 % reduction). The test page doesn’t contain any scripts, so this is solely from Brave injecting its own.
- The page
loadevent firing time improved from 962,7 ms to 181,2 ms (a 81,18 % reduction). The page load event is the time from the page began loading until the browser considered it done. - Peak JavaScript heap (RAM) consumption improved from 13,9 MB to 3,8 MB (a 72,66 % reduction).
- HTML parsing time improved from 165,28 ms to 49,49 ms (a 70,06 % reduction).
Brave spent a whole second longer to load pages compared to competing web browsers without adblockers installed. Brave slowed down page loads even when you disabled its adblocker. The legacy code ran anyway, even when it wasn’t doing anything.
These results are from testing on a 2018-model Lenovo ThinkPad laptop with balanced battery/performance handling. The timings are almost immeasurably short for the same tests on a high-end desktop computer. Most people use laptops and other low-end devices, so the figures are more representative of the average user.
I haven’t investigated whether this impacts Brave on Android. Brave on Android shares a lot of code with its desktop brethren, but the required performance testing takes a lot more time to complete on the platform.
Update (): An earlier versiom of this article published the wrong figure for the load event timings. (The figure wasn’t corrected for network overhead.) The mistake has been corrected.