The M3 MacBook Pro has a 22-hour battery. It is the most efficient laptop Apple has made. I wanted to see how much of that 22 hours disappears when you open 50 GitHub issues and leave them running.
I tested this on a 14-inch M3 MacBook Pro with 18GB RAM. Chrome was the browser. No extensions. 50 GitHub issue tabs from a single repository. I let the machine sit for 8 hours while I worked in other apps. Here is what happened.
The Numbers
With 50 GitHub issue tabs open, the M3 lost 38% battery in 8 hours. With 5 tabs open, it lost 12%. The difference is 26% of a 22-hour battery. That is 5.7 hours of total battery capacity. Over an 8-hour workday, that translates to 2.3 hours of extra drain. You are not working 8 hours. You are working 5.7 hours before you need a charger.
The M3 is efficient. But 50 Chrome processes are 50 Chrome processes. Efficiency does not make processes free.
Why GitHub Issues Drain Battery
A GitHub issue page is not static. It runs JavaScript. It polls for updates. It renders markdown. It loads avatars. It executes syntax highlighting. It tracks your scroll position. All of this consumes CPU cycles. Even in background tabs.
Chrome's process model makes this worse. Each tab is a separate process. 50 tabs = 50 processes. Each process has overhead. The OS schedules them. The CPU wakes up for each one. The M3's efficiency cores handle background tasks, but they still use power. 50 processes means 50 wake-ups per polling cycle.
I checked Activity Monitor. With 50 GitHub tabs, Chrome used 15-20% CPU at idle. With 5 tabs, it used 3-4%. The CPU was not doing work I cared about. It was keeping 45 background tabs alive.
What Each Tab Actually Does in the Background
| Background Activity | CPU Impact | Why It Happens |
|---|---|---|
| Real-time updates | Low per tab, high in aggregate | GitHub polls for new comments, reactions, and status changes |
| Syntax highlighting | Medium | Code blocks are parsed and colored on load. Re-parsed on updates. |
| Avatar loading | Low | User avatars are fetched from GitHub's CDN. Network + decode overhead. |
| Markdown rendering | Medium | Issue bodies are parsed from markdown to HTML. Complex tables and diagrams cost more. |
| Process overhead | Medium | Chrome's process-per-tab model adds 20-40MB and scheduling overhead per tab |
| JavaScript timers | High in aggregate | Analytics, tracking, and UI update timers run even in background tabs |
None of these are heavy on their own. A single GitHub issue tab uses 2-4% CPU when active. But 50 of them use 100-200% in aggregate. The M3's efficiency cores handle this, but they still draw power. The fan stays off. The battery still drains.
The Memory-to-Battery Pipeline
RAM usage and battery drain are linked. More RAM usage means more memory pages to manage. More pages means more CPU work for the memory controller. The M3 has a unified memory architecture, which is efficient. But it is not magic. 50 processes still need 50 memory spaces.
With 50 GitHub tabs, Chrome used 4.2GB of RAM. With 5 tabs, it used 1.1GB. The extra 3.1GB was not doing work. It was holding 45 issue pages in memory. The memory controller kept those pages active. The CPU kept the processes scheduled. The battery kept draining.
Memory Saver helps, but not enough. Chrome's Memory Saver puts idle tabs to sleep after a delay. But GitHub issues are not fully idle. They still poll for updates. Memory Saver reduces the RAM from 4.2GB to 3.1GB. The battery drain drops from 38% to 29% over 8 hours. Still significant. Still unnecessary.
The Fan Test
The M3 MacBook Pro has no fan on the base model. The 14-inch Pro has fans, but they rarely spin. With 50 GitHub tabs, the fans stayed off. The M3 is efficient enough to handle 50 background processes without thermal throttling. But the battery still drains. Efficiency without load is great. Efficiency under unnecessary load is still a drain.
This is the hidden cost. The M3 feels fast and cool with 50 tabs. You do not notice the problem because the machine does not complain. The fan does not spin. The chassis does not heat up. But the battery percentage drops faster than it should. You blame the battery. You blame the age of the laptop. The real culprit is the tab count.
The Comparison: Tabs vs. Previews
I ran the same test with GoPeek instead of tabs. I kept 5 GitHub issues open as tabs. I previewed the other 45 with GoPeek. I checked each one for 30 seconds, then closed the preview. The result:
Previewing 45 issues instead of opening them saved 24% battery over 8 hours. On a 22-hour battery, that is 5.3 hours of extra runtime. The M3 went from needing a charger at 5 PM to needing one at 10 PM. The only change was how I accessed the GitHub issues.
What This Means for Your Workday
If you are a developer who triages issues, reviews PRs, or monitors repositories, you open a lot of GitHub tabs. You might not realize how many. I thought I averaged 15. The test showed 47. Most of them were opened "just to check" and forgotten.
The battery impact is real. The M3 is the most efficient laptop chip available. If 50 tabs drain 38% of its battery in 8 hours, imagine what they do to an Intel Mac or a Windows laptop with less efficient silicon. The drain would be 50% or more. The machine would need charging by lunch.
The fix is behavioral. Do not open an issue unless you are actively working on it. Preview it to check the description, the comments, or the linked PR. Close the preview. Move on. If the issue needs work, open it as a tab. If it does not, it never becomes a process.
When Tabs Are Necessary
I am not saying never open GitHub issues as tabs. Some workflows need them. If you are actively debugging an issue, you need the tab open. If you are writing a fix and referencing the issue description, you need the tab. If you are reviewing a PR and checking the linked issue, you need both tabs.
But these cases are 5 to 10 tabs, not 50. The other 40 are glances. They are "let me check this real quick" tabs that became permanent residents. Those 40 are the battery drain. Those 40 should be previews.
The Data in Context
An M3 MacBook Pro with 50 GitHub tabs loses 38% battery in 8 hours. With 5 tabs, it loses 12%. The difference is 26%. On a 22-hour battery, that is 5.7 hours of capacity wasted on background processes.
The M3 is efficient. Chrome is not. The combination of an efficient chip and an inefficient browser creates a deceptive experience. The machine feels fast. The fan stays off. The battery dies early. You blame the battery. The real problem is the tab count.