Warum Chrome so viel RAM frisst: die echten Gründe hinter dem Hunger

Ein Prozess pro Site: die ganze Geschichte in einer Zeile

Chromium zerlegt den Browser in viele Betriebssystemprozesse: Renderer für Tabs — einer pro Site (Site-Isolation steckt verschiedene Sites sogar innerhalb eines Tabs in verschiedene Prozesse) —, einen GPU-Prozess, einen Netzwerkdienst, einen Speicherdienst und je Prozess pro geladener Erweiterung. Der Sinn ist Schadensbegrenzung: Ein abgestürzter Renderer reißt ein Tab mit, nicht den Browser, und ein kompromittierter Renderer hat keinen direkten Zugriff auf andere Sites. Der Preis sind die Overhead-Kosten jedes Prozesses — zwanzig offene Sites heißen also zwanzig kleine Chromium-Instanzen, jede mit ihrem Anteil an Bibliotheken, JIT-Heaps und Renderpuffern.

Es summiert sich schneller als erwartet, denn in der Zahl stecken längst nicht nur Tabs:

• Ein Renderer-Prozess pro Site — zehn Sites in zehn Tabs, plus die aus fremden Domains eingebetteten
• Jede aktivierte Erweiterung unterhält einen eigenen Hintergrundprozess, selbst im Leerlauf
• Der GPU-Prozess hält dekodierte Bilder, Kacheln und Videoframes — ein 4K-YouTube-Tab ist zum größten Teil genau das
• Service Worker überleben das Schließen ihres Tabs und halten Offline-Apps bereit
• Vorgeladene Seiten aus Omnibox-Vorschlägen und Prerendering belegen Speicher, bevor Sie sie überhaupt besuchen

Warum Chrome den Speicher nicht zurückgibt

Der zweite Grund ist Chromes Allokator PartitionAlloc: Er cacht freigegebene Seiten innerhalb jedes Prozesses für den sofortigen Weitergebrauch, statt sie an Windows zurückzugeben. Der Task-Manager zeigt diesen Pool als Teil von Chromes Fußabdruck, obwohl er technisch frei ist — die Zahl wirkt düsterer, als der Druck aufs System tatsächlich ist. Unter echter Knappheit gibt der Browser Speicher durchaus her — deshalb „erholt“ sich Chrome, nachdem Sie eine schwere App schließen —, im Leerlauf aber hält er bewusst zusammen, was er einmal bezahlt hat.

Ein Teil des gehaltenen Speichers ist Caching im ehrlichen Sinn: Der Back/Forward-Cache behält gerenderte Seiten, damit der Zurück-Knopf sofort reagiert, und Disk-Cache-Mappings ersparen das erneute Lesen der Dateien. Deshalb wirkt ein seit Tagen laufender Browser schwerer als ein frisch gestarteter: Er hat schlicht mehr zwischengespeichert, was sich zu behalten lohnt. Das ist das Argument „unbenutzter RAM ist verschwendeter RAM“, und ausnahmsweise stimmt es technisch — die Alternative wäre, jede erneut besuchte Seite neu zu rendern.

Was den Fußabdruck wirklich verkleinert

Aktivieren Sie den Speichersparmodus unter chrome://settings/performance: Er legt inaktive Tabs schlafen und gibt deren Renderer frei — der größte Hebel überhaupt bei einer vielen Tabs offenen Session. Dann gehen Sie den echten Übeltätern nach: Shift+Esc öffnet Chromes eigenen Task-Manager, sortieren Sie nach Speicher — meistens wiegt eine einzige schwere Seite (Web-IDE, Videokonferenz, aufgeblähtes Webmail) oder eine Erweiterung mehr als vierzig gewöhnliche Tabs. Erweiterungen sind besonderer Verdächtiger, denn jede fügt jedem Fenster einen Prozess hinzu, und viele laufen pausenlos.

Danach ist die ehrliche Antwort Arithmetik statt Magie: weniger schlafende Tabs, weniger Erweiterungen, kein dauerhaft angepinntes Dashboard, das niemand liest. Das Umschalten der Hardwarebeschleunigung tauscht GPU-Speicher gegen CPU-Last — bei schwacher integrierter Grafik manchmal ein Gewinn, manchmal das Gegenteil. Was nicht funktioniert: „RAM-Reiniger“, die Working Sets zwangsweise beschneiden — die Zahl sinkt, und der Browser ruckelt, während er das Beschnittene neu besorgt.

Fragen und Antworten

Weiterlesen