Chrome Site Isolation: Verify Cross-Site Process Boundaries and Measure Memory Cost

The problem: speculative execution made the renderer process a security boundary

When researchers demonstrated Spectre-style side-channel attacks, it became clear that enforcing the same-origin policy inside a single process was not enough. Code running in one renderer could, in principle, infer data from another origin sharing that process through memory timing. Chrome's Site Isolation answers this by giving each cross-site iframe its own operating-system renderer process, so the kernel's memory protection enforces the boundary.

Site Isolation is enabled by default for most browsing contexts in current stable Chrome. The engineering trade-off is real: Chrome telemetry reports roughly 10–13 percent higher resident set size (RSS) on typical desktop workloads. On memory-constrained devices, or pages that embed many third-party iframes, that overhead can matter.

How Chrome decides which iframes get their own process

Chrome defines a site as the scheme plus registered domain, for example https://example.com. When a top-level page embeds an iframe whose site differs from its own, Chrome starts a dedicated renderer process for that subframe. Same-site iframes, such as https://app.example.com inside https://example.com, may still share a renderer because they already operate under the same site principal.

The renderer process holds the DOM, JavaScript heap, and GPU resources for exactly one site instance. If speculative code inside that process reads memory it should not, the exposed data belongs to that same site rather than to the top-level page or other embedded origins.

Worked example: confirm isolation with Chrome Task Manager

Open a page that embeds a cross-site iframe. A simple test is https://example.com with an embedded https://www.youtube.com player. No special flags or internal builds are needed.

1. Press Shift+Esc to open Chrome Task Manager.
2. Right-click the column headers and make sure Site and Process ID are visible.
3. Find the top-level page entry, listed as Tab, and the iframe entry, listed as Subframe.
4. Compare the Site and Process ID columns. The subframe should show the iframe's origin and a different process ID from the top-level tab.

Expected check: the subframe row reads something like https://www.youtube.com in the Site column and its PID differs from the top-level page's PID. If both rows show the same PID, the iframe is either same-site or Site Isolation has been disabled by enterprise policy.

You can cross-check this in DevTools by opening the process selector in the toolbar; each renderer appears as a separate entry labeled with its site.

Measure the memory cost on your own workload

The 10–13 percent figure comes from Chrome telemetry. Your actual cost depends on how many distinct sites a page embeds and how long their renderers stay alive. To measure your page:

1. Close all Chrome windows.
2. Launch Chrome with a fresh user data directory to avoid profile noise. On Linux or macOS:

chrome --user-data-dir=/tmp/chrome-test-profile

On Windows, use a path such as %TEMP%\chrome-test-profile.

1. Open the target page, for example a dashboard that embeds several third-party widgets.
2. Wait for network idle, then record RSS. In Chrome Task Manager, sum the RSS values for all renderer rows. On Linux or macOS you can also use ps -o rss= -p <pid1>,<pid2> for the renderer process IDs.
3. Calculate the overhead relative to a baseline. Chrome does not provide a per-tab switch to turn isolation off, and disabling it with command-line flags is not recommended outside controlled enterprise testing. If you need a controlled comparison, use a separate device or profile where isolation is managed by enterprise policy, then apply:

(RSS_with_isolation - RSS_baseline) / RSS_baseline * 100

Pages with many same-site iframes show little delta because they share renderers. Pages with many distinct cross-site domains can spawn one renderer per site, so RSS scales roughly with active site count.

Limitations you cannot tune away

• Same-site iframes share a process. Untrusted content on a subdomain of your main site is not isolated from the main page by this feature. Move untrusted content to a fully distinct registered domain if you need a process boundary.
• Memory grows with site count. A page embedding twenty different ad-tech domains can spawn twenty or more renderers. Chrome reuses processes where possible, but RSS still rises with active site instances.
• No user-facing knob. Enterprise policies such as SitePerProcess can force isolation for specific origins or change default behavior, but developers cannot toggle it per tab.

Actionable closing: verify, measure, then decide

Open Chrome Task Manager with Shift+Esc on a page you ship. Confirm that every cross-site iframe appears as a Subframe with a distinct site and a distinct PID. If you are deploying to a memory-constrained kiosk or embedded device, run the RSS measurement above and budget for the typical 10–13 percent increase. Site Isolation is a default you generally should not disable, but knowing its exact cost on your pages lets you make an informed architectural call, such as reducing the number of distinct embedded origins.