Nav0 vs Chrome: A Head-to-Head Performance Benchmark on macOS

March 4, 2026 · 11 min read

We talk a lot about how modern browsers are bloated. But talk is cheap. So we decided to actually measure it.

We ran a controlled, head-to-head performance comparison between nav0 v0.0.6 and Google Chrome v144.0.7559.133 on a MacBook Pro with an Apple M1 chip. We tested with 10, 20, 30, 40, and 50 open tabs, measuring memory consumption, CPU usage, and process count at each step.

The results weren't even close.

The Results

Before we get into methodology, here are the numbers. Every test was run on the same machine, with the same websites, under the same conditions.

Memory Usage

Tabs	Chrome	Nav0	Difference
10	1,551 MB	1,247 MB	-304 MB (-19.6%)
20	4,441 MB	2,461 MB	-1,980 MB (-44.6%)
30	6,938 MB	3,755 MB	-3,183 MB (-45.9%)
40	8,251 MB	4,345 MB	-3,906 MB (-47.3%)
50	10,076 MB	4,294 MB	-5,782 MB (-57.4%)

At 50 tabs, Chrome consumed over 10 GB of memory. Nav0 used 4.3 GB. That's a 57.4% reduction — nearly 6 GB of RAM saved.

And notice the scaling pattern. Chrome's memory usage grows almost linearly with tab count: roughly 200 MB per tab. Nav0's memory growth flattens significantly after 30 tabs, barely increasing between 40 and 50 tabs. At 50 tabs, nav0 actually used slightly less memory than at 40 tabs (4,294 MB vs 4,345 MB), suggesting that its resource management actively adapts to constrained conditions.

Average across all tests: Chrome 6,251 MB vs Nav0 3,220 MB — nav0 uses 48.5% less memory.

CPU Usage

Tabs	Chrome	Nav0	Difference
10	29.5%	8.0%	-21.6 pts (-73.0%)
20	14.6%	9.1%	-5.5 pts (-37.7%)
30	141.2%	11.8%	-129.3 pts (-91.6%)
40	187.7%	12.0%	-175.8 pts (-93.6%)
50	101.7%	24.4%	-77.3 pts (-76.0%)

CPU percentages over 100% mean multiple cores are being saturated. At 40 tabs, Chrome was consuming nearly 188% CPU — pinning almost two full cores just to keep idle tabs alive. Nav0 at the same tab count: 12%. That's not a typo.

Chrome's CPU behavior was also erratic. It swung from 14.6% at 20 tabs to 141.2% at 30 tabs, suggesting heavy background processing that kicks in unpredictably. Nav0's CPU usage remained remarkably flat and predictable across every tab count, only ticking up modestly at 50 tabs.

Average across all tests: Chrome 95.0% vs Nav0 13.1% — nav0 uses 86.3% less CPU.

Process Count

Tabs	Chrome	Nav0	Difference
10	67	22	-45 (-67.2%)
20	90	34	-56 (-62.2%)
30	103	43	-60 (-58.3%)
40	112	53	-59 (-52.7%)
50	120	62	-58 (-48.3%)

With just 10 tabs open, Chrome spawned 67 processes. Nav0 ran with 22. Every additional process means additional memory overhead, additional context switches, and additional CPU scheduling work for your operating system.

Chrome's process-per-tab architecture, combined with its various utility processes (GPU, network, storage, audio, extension service workers, renderer processes), means the process count scales aggressively. Nav0's architecture keeps process count substantially lower while still maintaining tab isolation where it matters.

Testing Methodology

We're engineers, not marketers. We didn't cherry-pick numbers to make ourselves look good. Here's exactly how the tests were run so you can reproduce them yourself.

Hardware and Software

• Machine: MacBook Pro with Apple M1 chip, 8 CPU cores, 16 GB RAM
• OS: macOS (Darwin arm64)
• Chrome: v144.0.7559.133, launched with a fresh temporary profile
• Nav0: v0.0.6, launched with default settings
• Node.js: 18+ with puppeteer-core for Chrome automation

Test Design

Each browser was tested at five tab counts: 10, 20, 30, 40, and 50. For each tab count, the test followed this exact sequence:

