Understanding Chrome Site Isolation: What It Means for Memory and Security

Why Site Isolation exists

Site Isolation is Chrome’s architectural decision to render each distinct origin in its own renderer process. By separating origins, the browser reduces the risk that a malicious site can read data from another site through side‑channel attacks such as Spectre. The trade‑off is higher baseline memory use because each renderer process carries its own overhead.

How Chrome groups origins into processes

Chrome does not use a strict “one tab, one process” rule. Instead it applies a process‑per‑site‑instance heuristic: frames that belong to the same site (scheme + registrable domain + optional port) and are loaded from the same top‑level navigation share a renderer process, while cross‑site frames are placed in separate processes. This heuristic keeps the isolation benefit while limiting the number of processes created for typical pages that embed many same‑site resources.

Observing isolation with a test page

1. Create a file named test.html with the following content:

<!DOCTYPE html>
<html>
<head><title>Site Isolation test</title></head>
<body>
<h1>Top‑level page (example.com)</h1>
<iframe src=\"https://example.com/same.html\"></iframe>
<iframe src=\"https://example.org/cross.html\"></iframe>
</body>
</html>

1. Open test.html in Chrome.
2. Open Chrome’s Task Manager (Shift + Esc) or navigate to chrome://processes.
3. Look for entries labeled “Renderer”.

When Site Isolation is enabled, you will typically see three renderer processes: one for the top‑level frame (example.com), one for the same‑site iframe (also example.com) and one for the cross‑site iframe (example.org). If the feature is disabled, the same‑site iframe may share the top‑level renderer, leaving only two renderer processes visible.

Trade‑offs and limits

• Each additional renderer process adds a fixed memory overhead (typically tens of megabytes), so pages with many isolated origins consume more RAM.
• On memory‑constrained devices or when many tabs are open, the increase can affect responsiveness.
• Enterprise administrators can adjust the behavior with policies such as SiteIsolationEnabled or via the flag --disable-site-isolation-per-origin.

What you can do

Verify the current state on your build:

1. Visit chrome://site-isolation to read whether isolation is active for the site you are inspecting.
2. Use chrome://processes to count renderer processes while you navigate between pages that embed same‑site and cross‑site iframes.
3. On Android, open chrome://flags#site-isolation-overrides to see the default setting for your device.

Because defaults differ between desktop and Android builds and can change across Chrome channels (Stable, Beta, Dev, Canary), test on the specific channel you intend to support if you need to confirm behavior.