Memory Savings in Brave: 33% to 66% memory reduction over Chrome

by | Feb 15, 2019 | Performance, Press, Research

This research was conducted by Dr. Andrius Aucinas, performance researcher at Brave, and Dr. Ben Livshits, Brave’s Chief Scientist.

We are continuing our series of posts evaluating Brave browser’s performance. This time we look at one aspect that often frustrates web users: the browsers’ memory consumption. Also, the virtue of aggressive blocking. Modern browsers have become fairly streamlined a standard version of Google Chrome browser barely takes more than 200 MB of memory. However, websites have grown in complexity and resource use, an effect exacerbated by ads and trackers. We discover that Brave delivers an impressive 33% to 66% memory reduction over a vanilla Chrome measured on a browser with a typical number of open tabs.


We compared Chrome (v. 71.0.3578.98) running with no blocker, Chrome with AdBlock Plus (v. 3.4.0) as well as uBlock Origin (v. 1.17.0_0), and Brave (v. 0.58.21, with underlying Chromium v. 71.0.3578.98). All extensions were used with default settings, because users tend to stick to defaults. We ran all tests on a powerful macOS laptop, MacBook Pro (2018) with an Intel Core i7 6-core CPU and 32 GB RAM, to ensure that our measurements are not skewed by memory backpressure of the underlying system. We then also verified the results using an older MacBook Air laptop (mid 2012) with a dual-core CPU and 4 GB RAM for a measure that is more representative of an average desktop user.

Although we generally use tools like Web Replay Proxy to eliminate page variations across test runs, such tools have shortcomings when it comes to deterministically replaying non-deterministic content, where we have observed a small number of requests failing. For this study we therefore used live versions of the websites, re-running each experiment several times to check for variance.

Finally, we are huge fans of GDPR in Europe. However, the additional friction of the consent requests does impact the user experience, and the default tracking that happens on the web. To provide a more complete picture, we ran our tests from both a UK business IP address as well as US IP address over VPN (the VPN exit node was hosted in a US region of AWS). Although AWS IP addresses can sometimes be blocked by various publishers to prevent automated web scraping, we did not observe any such cases across our chosen set of sites.

For memory measurements we relied on Chromium’s tracing tools, specifically, browser startup tracing, running the browser with a few flags disabling features that can add variance but which are not important for our tests. What the different options do is primarily disable chromium features that may cause unpredictable behavior, such as updating safe browsing rules in background:

    --user-data-dir=./new-user-profile \
    --trace-config-file=./trace.config \
    --safebrowsing-disable-auto-update \
    --disable-background-networking \
    --disable-dev-shm-usage \
    --disable-hang-monitor \
    --disable-breakpad \
    --no-first-run \
    --enable-automation \