1. Clean launch. Kill any existing instance on the debug port. Launch the browser fresh with no prior state.
2. Open tabs. Navigate to real-world websites sequentially. Each tab loads an actual page — no blank tabs, no synthetic pages.
3. Settle period (8 seconds). After all tabs are open, wait 8 seconds for the browser to finish background work like rendering, JavaScript execution, garbage collection, and service worker initialization.
4. Measurement period (5 seconds). Sample CPU and memory over a 5-second window, then average the results.
5. Clean shutdown. Kill the entire process tree and wait 3 seconds before the next test.

Both browsers were tested back-to-back for each tab count, meaning they experienced the same system conditions. Chrome was always tested first, then nav0, for every tab count.

The Test URLs

We didn't just load about:blank fifty times. The test rotated through 15 real-world websites spanning three weight classes:

Light pages — minimal JavaScript, mostly text:

• Hacker News, CNN Lite, NPR Text, Wikipedia, Craigslist

Medium pages — moderate JavaScript, standard web apps:

• MDN Web Docs, GitHub Docs, Stack Overflow, npm, GitHub Explore

Heavy pages — complex JavaScript, video, dynamic content:

• Reddit, YouTube, BBC News, CNN, Twitch

Tabs cycled through these 15 URLs in order, so at 50 tabs each URL was loaded at least three times. This ensures the benchmark reflects realistic browsing patterns, not synthetic best-case scenarios.

How We Measured Memory

This is important because memory measurement in browsers is notoriously tricky to get right.

We used macOS's footprint command, which reports the physical footprint of a process — the same number you see in Activity Monitor's "Memory" column. This is the gold standard for memory measurement on macOS because it correctly handles shared memory.

Why does this matter? Browsers spawn dozens of subprocesses that share memory-mapped libraries. If you naively sum the RSS (Resident Set Size) of every process, you double-count shared memory and get an inflated number. The footprint command avoids this by attributing shared memory to only one process, giving an accurate picture of the browser's true memory impact on the system.

For each measurement, we:

1. Built the complete process tree starting from the root browser PID, recursively collecting all child processes via pgrep -P.
2. Passed every PID in the tree to the footprint command.
3. Parsed the output for Physical footprint or phys_footprint values, handling both human-readable units (K, M, G) and raw byte counts.
4. Summed the physical footprint across all processes.

If footprint was unavailable for any reason, the script fell back to RSS summation with a warning — but on macOS, footprint was always available and always used.

How We Measured CPU

CPU was sampled using ps -o %cpu= for every process in the browser's process tree. We sampled once per second for the full 5-second measurement window, collecting the total CPU percentage across all subprocesses at each sample, then averaged across all samples.

CPU percentages are reported as they appear on macOS: 100% means one full core is saturated, 200% means two cores, and so on. This is consistent with what Activity Monitor and top report.

How We Built the Process Tree

Both Chrome and nav0 spawn child processes — renderers, GPU processes, utility workers, etc. To capture the full resource picture, we recursively walked the process tree from the root PID:

1. Start with the root browser PID (the PID of the process we launched).
2. Use pgrep -P <pid> to find all direct children.
3. Recurse into each child to find grandchildren, and so on.
4. Collect every PID in the tree for measurement.

This ensures we're measuring the complete browser footprint, not just the main process. Chrome in particular has a complex multi-process architecture with many types of subprocesses, and missing any of them would undercount its resource usage.

Chrome Test Setup

Chrome was launched via command line with these flags:

• --remote-debugging-port=9222 — enables the Chrome DevTools Protocol for tab automation
• --user-data-dir=<temp> — uses a fresh temporary profile, no extensions, no cached data
• --no-first-run — skips the first-run setup dialog
• --no-default-browser-check — skips the "make Chrome your default" prompt
• --disable-default-apps — no pre-installed apps
• --disable-extensions — no extensions loaded
• --disable-background-networking — reduces background network activity

Tabs were opened using Puppeteer via the Chrome DevTools Protocol. Each tab was navigated with waitUntil: 'domcontentloaded' and a 20-second timeout.

Note: Chrome was tested with extensions disabled and background networking turned off. This is a favorable configuration for Chrome — in real-world usage with extensions, syncing, and background services active, Chrome's resource usage would be even higher.

Nav0 Test Setup

Nav0 was launched with the REMOTE_DEBUGGING_PORT environment variable set, which activates a lightweight HTTP control server for test automation. Tabs were created via HTTP POST requests to http://127.0.0.1:9229/create-tab?url=<encoded-url>.

Nav0 was launched with its default configuration — no special flags to reduce resource usage. What you see in the benchmark is what you get when you use nav0 normally.

