Feature • Energy & Computing
Every pixel rendered, every script executed, every network packet fetched — your browser is quietly draining your battery one open tab at a time. We spent three months profiling real-world web pages to find out just how expensive modern browsing has become.
It began with a simple observation: leave a dozen browser tabs open for an hour and a half of laptop battery disappears before you've typed a word. The culprit, most people assume, is streaming video or some misbehaving cryptocurrency ticker widget. The reality, as we discovered after months of rigorous profiling, is far more diffuse — and far more interesting.
Modern web pages are not documents. They are applications, and the distinction matters enormously once you start counting joules. A static HTML page from the early web consumed perhaps 50–80 milliwatts during active reading. Today's median news article, laden with third-party analytics scripts, autoplay video previews, and real-time personalisation pipelines, regularly clocks in at 400–900 milliwatts. That's a tenfold increase in twenty-five years, even as the underlying hardware has become dramatically more efficient.
Our methodology drew from a combination of hardware-level instrumentation and browser-side profiling. For hardware measurements, we fitted test laptops with USB-C inline power meters capable of 1 ms resolution, logging the figures to a local server during scripted browsing sessions. For software, we used Chrome's navigator.getBattery() API, cross-validated against the power meters to quantify the API's ±2% granularity error on macOS.
We tested five categories of page: long-form editorial articles (like the one you're reading), photo galleries, video-heavy pages, news link aggregators, and purely blank calibration pages. Each was loaded in a stripped-down Chromium instance with no extensions, against a controlled Wi-Fi environment, on a 14-inch laptop at 50% screen brightness. Each test ran for thirty minutes, repeated five times, with results averaged across runs to reduce noise from OS background activity.
If there is one single variable that predicts a page's energy footprint better than any other, it is JavaScript bundle size. Our regression analysis across 240 pages found a Pearson correlation of r = 0.79 between total JS parse-and-execute time and power draw during the first thirty seconds of load. Script execution is CPU-intensive, and CPUs are, watt-for-watt, the greediest component in a laptop at moderate workloads.
The mechanism is straightforward. When a browser parses JavaScript, V8 (Chrome's engine) compiles it to bytecode, then hot-pathed functions get JIT-compiled to native machine code. This is compute-heavy work. A 500 KB compressed JS bundle — modest by today's standards — typically takes 800–1,400 ms to parse and execute on a mid-range laptop, pulling the CPU core into a sustained high-frequency state and spiking power draw from a resting ~2W to 8–14W for that window.
What's worse is the long tail. Many frameworks ship with "lazy-loaded" modules that fire after initial render, triggered by user interaction or visibility observers. In practice, scrolling through a news article can trigger four, six, even eight separate dynamic imports — each producing a fresh spike of parsing activity just as the user settles into reading. The power profile looks less like a smooth curve and more like a sawtooth.
First-party JavaScript is at least visible to developers. Third-party scripts — analytics, ad networks, live-chat widgets, social embeds — are a different matter. In our sample, the median page loaded 14 third-party scripts from 8 distinct domains. These scripts collectively executed for longer than the page's own code in 61% of cases. They also tend to use persistent setInterval loops, polling for ad viewability, consent-signal updates, and data-layer flushes at intervals of 250–2,000 ms.
Each of those timer callbacks wakes the main thread, preventing the browser process from entering a lower-power idle state. Chrome's energy metrics confirm this: pages with heavy third-party analytics show 30–45% higher CPU energy use during ostensibly "idle" reading time compared to pages with no third-party scripts. The user is doing nothing but reading; the browser is sprinting.
"The user is doing nothing but reading; the browser is sprinting."— Mara Lindqvist, The Synthetic Times
CPU activity is only part of the story. The rendering pipeline — layout, paint, composite, and GPU rasterisation — represents a second major energy sink, especially for visually rich pages. CSS animations and transitions trigger compositing passes. Sticky headers recompute layout on every scroll event if not properly promoted to their own layer. Oversized images, even when they've been lazily loaded off-screen, can force the GPU to decode and cache texture data speculatively.
We found that position: sticky elements alone added a consistent 25–40 mW to idle-scroll power draw. This seems small until you remember that a news page can have three sticky elements (header, side rail ad, cookie consent bar), and the user may spend forty-five minutes scrolling that page. At 35 mW overhead over 45 minutes, that is 1.575 Wh — or about 1.3% of a 120 Wh battery, for nothing more than a sticky header.
Most battery benchmarks focus on compute but neglect the network radio. Wi-Fi is not free. The 802.11ac radio in a typical laptop consumes 2–4W during active data transfer and drops to roughly 150–300 mW when associated but idle (in power-save mode, PSM). The key word is "idle": PSM only activates when the radio has no pending data. Web pages that make continuous background requests — polling for notifications, streaming analytics events, pre-fetching adjacent articles — keep the radio out of PSM continuously.
We measured this directly by comparing the battery drain of two nominally identical article pages: one with all network activity silenced after initial load, one with its normal background beacon traffic intact. The difference: 180–220 mW, sustained for the entire reading session. Over a typical 45-minute article dwell, that is an additional 0.14–0.17 Wh consumed purely by background network chatter the user never notices and never benefits from.
HTTP/2's multiplexing was supposed to reduce the number of open connections — and it does, in terms of TCP handshakes. But persistent connections carry a cost: each open HEADERS frame poll or server-push notification wakes the radio. A typical news page maintains 6–12 persistent HTTP/2 connections across its third-party origin set. Even if each connection carries very little data, the aggregate wakeup rate can prevent the radio from entering PSM for minutes at a time.
The introduction of HTTP/3 (QUIC over UDP) makes this slightly worse on some configurations, since QUIC's connection migration features require more frequent keepalive packets than TCP's established OS-level idle timer management. Browser vendors are aware of this tradeoff, and several have introduced heuristics to coalesce background requests, but these optimisations are unevenly applied and easily defeated by non-cooperative origins.
Screen power is both the most obvious and the most misunderstood component of browsing energy. OLED panels — now common in premium laptops — are nearly zero-power for black pixels and proportionately expensive for bright pixels. An OLED panel at full white brightness can draw 8–12W on a 14-inch laptop; at full black it draws under 0.5W. This means a white-background article page on an OLED laptop consumes significantly more energy than the same page with a dark background.
For IPS/LCD panels, the difference matters less because the backlight is always on. But many LCD panels implement local dimming — hardware-controlled zones of backlight brightness — and the zone-update algorithm can paradoxically increase power consumption on pages with rapidly changing content, as the dimming engine works to track high-frequency changes.
The practical implication: dark mode isn't a cosmetic preference on OLED hardware, it is a measurable energy optimisation. Our tests show 18–27% lower panel power draw for dark-themed pages on OLED laptops at identical perceived-brightness settings.
The most counterintuitive finding of this project was not any individual component but how the components compound. A page with heavy JS execution runs the CPU at high frequency; a CPU at high frequency generates heat; heat causes the fan to spin up; the fan motor draws another 300–800 mW. A page keeping the Wi-Fi radio awake also keeps a background CPU thread spinning in the kernel's network stack. GPU compositing keeps a slice of the memory bus active, preventing deeper DRAM power states.
In other words, each individual overhead is not merely additive — some combinations are multiplicative through shared physical dependencies. Our empirical data confirms this: the most power-hungry page in our set drew 2.4× the power of what a naive sum of its component overheads would predict. The components were feeding each other.
The uncomfortable truth is that most of the energy cost of a web page is outside the user's control. You can use a content blocker to eliminate third-party scripts — that alone can cut browsing power draw by 20–35%. You can enable dark mode on OLED hardware. You can close unused tabs; each background tab fires its own timers and performs its own garbage collection sweeps.
But you cannot, as a user, change the rendering architecture of the pages you visit. You cannot force a news site to use static HTML instead of a hydrated React application. You cannot stop an ad network from running a 400 KB auction script in a sandboxed iframe. The tools available to users are coarse filters; the underlying architecture remains what it is.
The more powerful levers are in the hands of developers and publishers. Shipping less JavaScript — not minifying it more, but shipping less of it — is the single most impactful change. Consolidating or eliminating third-party analytics. Avoiding setInterval-based polling in favour of event-driven updates. Ensuring sticky elements are GPU-promoted before scroll events fire. Testing pages with a power meter, not just a Lighthouse score.
We want to be transparent about the limitations of this study. Power draw varies enormously across hardware — a laptop with a large battery and efficient silicon will show different absolute numbers than a thin ultrabook under thermal throttling. Our Wi-Fi conditions were controlled; real-world network variability would add further noise. The Battery Status API itself has a reporting granularity of 1% on most platforms, meaning short-duration experiments carry high relative error.
What we are confident in are the relative differences — the patterns and proportions. A video page draws substantially more than an article; an article with heavy third-party analytics draws substantially more than a clean static page; these conclusions hold across our entire test matrix and are consistent with independently published findings from browser vendors and academic researchers.
The browser tab has become one of the most energy-dense user interfaces ever conceived. The cost has been hidden for so long precisely because it is distributed — across chips, radios, fans, and pixels — and because the people who pay it (laptop owners) are not the people who built it (framework authors and ad-tech networks). Measurement is the first step toward accountability.
Energy Performance Web Browsers
Continue reading: What Drains a Laptop Battery, Ranked • Latest in Energy & Computing