Inattività silenziosa: Windows in background prima e dopo l’ottimizzazione
In questa pagina
Risposta breve
Sezione intitolata “Risposta breve”La disattivazione dei componenti in background di Windows rende effettivamente più silenzioso il sistema in idle: in due serie di misurazioni indipendenti il numero di processi è diminuito di 49–56 %, l’utilizzo della CPU in idle di 17–67 % e il commit della memoria di 52 % nella seconda serie. Con la CPU a pieno carico, però, il throughput è aumentato solo di 0,2–0,5 %. Un «idle silenzioso» significa una riduzione confermata dell’attività in background e della contesa per le risorse, non un aumento degli FPS: in questo studio non è stato misurato l’effetto finale sui giochi.
Stato: la direzione dell’effetto è stata riprodotta in due serie indipendenti sulla stessa build di Windows 11 in una macchina virtuale. I valori differiscono tra le serie perché l’attività in background di Windows si presenta a raffiche: nella finestra con la scansione di Microsoft Defender, la differenza nell’utilizzo della CPU raggiunge −67 %, mentre in una finestra già silenziosa è di −17 %.
Affermazioni verificabili
Sezione intitolata “Affermazioni verificabili”Abbiamo verificato quattro affermazioni:
- La disattivazione dei componenti in background riduce sensibilmente l’attività del sistema in idle.
- Riduce sensibilmente l’attività nei primi minuti dopo l’avvio.
- Riduce sensibilmente il consumo di memoria.
- Offre un aumento misurabile delle prestazioni con la CPU a pieno carico.
Ambito dello studio
Sezione intitolata “Ambito dello studio”- Windows 11 Pro, build 26300.9457 (26H2);
- macchina virtuale: 4 vCPU, 8 GB di RAM, virtualizzazione VMware;
- due stati della stessa installazione: originale («prima») e dopo l’applicazione del profilo di ottimizzazione BoosterX (build corrente alle date delle misurazioni);
- due serie di misurazioni indipendenti: 2026-09-18 e 2026-09-19; gli stati sono stati confrontati su copie indipendenti del disco, per evitare che le misurazioni si influenzassero a vicenda;
- fasi: 5 minuti dopo l’avvio, 5 minuti di stabilizzazione, 5 minuti di idle;
- brevi carichi sintetici: 1, 4 e 8 thread, carico sulla memoria, carico a impulsi e combinazioni di priorità.
Le misurazioni non includevano giochi reali, carichi sulla GPU, hardware fisico né finestre di lunga durata (ore e giorni).
Una serie separata su un PC fisico Ryzen 7 7800X3D, con quattro fasi e misurazioni di gioco, è pubblicata nell’articolo «BoosterX: attività in background di Windows e FPS in CS2». I suoi risultati non vengono combinati con quelli di questa serie su macchine virtuali.
Metodologia
Sezione intitolata “Metodologia”Il protocollo è conforme a «Come analizziamo Windows»:
- ogni fase è stata registrata con una traccia ETW (Windows Performance Recorder, profili leggeri per CPU, disco, file e rete) e con contatori delle prestazioni a intervalli di 5 secondi (sistema) e 15 secondi (per processo);
- la fase «dopo l’avvio» è stata avviata con un riavvio controllato ed è iniziata con un uptime di circa un minuto;
- per ogni traccia è stato verificato il numero di eventi persi: in tutte le finestre riportate è pari a zero;
- la media è stata calcolata solo sugli intervalli completi di cinque secondi compresi nei limiti della fase (59 intervalli per fase);
- nella serie 2, la prima esecuzione «prima» è stata esclusa perché la macchina virtuale è entrata in sospensione; è stata usata la ripetizione;
- i test di carico sono stati eseguiti due volte; sono riportate le mediane. L’utilizzo della CPU è normalizzato su quattro vCPU.
«Prima» e «dopo» sono due stati della stessa installazione di Windows: lo stato «dopo» è stato ottenuto applicando il profilo di ottimizzazione, mentre «prima» corrisponde allo stato originale. È stato modificato l’intero insieme di impostazioni, quindi non è stato valutato il contributo isolato di una singola disattivazione.
Risultati
Sezione intitolata “Risultati”Serie 1 (2026-09-18): idle stabile senza manutenzione attiva:
| Metrica | Prima | Dopo | Variazione |
|---|---|---|---|
| Utilizzo CPU, % | 2,48 | 2,06 | −17 % |
| DPC + ISR, % CPU | 1,73 | 1,59 | −8 % |
| Cambi di contesto, /s | 469 | 381 | −19 % |
| Processi (media) | 134,9 | 69,3 | −49 % |
| Thread (media) | 1 444,6 | 738,7 | −49 % |
| CPU totale di tutti i processi, % | 1,22 | 1,06 | −13 % |
| Memoria disponibile, MB | 5 490 | 6 518 | +1 028 |
| Lettura dal disco, KB/s | 22,6 | 24,4 | +8 % |
| Scrittura sul disco, KB/s | 311,3 | 262,1 | −16 % |
| Rete (ricezione), KB/s | 132,6 | 2,2 | −98 % |
| Rete (invio), KB/s | 43,2 | 4,7 | −89 % |
Serie 2 (2026-09-19): stessa finestra di idle, ma nello stato «prima» era in corso una scansione in background di Microsoft Defender:
| Metrica | Prima | Dopo | Variazione |
|---|---|---|---|
| Utilizzo CPU, % | 33,37 | 11,03 | −67 % |
| Cambi di contesto, /s | 3 737 | 291 | −92 % |
| Processi (media) | 142,3 | 61,9 | −56 % |
| Thread (media) | 1 494,7 | 637,1 | −57 % |
| Memoria disponibile, MB | 5 174 | 6 653 | +1 479 |
| Memoria fisica utilizzata, MB | 3 017 | 1 538 | −49 % |
| Commit della memoria, MB | 2 617 | 1 249 | −52 % |
| Pool non paginato, MB | 298,2 | 212,9 | −29 % |
| Pool paginato, MB | 258,5 | 86,0 | −67 % |
| DPC, % CPU | 0,89 | 0,19 | −78 % |
| Lettura dal disco, MB/s | 7,42 | 0,01 | −99,9 % |
| Scrittura sul disco, MB/s | 4,57 | 0,23 | −95,0 % |
Nella serie 2, in entrambi gli stati il traffico di rete in idle era quasi nullo (decine di byte al secondo), quindi le relative righe non sono riportate. La differenza tra le serie non è una contraddizione, ma una caratteristica dell’attività in background: quando Windows esegue operazioni di manutenzione, la disattivazione dei componenti in background consente un risparmio maggiore; quando la finestra è già silenziosa, il risparmio è minore.
Primi minuti dopo l’avvio
Sezione intitolata “Primi minuti dopo l’avvio”| Metrica | Serie 1 (prima → dopo) | Serie 2 (prima → dopo) |
|---|---|---|
| Utilizzo CPU, % | 3,42 → 2,59 | 14,62 → 11,88 |
| Cambi di contesto, /s | 1 114 → 600 | 1 257 → 393 |
| Processi | 132 → 74 | 139 → 64 |
| Thread | — | 1 719 → 746 |
| Memoria fisica utilizzata, MB | — | 2 821 → 1 581 |
| Memoria disponibile, MB | — | 5 370 → 6 610 |
| Lettura dal disco, KB/s | — | 826 → 433 |
| Scrittura sul disco, KB/s | 634 → 418 | 709 → 298 |
| Rete (ricezione), KB/s | — | 1,15 → ~0 |
Il trattino indica che in questa serie la metrica non è stata registrata per la fase.
Composizione e memoria
Sezione intitolata “Composizione e memoria”Inventario rilevato in idle (serie 1):
| Prima | Dopo | |
|---|---|---|
| Processi | 136 | 70 |
| Thread | 1 679 | 842 |
| Working set totale, MB | 3 841 | 1 868 |
| Private bytes totali, MB | 1 524 | 660 |
I principali consumatori di memoria prima dell’ottimizzazione erano: il processo antivirus MsMpEng.exe (257 MB), explorer.exe (213 MB), StartMenuExperienceHost (144 MB), msedge.exe (133 MB), SearchHost.exe (122 MB). Dopo l’ottimizzazione, in cima all’elenco figuravano explorer.exe (170 MB), msedgewebview2 (119 MB), SearchHost.exe (115 MB) e StartMenuExperienceHost (106 MB).
La memoria disponibile è aumentata di 1,0–1,5 GB, mentre il commit si è ridotto di 52 %. L’articolo «Quanta memoria si può liberare davvero in Windows» spiega che cosa si può effettivamente «liberare» e perché la somma dei working set dei processi non equivale alla memoria libera.
A pieno carico
Sezione intitolata “A pieno carico”Brevi test sintetici (serie 2, mediane di due ripetizioni):
| Scenario | Variazione del throughput | Utilizzo CPU: prima / dopo |
|---|---|---|
| Un thread | +5,4 % | 21,9 / 22,6 % |
| Quattro thread (pieno carico) | +0,19 % | 88,9 / 89,4 % |
| Otto thread (pieno carico) | +0,50 % | 88,9 / 88,8 % |
| Carico sulla memoria | +11,2 % | 84,8 / 87,5 % |
| A impulsi (pause di 1 ms) | +5,4 % | 64,3 / 67,7 % |
| Priorità miste | +8,5 % | 21,2 / 22,5 % |
| Priorità in background | +77,1 % | 38,8 / 65,2 % |
Con un carico completo su quattro thread, il processo di lavoro ha utilizzato circa 89 % della capacità di quattro vCPU sia prima sia dopo l’ottimizzazione. Il restante ~11 % nella macchina virtuale non può essere definito «rumore di Windows» eliminabile: la pianificazione dell’hypervisor non è visibile nella traccia del sistema guest. I thread di lavoro erano distribuiti uniformemente (scarto del volume di lavoro tra i thread: 0,994–0,997); non si è osservata alcuna starvation e, dopo l’ottimizzazione, la coda della CPU in idle era praticamente vuota.
Origine dell’attività in background
Sezione intitolata “Origine dell’attività in background”Fonti di attività in background misurate nello stato «prima»:
- scansione antivirus: la fonte principale nella finestra della serie 2; il processo
MsMpEng.exeha consumato 212 secondi CPU durante una finestra di idle di cinque minuti; - nello stato originale erano attivi il servizio di ricerca, il servizio SysMain, la telemetria, lo spooler di stampa e altri componenti; il profilo di ottimizzazione porta allo stato disabilitato circa 50 servizi in background e 58 attività pianificate;
- dopo l’avvio, l’attività è accompagnata dall’orchestratore degli aggiornamenti di Windows.
La disattivazione dei componenti in background non elimina del tutto l’attività in background: nello stato ottimizzato continuava a essere eseguita la valutazione della compatibilità delle applicazioni (circa 3,7 ms CPU al secondo nella finestra di manutenzione), mentre l’attività residua complessiva in idle stabile era pari a 4,8 ms CPU al secondo, circa 0,12 % della capacità di quattro vCPU (misurata tramite traccia).
Cosa è stato confermato
Sezione intitolata “Cosa è stato confermato”- Riprodotto (due serie indipendenti): numero di processi −49…−56 %, thread −49…−57 %, memoria disponibile +1,0–1,5 GB.
- Misurato (serie 2): commit −52 % in idle; memoria fisica utilizzata −49 % in idle e −44 % nella fase successiva all’avvio.
- Misurato: utilizzo della CPU in idle −17 % nella finestra silenziosa e −67 % nella finestra con la scansione; cambi di contesto −19 % e −92 %; DPC −78 % (finestra della serie 2); attività dopo l’avvio inferiore in entrambe le serie.
- Misurato: con la CPU a pieno carico, aumento del throughput di +0,19 % (4 thread) e +0,50 % (8 thread); con carichi parziali e misti, da +5,4 a +11,2 %.
- Misurato: il carico con priorità in background è stato più veloce del 77,1 %: nello stato «prima» competeva con l’attività in background di Windows, inclusa la scansione antivirus.
- Osservato: le principali fonti di attività in background sono la scansione antivirus, la manutenzione e le attività di compatibilità; dopo l’ottimizzazione, l’attività residua è prossima allo zero, ma non è nulla.
Cosa non è stato confermato
Sezione intitolata “Cosa non è stato confermato”- Aumento degli FPS, riduzione dell’input lag o del frametime nei giochi reali: non misurati. I test sintetici della CPU non simulano un gioco con GPU e non dimostrano un effetto sui giochi.
- Contributo isolato di ogni singola disattivazione: è stato applicato un insieme di modifiche.
- Trasferibilità dei valori assoluti all’hardware fisico, ad altre build e ad altri profili di ottimizzazione.
- Stabilità su finestre lunghe: ogni fase è durata 5 minuti; l’attività in background di Windows si presenta a raffiche, quindi non è stata misurata una «giornata media».
- Le misurazioni sono state eseguite in una macchina virtuale. La virtualizzazione contribuisce ai valori DPC/ISR e nasconde la pianificazione dell’host; su hardware fisico i valori assoluti saranno diversi. Le proporzioni e la direzione del confronto «prima/dopo» restano valide a parità di condizioni.
- La metrica ISR è stata esclusa dalle tabelle: nella macchina virtuale, il contatore ISR di PDH differisce di circa 10 % dai gestori degli interrupt rilevati tramite ETW e non corrisponde alla somma esatta.
- La finestra «prima» della serie 2 includeva una scansione attiva di Defender e il carico dell’host differiva tra le finestre (in media 44 % contro 24 %). I valori si riferiscono quindi a finestre specifiche; la direzione è stata confermata da due serie.
- Nella serie 1, una parte della fase di idle è stata interrotta da una pausa esterna della macchina virtuale di circa 26 secondi; la registrazione è terminata dopo la ripresa e non sono stati persi eventi.
- I test di carico sono stati ripetuti due volte: si tratta di statistiche descrittive, senza valutazione della significatività statistica.
- Parte del vantaggio in idle è legata alla disattivazione dei componenti di protezione di Microsoft Defender. Un sistema senza protezione antivirus è un compromesso consapevole, non un’ottimizzazione priva di costi; la protezione va disattivata solo comprendendone le conseguenze.
- Il livello di misurazione (traccia e contatori) genera a sua volta un piccolo carico in background, presente in entrambi gli stati.
Lo studio e gli strumenti utilizzati appartengono allo sviluppatore di BoosterX, che ha quindi un interesse diretto nei risultati. La metodologia e i limiti di applicabilità sono descritti sopra; le conclusioni possono essere verificate consultando i dati aperti e le fonti pubbliche elencate.
Conclusione pratica
Sezione intitolata “Conclusione pratica”La riduzione del rumore in background è un effetto reale, riprodotto due volte: la metà dei processi e dei thread, la metà del commit della memoria e un’attività su disco e rete in idle ridotta di un ordine di grandezza. È utile di per sé — per la reattività del sistema, le attività in background, la temperatura, il rumore delle ventole e l’autonomia della batteria — e non richiede promesse sugli FPS.
Non bisogna aspettarsi un aumento delle prestazioni a pieno carico. Se la CPU è già impegnata in attività utili per ~89 % della sua capacità, la disattivazione dell’attività in background non aggiungerà il restante 11 %: nella macchina virtuale non è attribuibile a Windows. L’effetto visibile dipende da ciò che il sistema sta facendo al momento del confronto: nella finestra di manutenzione la differenza è multipla, in quella silenziosa è moderata.
Raccomandazione: valutate l’attività in background prima e dopo qualsiasi modifica sul vostro computer (Gestione attività → «Prestazioni» e «Processi», Monitoraggio risorse), invece di basarvi sulle percentuali ottenute da altri. Se l’obiettivo sono gli FPS in un gioco specifico, misurateli prima e dopo la modifica.
Ripristino dello stato
Sezione intitolata “Ripristino dello stato”Entrambe le serie sono state eseguite in macchine virtuali isolate su copie indipendenti del disco; al termine delle misurazioni, le macchine sono state riportate allo stato originale. L’articolo non richiede al lettore di modificare impostazioni, quindi non è necessario eseguire un ripristino sul proprio computer.
Fonti primarie pubbliche
Sezione intitolata “Fonti primarie pubbliche”- Microsoft: Windows Performance Recorder — strumento di registrazione delle tracce ETW utilizzato nella metodologia; verificato il 2026-09-20.
- Microsoft: About Event Tracing — modello ETW e verifica degli eventi persi; verificato il 2026-09-20.
- Microsoft: Microsoft Defender Antivirus in Windows — processi e servizi di Defender, incluso
MsMpEng.exe(«Antimalware Service Executable» in Gestione attività); verificato il 2026-09-20. - Come analizziamo Windows — livelli di evidenza e protocollo di misurazione.
- Service Host e componenti in background di Windows 11 — come Windows ospita i servizi in background nei processi.
- Quanta memoria si può liberare davvero in Windows — analisi dettagliata della memoria in questo stesso esperimento.
- Desktop e schermata di accesso — seguito: da cosa è composto il rumore della sessione utente.
Cronologia delle modifiche
Sezione intitolata “Cronologia delle modifiche”- 2026-09-20: prima pubblicazione: due serie indipendenti di misurazioni in idle, fasi successive all’avvio, inventario e test di carico.
- 2026-09-20: precisata l’attribuzione dei risultati alle serie (commit e memoria fisica utilizzata: solo serie 2; processi −49…−56 %); la dichiarazione sul conflitto di interessi è stata uniformata alla formulazione canonica.