Warum Browser jedes Jahr wieder schwerer werden

Die Isolation hat alles multipliziert

Seit dem Spectre-Hardening betreibt Chromium jede Site im eigenen Prozess, und Firefox ist mit seinem eigenen Site-Split nachgezogen. Eine Sitzung mit fünfzehn Tabs und ein paar Erweiterungen ist mühelos ein Viertel­hundert Prozesse und mehr: der Browser selbst, der GPU-Prozess, der Netzwerkdienst und je ein Renderer pro Site. Site-Isolation ist wirklich gute Sicherheit: Ein kompromittierter Renderer kann die Daten anderer Sites nicht lesen. Aber jeder Prozess zahlt den vollen Preis für den Rendering-Stack, und dieselben fünfzehn Tabs, die 2014 in einem Prozess lebten, zahlen heute fünfzehn Mal Eintritt.

Erweiterungen sind ebenfalls Prozesse. Seit Manifest V3 laufen sie als ereignisgesteuerte Service Worker, wachen auf, wenn ihre Regeln sie brauchen, und halten Content-Scripts in jeder geöffneten Seite injiziert. Ein Dutzend „kleiner“ Erweiterungen wiegt so viel wie mehrere zusätzliche Tabs, und eine einzelne danebenlaunende kann alle zusammen überessen. Chromes eigener Task-Manager (Shift+Esc) zeigt die Kosten pro Tab und pro Erweiterung mit Namen — fünf Minuten dort schlagen jeden generischen Rat.

Die Plattform kann nur wachsen

Ein Browser liefert allen dieselbe Binärdatei aus, und in ihr steckt alles, was das moderne Web kann: WebGPU, WebAssembly, WebRTC, WebCodecs, Service Worker, installierbare Apps. Features zu entfernen ist nahezu unmöglich — irgendwo hängt noch eine Bank oder ein Intranet an der API von 2013 —, also kann die Engine nur akkumulieren. Jedes Release aktualisiert dazu seine Komponenten im Hintergrund: Codecs, den Netzwerk-Stack, Safe-Browsing-Listen; der Browser, den Sie gestern nicht neu gestartet haben, hat sich dreimal selbst gepatcht.

Die Webseiten selbst sind genauso schnell gewachsen. Eine durchschnittliche Seite liefert Megabytes an JavaScript aus, bevor Inhalt sichtbar wird, Werbung und Analytics reiten obendrauf, und eine „leichte“ Nachrichtenseite lädt mühelos hundert Skripte. Der Browser zeigt ehrlich, wessen Last er trägt — öffnen Sie den eingebauten Task-Manager und vergleichen Sie eine Dokumentationsseite mit einem Shop. Die Engine wurde schwerer, aber die Nutzlast wuchs schneller.

• Eine volle JavaScript-Engine mit JIT — jeder Prozess zahlt für den Compiler, nicht nur scriptlastige Sites
• GPU-Compositing und Codecs — jeder Renderer trägt seinen Anteil an der Grafik-Pipeline
• Service Worker — Sites halten Logik im Hintergrund laufen, ohne sichtbaren Tab
• Installierbare PWAs — eine Web-App bekommt eine eigene Runtime, nicht von einem kleinen Browser zu unterscheiden
• Erweiterungen — je ein Prozess, plus Content-Scripts, in jede geöffnete Seite injiziert

Was die Rechnung wirklich drückt

Der ehrliche erste Schritt ist das Ruhenlassen von Tabs, und das ist eingebaut: die „schlafenden Tabs“ von Edge frieren Hintergrund-Tabs nach einem selbst gewählten Timer ein, und Chromes Memory Saver lagert inaktive Tabs aus und stellt sie beim Klick wieder her. Beide holen echten Speicher zurück, und beide lassen Ausnahmen für Sites pinnen, die immer wach bleiben sollen. Der zweite Schritt ist der Erweiterungs-Audit: weg damit, was Sie nicht wiedererkennen, aus mit dem, was wöchentlich statt stündlich gebraucht wird — und die Zahlen im Task-Manager vorher und nachher vergleichen.

Was nicht funktioniert: die Jagd nach „leichten“ Browsern. Alles, was auf derselben Engine läuft, trägt dieselbe Pro-Prozess-Architektur und dasselbe Plattformgewicht — Sie tauschen Kompatibilität oder Sicherheitsupdates gegen einen Rundungsfehler. Alte Forks auf aufgegebenen Engines sind schlimmer als schwer: sie sind ungepatchte Angriffsfläche. Mehr RAM ist der unglamouröse Fix, der zur Trendlinie passt — der Browser ist ein Betriebssystem fürs Web, und niemand fährt ein Betriebssystem auf der Mindestausstattung.

Fragen und Antworten

Weiterlesen