Perché Chrome consuma tutta questa RAM: le vere ragioni

Un processo per sito: tutta la storia in una riga

Chromium spezza il browser in molti processi del sistema operativo: renderer per le schede, uno per sito (l'isolamento dei siti mette siti diversi in processi diversi anche dentro una sola scheda), un processo GPU, un servizio di rete, un servizio di archiviazione e un processo per ogni estensione caricata. Il punto è il contenimento dei danni — un renderer che crasha si porta via una scheda, non il browser, e un renderer compromesso non ha accesso diretto agli altri siti. Il costo è che ogni processo si porta il suo overhead di runtime: venti siti aperti significano venti piccole istanze di Chromium, ciascuna con la sua parte di librerie, heap JIT e buffer di rendering.

La somma cresce più in fretta di quanto la gente si aspetti, perché quel numero non sono solo le schede:

• Un processo renderer per sito — dieci siti in dieci schede, più quelli in iframe da altri domini
• Ogni estensione attiva gira nel suo processo in background, perfino da ferma
• Il processo GPU tiene immagini decodificate, tile e frame video — una scheda YouTube in 4K è per lo più questo
• I service worker restano vivi dopo che chiudi la loro scheda, pronti per le app offline
• Le pagine precaricate dai suggerimenti dell'omnibox e dal prerendering occupano memoria prima ancora che le visiti

Perché Chrome non restituisce la memoria

Il secondo motivo è l'allocatore di Chromium, PartitionAlloc, che tiene in cache le pagine liberate dentro ogni processo per riutilizzarle subito invece di restituirle a Windows. Gestione attività mostra quella cache come parte dell'ingombro di Chrome anche se tecnicamente è libera, così il numero sembra più spaventoso della pressione reale sul sistema. Il browser la memoria la rilascia sotto pressione vera — ecco perché Chrome «si riprende» dopo che chiudi un'app pesante — ma su una macchina a riposo trattiene deliberatamente ciò che ha pagato.

Parte della memoria trattenuta è caching nel senso onesto: la back/forward cache conserva le pagine renderizzate così il pulsante Indietro è istantaneo, e le mappature della cache su disco evitano di rileggere i file. È anche per questo che un browser acceso da giorni sembra più pesante di uno appena avviato: ha semplicemente messo in cache più cose che valeva la pena tenere. È l'argomento della «RAM non usata è RAM sprecata», e per una volta è tecnicamente vero — l'alternativa è ri-renderizzare ogni pagina che rivisiti.

Cosa riduce davvero l'ingombro

Attiva Memory Saver su chrome://settings/performance: mette a dormire le schede inattive e libera i loro renderer — la leva più grande in assoluto su una sessione con molte schede. Poi passa in rassegna i veri colpevoli: premi Shift+Esc per aprire il gestore attività di Chrome e ordina per memoria — nella maggior parte dei casi un sito pesante (una IDE web, una videochiamata, una webmail gonfia) o un'estensione pesano più di quaranta schede normali. Le estensioni meritano un sospetto speciale: ognuna aggiunge un processo a ogni finestra e molte girano di continuo.

Dopo di che, la risposta onesta è aritmetica, non magica: meno schede addormentate, meno estensioni, niente dashboard appuntate per sempre che nessuno legge. Attivare o disattivare l'accelerazione hardware scambia memoria GPU contro carico CPU — a volte conviene su una GPU integrata debole, a volte il contrario. Ciò che non funziona: i «pulitori di RAM» che potano a forza i working set — il numero scende e il browser balbetta mentre recupera ciò che era stato potato.

Domande e risposte

Da leggere dopo