A weather app shouldn't need 1 GB of RAM. WebView2 explains why it does.

What happened

Notebookcheck published memory measurements of the built-in Windows 11 Weather app showing the process tree consuming north of 1 GB of resident RAM on a fresh launch, with no interaction beyond opening the window. The number is not a leak, not a background sync gone wrong, and not a one-off on some exotic hardware — it's the steady-state cost of showing a 7-day forecast.

For context: 1 GB is roughly what a running instance of VS Code with a mid-sized project loaded uses. It is more than a stock Slack client. It is orders of magnitude more than the Windows Vista/7-era Weather gadget (measured in single-digit MB) or the Windows 8 Metro Weather app (typically 30–80 MB). The app itself has not gotten dramatically more feature-rich in the intervening decade. The runtime under it has.

The Weather app is, architecturally, a web page hosted inside a Chromium engine that Microsoft ships and updates independently of Windows — a component called WebView2. Once you know that, the memory number stops being surprising and starts being predictable.

Why it matters

WebView2 is Microsoft's official, blessed way to build "modern" desktop apps on Windows. The pitch, roughly: reuse your web skills, get automatic updates, ship one binary. What the pitch elides is the process model you're inheriting.

A WebView2 host doesn't spawn one process. It spawns the Chromium multi-process tree: a browser process, one or more renderer processes (one per site-isolated origin), a GPU process, a network service, a storage service, and various utility processes for audio, video decode, and crash handling. Each of those has its own heap, its own V8 isolate where applicable, its own graphics context. Task Manager's summary line hides this by aggregating them under a single friendly name.

On top of that runtime, the Weather app loads what is effectively an MSN.com page — complete with the ad tech, telemetry SDKs, and layout frameworks that MSN carries for the browser version. You are running the same JavaScript payload a browser tab would run, except you don't get to close the tab and you didn't ask for the ads. A community thread on the Notebookcheck story pointed out that blocking `assets.msn.com` at the hosts-file level cuts memory usage roughly in half, which is the tell: a meaningful fraction of the footprint is third-party web infrastructure, not the forecast.

Compare the trade-offs of adjacent stacks:

- Electron ships its own Chromium *and* its own Node.js runtime per app. Two Electron apps run two full copies. Discord, Slack, and VS Code each pay this cost independently — which is why a machine running all three easily crosses 2 GB just at idle. - WebView2 is better than Electron in one specific way: the runtime is shared across apps on the same machine, so the second WebView2 app you install doesn't pay the disk cost twice. But the *process* cost — the running browser tree per app — is not shared. Every WebView2 app pays it in full. - Tauri and similar frameworks (Wails, Neutralino) delegate to the OS's system webview (WebView2 on Windows, WebKit on macOS, WebKitGTK on Linux) and keep the app-side runtime in a smaller compiled language like Rust or Go. Idle memory typically lands in the 50–150 MB range for equivalent apps. - Native (Win32/WinUI/native macOS/Qt) still wins on baseline memory by an order of magnitude and always will, because it isn't dragging a browser engine to render a menu.

The interesting story isn't that a Microsoft app is bloated — it's that Microsoft's own recommended path for building modern Windows apps has this floor, and Microsoft themselves hit it. If the vendor that ships the runtime, controls the OS, and writes the sample code can't get a weather forecast under 1 GB, that's not a discipline problem. That's the architecture's resting heart rate.

There's a secondary story about incentives. The Weather app monetizes through MSN ad inventory. Rewriting it as a lean native app would mean rebuilding the ad stack, breaking the shared content pipeline with MSN.com, and losing the ability to A/B test forecast layouts without shipping a Windows update. From a business standpoint, the 1 GB is a feature — it's what buys the shared codebase. From a user standpoint on an 8 GB laptop, it's the reason you close Weather before opening Photoshop.

What this means for your stack

If you ship a desktop app to end users, the Weather app is a preview of what your users will hold you to when they open Task Manager. A few concrete implications:

Pick your webview budget deliberately. If you're greenfield and the app is genuinely a rich UI (dashboards, editors, communication tools), Electron or WebView2 remains defensible — but budget 200–400 MB minimum at idle and design your feature set around that reality. Don't build a menu-bar utility on Electron. The rule of thumb: if your app is smaller in scope than VS Code, it probably shouldn't ship with more runtime than VS Code.

Look hard at Tauri if you're greenfield. The ecosystem is now mature enough for production apps (1Password, Cloudflare's tunnel client, several YC-backed dev tools). Using the OS webview means your app's memory profile scales with what the user's OS is already paying for the system browser, rather than adding a fresh copy. The trade-off is real: cross-platform CSS quirks return, because Safari's WebKit is not Chromium.

Audit your third-party payload. The Weather app's memory footprint is dominated by MSN's ad and telemetry stack, not by the forecast rendering itself. If you're loading Segment, Amplitude, Sentry, Intercom, and three A/B testing SDKs into your Electron shell, you are shipping a browser's worth of JavaScript on top of a browser. That compounds.

Measure resident memory, not just working set. Windows Task Manager's default column understates multi-process apps. Use `Get-Process | Where-Object { $_.ProcessName -like 'msedgewebview2*' } | Measure-Object WorkingSet64 -Sum` or the equivalent on macOS/Linux to see what your app actually costs when you sum every helper process it spawned. The number is often 2–3× what a naive glance suggests.

Looking ahead

The web-view-everywhere pattern is now the default assumption for consumer desktop software, and the industry-wide memory bill is showing up in three places: entry-level laptops that ship with 8 GB and feel slow within a year, Windows-on-ARM devices where every extra Chromium instance eats battery, and the growing category of AI coding assistants and agent tools that all want to run their own Electron shell alongside your editor. Weather at 1 GB is a rounding error on a 32 GB workstation and a genuine problem on the Copilot+ PCs Microsoft is telling everyone to buy. The architectural choice — ship a browser, render a page, call it an app — has run out of headroom on the devices where most people actually live.