How Chromium's Memory Saver Mode Frees Up System RAM

This article explains the technical mechanics behind the Memory Saver mode in Chromium-based web browsers. It covers why Chromium consumes significant memory, how the browser identifies inactive background tabs, the exact process of discarding those tabs to free up system RAM for active applications, the exceptions that prevent data loss, and how tabs are restored upon user return.

Why Chromium Needs a Memory Saver

Chromium uses a multi-process architecture. To ensure security and stability, the browser isolates different websites and tabs into their own dedicated "renderer processes." If one tab crashes, it does not crash the entire browser. However, this isolation means every open tab duplicates certain baseline memory overheads. When dozens of tabs are open, these renderer processes quickly consume gigabytes of system RAM, starving active applications of resources. Memory Saver directly addresses this by managing the lifecycle of these processes.

Identifying Inactive Tabs

Chromium relies on an internal component called the Performance Manager to monitor the state of all open tabs. When Memory Saver is enabled, the browser tracks a tab's visibility and user interaction.

Once a tab is moved to the background (meaning it is no longer the active tab in the window), an internal timer starts. If the user does not interact with the tab for a predetermined period, the Performance Manager flags the tab as "inactive" and makes it a candidate for discarding.

The Tab Discarding Process

When an inactive tab is selected for memory reclamation, Chromium executes a process called "tab discarding." It does not close the tab; instead, it strips the tab of its heavy system resource allocations through the following steps:

  1. State Preservation: Before shutting the tab down, Chromium records the tab's basic session state, including the current URL, navigation history (for the back and forward buttons), and sometimes the scroll position.
  2. Process Termination: Chromium completely terminates the underlying renderer process associated with that background tab (or detaches the tab from a shared process).
  3. Memory Reclamation: By killing the renderer process, all the RAM allocated to rendering the webpage's HTML, CSS, DOM trees, images, and executing JavaScript is immediately released back to the operating system. This freed RAM becomes instantly available for the currently active browser tab or other heavy software running on the computer.
  4. UI Retention: The tab remains visible in the browser's tab strip, retaining its title and favicon so the user knows it is still there.

Exceptions: When Tabs Are Not Discarded

To prevent frustrating the user or causing data loss, Chromium's Performance Manager actively checks for specific conditions before discarding a tab. A background tab will be bypassed by Memory Saver if it is doing any of the following:

  • Playing audio or video.
  • Participating in an active WebRTC session (such as a video call or screen sharing).
  • Holding partially filled-out user forms or unsaved text inputs.
  • Actively downloading a file.
  • Interacting with connected hardware devices via WebUSB, WebBluetooth, or WebHID.
  • Displaying notifications or utilizing specific background service workers.
  • Listed on the user's manual "Always keep these sites active" exception list.

Restoring a Discarded Tab

Because the tab's renderer process was terminated to save RAM, the webpage no longer exists in the system's active memory. When the user clicks on a discarded tab to bring it back to the foreground, Chromium creates a brand-new renderer process. It then uses the saved session state to automatically reload the webpage from the internet or the local disk cache, placing the user back where they left off.