Understanding Chrome Site Isolation: Why Your Browser Uses So Much RAM

The Problem: The Memory-Security Trade-off

If you have ever opened the Chrome Task Manager and wondered why a single tab has spawned five different processes, you are seeing Site Isolation in action. For years, browsers isolated content by the tab. If you had three tabs open, you had three renderer processes. However, if one tab contained an iframe (an embedded window) from a different website, both the main page and the iframe shared the same process memory.

This shared memory created a critical vulnerability. Speculative execution attacks, such as Spectre, allow a malicious script to read memory it shouldn't have access to. In a non-isolated environment, a malicious ad in an iframe could potentially read sensitive cookies or passwords from the main page because they lived in the same process. The takeaway: Chrome now prioritizes security over memory efficiency by ensuring that different sites never share a process.

The Shift from Tab-Isolation to Site-Isolation

Site Isolation moves the security boundary from the browser tab to the site (defined as the effective Top-Level Domain plus one, or eTLD+1). This means that blog.example.com and shop.example.com might share a process, but example.com and malicious-site.net never will.

To achieve this, Chrome implements Out-of-Process iframes (OOPIFs). When a page embeds content from another origin, Chrome spawns a dedicated renderer process for that iframe. The main page no longer has direct memory access to the iframe; instead, they communicate via a secure Inter-Process Communication (IPC) channel managed by the browser's main process.

Practical Verification: Inspecting Your Processes

You can verify this behavior in real-time without any external tools. Follow these steps to see how Chrome maps sites to processes:

1. Open a new Chrome window.
2. Navigate to a site that embeds third-party content (for example, a news site with embedded social media posts or a page with a YouTube embed).
3. Press Shift + Esc to open the Chrome Task Manager.
4. Look for the "Tab" entry and the accompanying "Subframe" entries.

You will notice that the main URL is listed as one process, while the embedded third-party domains are listed as separate "Subframe: [domain]" processes. Each of these is a distinct OS-level process with its own memory space.

Comparing Isolation Models

The Engineering Cost: Memory and Latency

This architecture is not free. Because each process requires its own instance of the renderer engine and basic overhead, total RAM consumption increases significantly. If a page has ten iframes from ten different domains, Chrome may spin up eleven processes for a single tab.

Additionally, there is a performance hit known as IPC overhead. When the main page needs to tell an OOPIF to resize or when the iframe needs to send a message to the parent, the data must be serialized and sent through the browser process. This introduces more latency than a simple function call within a single process.

Limitations and Resource Management

Site Isolation is not absolute. Chrome employs a dynamic resource manager; if your system is critically low on memory, the browser may group some sites together to prevent the OS from crashing or swapping to disk excessively. This means that under extreme memory pressure, the security guarantees of strict isolation may be relaxed to maintain stability.

Actionable Summary

To audit how your own web applications are being isolated, navigate to chrome://process-internals. This page provides a detailed mapping of every active process and the specific sites they host. If you are a developer noticing unexpected latency in cross-origin iframes, consider if you can consolidate domains or use postMessage more efficiently to reduce the frequency of IPC calls.