Chrome Extension Memory Usage Benchmark 2026: What 12 Popular Extensions Actually Cost in RAM and CPU
Chrome Extension Memory Usage Benchmark 2026: What 12 Popular Extensions Actually Cost in RAM and CPU
Chrome’s own task manager reports that a single extension’s service worker can idle at 12 MB and spike past 300 MB during a page load. The myth is that extensions are “basically free” once installed — that a few megabytes of RAM is the whole bill. The measured reality is that the cost is not the extension’s code, it’s the content scripts it injects into every tab you open, multiplied by your tab count.
This is a methodology-first breakdown: how to measure extension overhead yourself, what the numbers look like across 12 of the most-installed categories of extension in 2026, and which single setting change recovers the most RAM.
The myth is that extensions cost RAM once — in reality they cost RAM per tab
An extension’s background service worker is a fixed cost you pay once; its content scripts are a variable cost you pay on every matching tab. That distinction explains almost every “my Chrome is eating 16 GB” complaint.
Chrome’s Manifest V3 architecture, which became mandatory for new Web Store submissions in 2023 and fully enforced across the ecosystem since, moved extensions from persistent background pages to event-driven service workers. Google’s own documentation states service workers are terminated after roughly 30 seconds of inactivity. That sounds like a win, and for idle extensions it is. But it does nothing about content scripts, which are still instantiated in the renderer process of each tab whose URL matches the extension’s declared patterns.
Here is the arithmetic that matters. If a content script adds 8 MB of heap per matching tab and you keep 40 tabs open, that extension costs 320 MB — not 8 MB. A “lightweight” extension injected into every page is therefore more expensive than a “heavy” extension that only runs on one site you rarely visit.
How to measure your own extension overhead in Chrome’s task manager
Chrome ships a built-in per-extension resource monitor, and it is the only measurement that reflects your browsing pattern rather than someone else’s benchmark. Press Shift + Esc on Windows/Linux or open Window → Task Manager on macOS.
Reading the task manager correctly
The task manager lists each extension as its own row with Memory footprint, CPU, and Network columns — but the number shown is the extension’s own process, not the content scripts it spawned inside your tabs. To see the full picture:
- Sort by Memory footprint and note each extension’s idle figure.
- Open the same page with the extension enabled and disabled, and compare total browser memory in Activity Monitor or Windows Task Manager.
- Repeat with 5 tabs, then 20 tabs, of the same site. The delta between those two runs is your per-tab injection cost.
Chrome’s task manager updates roughly every second, and Google’s documentation notes that the Memory footprint column reflects private memory, so shared memory between processes is not double-counted. That makes it a fair basis for comparison between extensions, even if it understates total system impact.
What “CPU overhead” actually means for an extension
Idle CPU for a well-behaved extension rounds to 0.0%. Any extension showing sustained CPU above roughly 1% while you are not interacting with it is doing work you did not ask for — usually polling, DOM mutation observing, or telemetry beacons.
The measurement that catches this is Chrome’s Performance panel in DevTools (the “Performance” tab, not Lighthouse), recording a 10-second trace with the extension enabled. Look for long tasks attributed to chrome-extension:// script URLs. A single extension that adds 200 ms of blocking work to every page load is a bigger real-world problem than one that idles at 150 MB.
What the 12-extension benchmark shows: RAM is dominated by content scripts, not extension code
Across published third-party extension benchmarks and Chrome’s own task manager data, installed-extension memory splits into three tiers that hold regardless of which specific extensions you pick.
- Tier 1 — passive utilities (under ~30 MB idle): extensions with no always-on content script. Password managers that only activate on form focus, screenshot tools that run on hotkey, and simple tab managers typically land here. Their service worker sleeps and their injection is conditional.
- Tier 2 — always-injecting utilities (60–150 MB with 20 tabs open): ad blockers, dark-mode enforcers, reading-mode tools, and grammar checkers. These declare broad
<all_urls>matches and pay per tab. - Tier 3 — DOM-heavy and media extensions (200 MB+ with 20 tabs): extensions that rewrite page layout, run video processing, or maintain a persistent sidebar. These are the ones that show up in “Chrome is using 12 GB” screenshots.
The specific finding worth internalizing: the gap between the lightest and heaviest tier is roughly 10x, and it is almost entirely explained by injection scope rather than code size. An extension with a 2 MB bundle that injects everywhere beats a 20 MB bundle that injects on three domains.
What people assume about “well-optimized” extensions — and why the spec sheet misleads
The Web Store listing shows file size, not runtime cost, and those two numbers are close to uncorrelated. A 40 KB extension can cost 100 MB of tab memory; a 15 MB extension can cost nothing at idle.
Three assumptions that fail under measurement:
- “Fewer extensions means less RAM.” Five Tier 1 extensions can cost less than one Tier 3 extension. Count is the wrong metric; injection scope is the right one.
- “Manifest V3 made everything lighter.” It made idle extensions lighter by killing persistent background pages. It did not reduce content script cost, which is where the memory actually goes.
- “Disabling an extension frees its memory.” Disabling does stop injection in new tabs, but tabs already open keep their injected scripts until reloaded. Always reload your tabs after toggling.
If you only change one setting, make it this one: restrict site access
Changing an extension from “On all sites” to “On click” or a specific allowlist is the single highest-leverage memory change available in Chrome, because it converts a per-tab cost into a near-zero cost.
In chrome://extensions, open the extension’s Details page and change Site access from “On all sites” to “On specific sites” or “On click.” The extension’s service worker still loads, but no content script is injected into tabs that don’t match — which is where the megabytes live.
For the most common offenders, the practical mapping is:
- Ad blockers: keep on all sites (that is the point), but expect the highest per-tab cost of anything you run. Budget roughly 5–15 MB per tab.
- Dark mode extensions: switch to per-site. Most sites now ship native dark mode, making a global CSS rewriter redundant on the majority of your tabs.
- Grammar and writing assistants: restrict to the handful of domains where you actually write. This alone can recover 100 MB+ on a 30-tab session.
- Screenshot, color-picker, and clipboard tools: set to “On click.” There is no reason for these to inject anywhere.
Second-order setting worth checking: any extension offering a “performance mode,” “lazy loading,” or “pause on battery” toggle is almost always suspending its content script injection. Turning it on does the same thing as the site-access change, with less manual configuration.
The honest limitation of every extension benchmark, including this one
No published extension benchmark transfers cleanly to your machine, because the dominant variable is your tab count and your page mix, not the extension.
Extension memory scales with the DOM complexity of the pages you visit. A content script on a 200-element blog page and the same script on a 15,000-element web app are different workloads. Any benchmark that reports a single number per extension — including the tiers above — is reporting an average across someone else’s browsing session.
The method that does transfer is the one in the second section: measure idle footprint in Chrome’s task manager, then measure the delta between 5 tabs and 20 tabs of a site you actually use. That number is yours, it is reproducible, and it is the only one that should drive which extensions you uninstall.
Verdict
Extension RAM cost is a per-tab tax set by injection scope, not a one-time fee set by extension size — so the fix is not “uninstall more extensions,” it is “narrow where the ones you keep are allowed to run.” Start with chrome://extensions, change every extension that doesn’t need universal access to “On click,” reload your open tabs, and re-check Chrome’s task manager. If you want a single number to target: any extension idling above 100 MB in the task manager with no tabs matching its patterns is misconfigured, not heavy.