What We Didn't Do

Transparency matters, so here's what this benchmark does not test:

• Page load speed. We measured idle resource consumption, not how fast pages render. That's a different benchmark.
• JavaScript performance. We didn't run Speedometer, JetStream, or other JS benchmarks. Both browsers use variants of the V8/Chromium engine, so JS execution speed is similar.
• Extension impact. Chrome was tested with extensions disabled. Real-world Chrome with uBlock Origin, password managers, and other extensions would use even more resources.
• Long-running sessions. Each test was a fresh launch. We didn't measure memory leaks over hours of browsing, which is a known issue with Chrome.
• Multiple runs for statistical significance. This was a single run at each tab count. The numbers could vary slightly between runs, though the magnitude of the differences makes the conclusion robust.

We plan to publish follow-up benchmarks covering these areas. The test script is open source in our repository — you can run it yourself and verify our results.

Why Nav0 Is More Efficient

These numbers raise an obvious question: how is nav0 so much lighter?

The answer isn't one magic trick — it's what happens when you build a browser without the baggage that Chrome has accumulated over 18 years of feature creep.

No Telemetry Overhead

Chrome runs a constant stream of background processes for Safe Browsing checks, usage statistics, component updates, field trial configurations, and sync services. Every one of those processes consumes memory and CPU cycles. Nav0 has zero telemetry. No data is collected, no data is sent, no background processes exist to manage data that doesn't exist.

No Bloat Features

Chrome ships with a built-in PDF viewer, a translation engine, a password manager, an autofill system, a payment handler, a media router (Chromecast), a reading list, a side panel, a tab groups manager, shopping integrations, and most recently, a suite of Gemini AI features. Each of these is a subsystem with its own processes, memory allocations, and CPU cycles.

Nav0 is a browser. It browses the web. That's it. Fewer features means fewer processes, less memory, and less CPU.

Leaner Process Architecture

Chrome's multi-process architecture was groundbreaking in 2008. But it has grown increasingly complex, with separate process types for renderers, GPU compositing, network, storage, audio, utility workers, extension service workers, and more. With 10 tabs, Chrome spawned 67 processes — nearly 7 processes per tab.

Nav0 achieves tab isolation with significantly fewer processes. At 10 tabs, it used 22 processes — about 2 per tab. The result is less memory overhead, fewer context switches, and less OS scheduling pressure.

Efficient Resource Management at Scale

Perhaps the most striking result is how nav0 scales. Chrome's resource usage grows roughly linearly — each additional tab adds a relatively fixed amount of memory and CPU. Nav0's resource growth flattens at higher tab counts, suggesting active resource management that adapts as the number of tabs increases.

At 50 tabs, nav0 used less memory than at 40 tabs. Chrome at 50 tabs used 22% more memory than at 40. The gap between the two browsers widened as tab count increased, from 19.6% at 10 tabs to 57.4% at 50 tabs. If you're someone who keeps a lot of tabs open — and let's be honest, that's most of us — the difference is dramatic.

What This Means for You

If you're running a machine with 8 GB or 16 GB of RAM, Chrome with 30+ tabs can push your system into swap territory, grinding everything to a halt. Nav0 at 50 tabs uses less memory than Chrome at 20.

If you're on a laptop, CPU usage directly translates to battery life. Chrome pinning nearly two full CPU cores at 40 idle tabs means your fans are spinning and your battery is draining — for tabs you're not even looking at. Nav0 at the same tab count barely registers on the CPU meter.

If you care about system responsiveness, fewer processes means less OS overhead. Chrome's 120 processes at 50 tabs compete with every other application on your system for scheduling time. Nav0's 62 processes at the same tab count leave more headroom for the rest of your work.

Try It Yourself

The test script is open source in our repository. If you have a Mac with Chrome and nav0 installed, you can reproduce these results in about 15 minutes. We believe in showing our work, not just making claims.

The numbers speak for themselves. Nav0 isn't just a little lighter than Chrome — it's a fundamentally different approach to building a browser. No telemetry tax, no feature bloat, no background processes doing work you never asked for.

Your computer's resources should go toward the things you're actually doing, not toward feeding a data pipeline you didn't sign up for.

Download nav0 — free, open source, and light on your system.

---

nav0 is a minimal, open-source browser built on one principle: your browser should work for you, not for an ad company. Zero telemetry. Zero bloat. Zero BS. Learn more.