Memory tracing itself is controlled by the contents of trace.config file:

  "startup_duration": 31,
  "result_file": "/tmp/trace.json",
  "trace_config": {
    "included_categories": ["disabled-by-default-memory-infra"],
    "excluded_categories": ["*"],
    "memory_dump_config": {
      "triggers": [
        { "mode": "light", "periodic_interval_ms": 5000 },
        { "mode": "detailed", "periodic_interval_ms": 10000 }

In essence, this tracing setup disables all other tracing but memory, to minimize overheads of tracing itself, and collects “light” as well as “detailed” memory dumps every 5 and 10 seconds respectively. Periodic memory dumps let us observe how memory changes during the duration of a test instead of providing only a one-off snapshot important to see in case it peaks earlier in the process.

Finally, we record for 31 seconds (just over the limit to collect 3 detailed memory dumps), giving the browser enough time to load all the pages, run any garbage collection and generally reach “quiescence”. The above illustration provides an example of how memory use grows throughout a single test as rendered by Chromium’s trace viewer (chrome://tracing).

The different colors indicate memory used by individual components (e.g., rendering engine, JS engine, web caches, dynamically allocated memory…), but they add up to total memory used by the browser at a given point in time. Tracing overheads as recorded by the tool itself were between 50 MB and 100 MB relatively small and varying little across the different configurations.

It is worth noting that we looked at using an automated, Developer Tools Protocol-driven approach for more complex user interaction sequences. However, with that setup, even simple page loads without additional interactions were yielding both much higher memory use numbers and large variations of memory use across subsequent runs. We therefore focused on the simple usage patterns in this case for repeatability.

Top-level memory usage differences

Out of the box Brave uses only slightly more memory than a vanilla Google Chrome due to additional functionality of built-in ad blocking and user rewards, for example. Another built-in extension as we wrote earlier is PDF.js for PDF document rendering instead of Chrome’s PDFium due to its frequent security problems. All in all, when a browser hasn’t loaded any external pages this adds about 70 MB of memory on top of standard Google Chrome, however the cost becomes negligible compared to the savings with just a handful of pages loaded.

Selecting the Benchmarks

The worksets measured in the above figure are collected from a few notoriously bad publishers overloading their sites with ads and trackers, as well as a fairly arbitrary set of articles, documents, and, of course, a weather forecast.

GDPR for Speed

Only one website,, did not display when browsing from a UK address due to regulatory issues. While this contributed to the large memory use differences between UK and US versions, a separate measurement with LATimes excluded still showed a 15% difference between UK and US versions on Chrome.

  • Well-implemented ad blocking can deliver 33% – 66% memory savings or 500 MB to as much as 1.9 GB across just 10 pages open
  • Not all ad blockers are created equal both Brave and uBlock Origin are much more aggressive than AdBlock Plus with default settings, yielding much higher savings
  • Regulation plays a surprisingly big role not only in privacy protection but also performance of the web

Detailed look at memory use differences

Explaining the Differences

The huge difference between AdBlock Plus and Brave or uBlock Origin comes from different default rules applied. For example, the default settings for AdBlock Plus enable only the EasyList and Anti-Circumvention filter lists for ad blocking, while also enabling the lengthy “Acceptable Ads” exceptions list of third party ads and trackers that both uBlock Origin and Brave block by default. Although AdBlock Origin is able to use additional rules, the Guardian has previously reported that only 8% – 10% of AdBlock Plus users opt-out of “acceptable ads”, making this the more important scenario for testing.

Third-party content such as ads and trackers often run in isolated subframes within a page. This limits potentially harmful interaction between content and such scripts. Chrome’s multiprocess architecture means they often also run on separate processes, providing further security and performance isolation, but also allows us to better quantify their overheads. In both worksets, we found a few third-party subframes present across all browser and ad-blocker combinations. Those included first-party widgets (e.g. CNN’s podcasts) as well as third-party tools such as Twitter’s or Facebook’s social sharing widgets arguably trackers, though ones that can’t be safely removed without breaking a website’s functionality. (Brave’s cookie + local storage blocking helps to greatly reduce the attack surface here.)

Tracing in Chromium attributes memory to individual processes; however, multi-process usage in Chromium itself is rather complex. It is well outside the scope of this article, but suffice it to say that for efficiency, the main frame of the page is sometimes allocated to the same process as its subframes, especially when they come from the same origin. Nevertheless, we define “blockable subframes” as ones that are not present in at least one other tested configuration, because in each case the pages were fully functional, with only ads removed. Represented in red color in the charts, they cover a large part of the memory savings achieved.

The fixed cost of the browser, the GPU process as well as any unnamed renderer processes typically running any extensions, are shown in black. This also covers the most direct cost of the ad blocking extensions, such as memory used for the block lists. Measuring only the specific extension processes would, however, miss part of the picture, both because part of Brave’s ad blocking functionality is within the core browser engine, but also because there are differences in the memory used at this core depending on the content rendered even without any extensions, although it is difficult to attribute memory use in more detail.

The green part in the graphs covers memory used by entities running on the processes tagged as running the main page content. It also, however, included some third-party subframes, albeit ones fairly deeply integrated. Specifically, the difference of 368 of memory between uBlock Origin and Brave in workset 2 can be attributed to just three pages,, and where trackers did not get caught by the filter rules.

Tracing Log Analysis

Carefully analysing the logs we discovered a few trackers that tend to slip through:

  • InstartLogic, running off first-party subdomains and generally offering features beyond tracking. Found on and
  • by AppNexus, a large platform for tracking ad targeted advertising, again found on and Covered in more detail by The Guardian
  •, an advertising exchange that tracks users and offers targeted advertising. Casale Media does not appear to have a big impact on memory use however

A rather peculiar observation is that even though AdBlock Plus is a very popular ad blocker that removes some of the advertising, it does result in higher memory use overall. That comes down to three factors: the extension itself having non-trivial overheads, not enough of the bad content (through omissions or explicit exceptions) getting blocked, and similarly to the above case some memory-heavy trackers getting embedded in the pages when viewed with the ad-blocker on, namely InstartLogic and Adnxs.

In addition to demonstrating the virtue of strong privacy protection through this testing, we’ve also proven that those privacy benefits lead to significant memory savings. Brave catches more ads and trackers than others and simply prevents them from running. Nevertheless, we also discovered a tracker during this analysis ( which provides questionable value for the end-user and will be blocked in the future.

Effects of a less powerful device

Curious to see how the browser behaves when it does not have all-you-can eat memory on the menu we turned to the MacBook Air with 4 GB RAM, from a UK network connection. To take into account significantly longer load times we have also had to increase tracing time to 90 seconds in line with the above setup, to allow the browser to reach “quiescence”. We focused on workset 2 as the heavier one, which previously used 2-3 GB RAM alone and would not fit in the memory left available aside system processes.

The figure illustrates our results: the browser used a few hundred megabytes less memory when loading the entire workset due to more aggressive garbage collection, but the 27% saving of Brave over Chrome is close to what we have observed before. The overall lower memory footprint when compared to a more powerful machine is deceptive. On the slower machine, all browser configurations are 4x to 5x slower to start and load all pages in the workset. This means for example an increase from 5s to 23s with Brave or 11s to 51s increase with Chrome to load the pages – the time the person has to wait for a page to load multiplies!

Curiously, Brave here used more memory than Chrome with uBlock Origin, pointing to adverse reaction to some website in the workset. Indeed, alone contributed significant overheads as well as the previously observed InstartLogic subframes not being present. Excluding confirms that, delivering 53% savings over Chrome’s baseline and pointing to an important area of work in the ad-blocking arms race: performance and adverse site behaviour with blocking present.

In our synthetic experiments we did not measure how memory pressure affects user interaction speed across the loaded pages or other programs running on the same machine, however even with the browser more eagerly preserving memory we still observe memory savings in the order of 500-840 MB very noticeable on a machine that only has 4 GB in total.

Blocking Effectiveness and Privacy Effects

Since we saw that the bulk of the savings come from aggressive ad and tracker blocking, we also looked at blocking differences across a wider set of pages. Measuring the number of distinct 3rd-party domains which were hit has been advocated as a better metric than the number of resources blocked for comparison of privacy protecting efficiency, but in our case it also serves as an indicator of expected memory savings as detailed above.

We used a list of 84 websites proposed by uBlock Origin as a reference benchmark. For this experiment, we ran all tests from a US IP address via AWS. Each page was loaded 3 times and the measurement with median load time was retained for analysis. A small number of websites failed to load, so we ended up with 78 sites. Since AdBlock Plus tends to be worse than either Brave or uBlock Origin, as well as Chrome with no blocking in terms of memory use, we exclude it from this analysis.

Aggregating the number of distinct 1st-party/3rd-party pairs, we ended up with:

  • Chrome 3,589 pairs
  • Chrome + uBo 864 pairs
  • Brave 730 pairs

Brave is therefore slightly more aggressive at blocking. On a per-site basis the difference is not huge, however 1 additional third party (1.7 on average) allowed through adds up to additional memory as detailed above for an occasional especially bad site alone it can mean and additional 300-350 MB of memory. This chart compares the number of distinct origins contacted when loading each of the 78 sites.

All in all, in percentage terms, the difference in the average number of third-party domains contacted is 15.5%, or 11% in the median case. This adds up to 134 additional pairs of first-party/third-party domains contacted across just 78 tested sites when compared to the next-best ad blocker.


In this post we demonstrate that Brave’s privacy benefits from ad-blocking go hand-in-hand with performance improvements. Specifically, a well-implemented ad blocker can deliver 33% to 66% memory savings or 500 MB to as much as 1.9 GB across just 10 pages open in a single session.

Most ad-blockers currently use huge lists of rules for resources that should be blocked and their differences spawn primarily from that. And while the story of user privacy is key in that picture, we demonstrate that performance is just as important, where minor differences between lists can yield 7% (79 MB) to a whopping 28% (368 MB) memory saving!

Across a wider set of news websites we frequently observed such minor differences between Brave and one of the best in class blockers, uBlock Origin. Just one or two additional third-parties allowed through can result in a big hit on memory use, therefore the extra effort in aggressively blocking them also improves performance for the users.

A rather peculiar discovery is the role of data privacy regulation on web performance, as we find that sites loaded from a UK address end up being lighter than exactly the same sites loaded from a US address, especially with no blocking applied. It demonstrates that publishers as well as any other parties in the open web still have work to do in improving the web and making it accessible to everyone, although we have plans for that as well.

Related Articles

Continue reading for news on ad blocking, features, performance, privacy and Basic Attention Token related announcements.

Brave Launches the First Advertising Platform Built on Privacy

With 70% revenue share to users, Brave Ads deliver effective advertisingwhile giving users privacy and control Starting today, users of Brave’s latest release of the desktop browser for macOS, Windows, and Linux can choose to view privacy-preserving Brave Ads by...

Brave Rewards on Android

Brave Rewards now in Brave Android App Brave Rewards is now available in the latest version of Brave for Android (1.0.91). To download it on your device, please visit the Google Play Store. Brave Rewards is the new way to help fund content on the Web while blocking...

Brave Sync Now Available for iPhones and iPads

Brave Sync is now available in today’s Brave for iOS release (version 1.9). Already a feature in the Brave desktop browser and Brave for Android app, Brave Sync for iOS enables users to automatically sync browsing data between devices running the Brave browser. Brave... Now Live

New Website for the BAT Community and Online Creators Features Latest News, Technical Tools, Promotions, and Global Meetup Groups

Ready to Brave the new internet?

Brave is built by a team of privacy focused, performance oriented pioneers of the web. Help us fix browsing together.
Download Brave

Join the Newsletter






Brave San Francisco

512 Second St., Floor 2
San Francisco, CA 94107

Brave London

Mindspace Shoreditch
9 Appold St
London, EC2A 2AP