Idle silenzioso: attività in background di Windows prima e dopo l'ottimizzazione
In questa pagina
Risposta breve
Sezione intitolata “Risposta breve”Disattivare i componenti in background di Windows rende effettivamente più silenzioso l’idle: in due serie di misurazioni indipendenti il numero di processi è calato del 49–56 %, l’occupazione della CPU in idle del 17–67 %, e il volume dei commit di memoria del 52 % nella seconda serie. Ma sotto pieno carico della CPU la capacità di throughput è cresciuta solo dello 0,2–0,5 %. L’«idle silenzioso» è una riduzione confermata del lavoro in background e della competizione per le risorse, non un aumento degli FPS: l’effetto finale in gioco in questo studio non è stato misurato.
Stato: la direzione dell’effetto è stata riprodotta in due serie indipendenti sulla stessa build di Windows 11 in una macchina virtuale. Le grandezze tra le serie differiscono perché il lavoro in background di Windows arriva a ondate: in una finestra con la scansione di Microsoft Defender la differenza di occupazione della CPU raggiunge −67 %, in una finestra già silenziosa −17 %.
Affermazione verificabile
Sezione intitolata “Affermazione verificabile”Abbiamo verificato quattro affermazioni:
- Disattivare i 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 sotto pieno carico della CPU.
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: quello iniziale («prima») e quello dopo l’applicazione del profilo di ottimizzazione BoosterX (build attuale 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, affinché le misurazioni non 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 cadenzato e mix di priorità.
Le misurazioni non includevano giochi reali, carico sulla GPU, hardware fisico e finestre prolungate (ore e giorni).
Metodologia
Sezione intitolata “Metodologia”Il protocollo corrisponde a «Come studiamo Windows»:
- ogni fase è stata registrata con una traccia ETW (Windows Performance Recorder, profili leggeri di CPU, disco, file e rete) e con contatori di prestazioni a intervallo di 5 secondi (sistema) e 15 secondi (per processo);
- la fase «dopo l’avvio» è stata avviata con un riavvio controllato e attivata a un uptime di circa un minuto;
- in ogni traccia è stato verificato il numero di eventi persi — in tutte le finestre riportate è pari a zero;
- la media è stata calcolata solo su intervalli completi di cinque secondi all’interno dei confini della fase (59 intervalli per fase);
- nella serie 2 la prima esecuzione «prima» è stata esclusa perché la macchina virtuale è andata in sospensione; è stata usata la ripetizione;
- le prove di carico sono state eseguite due volte, sono riportate le mediane; l’occupazione della CPU è normalizzata su quattro vCPU.
«Prima» e «dopo» sono stati della stessa installazione di Windows: il «dopo» è stato ottenuto applicando il profilo di ottimizzazione, il «prima» è lo stato iniziale. È stato modificato l’insieme completo delle impostazioni, quindi il contributo isolato di una singola disattivazione non è stato valutato.
Risultati
Sezione intitolata “Risultati”Serie 1 (2026-09-18) — idle consolidato senza manutenzione attiva:
| Metrica | Prima | Dopo | Variazione |
|---|---|---|---|
| Occupazione 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 da disco, KB/s | 22,6 | 24,4 | +8 % |
| Scrittura su 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) — la stessa finestra di idle, ma nello stato «prima» era in corso una scansione in background di Microsoft Defender:
| Metrica | Prima | Dopo | Variazione |
|---|---|---|---|
| Occupazione 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 occupata, MB | 3 017 | 1 538 | −49 % |
| Commit di memoria (commit), MB | 2 617 | 1 249 | −52 % |
| Nonpaged pool, MB | 298,2 | 212,9 | −29 % |
| Paged pool, MB | 258,5 | 86,0 | −67 % |
| DPC, % CPU | 0,89 | 0,19 | −78 % |
| Lettura da disco, MB/s | 7,42 | 0,01 | −99,9 % |
| Scrittura su disco, MB/s | 4,57 | 0,23 | −95,0 % |
Nell’idle della serie 2 la rete era quasi assente in entrambi gli stati (decine di byte al secondo), perciò le righe di rete non sono riportate. La differenza tra le serie non è una contraddizione, ma una proprietà del background stesso: quando Windows esegue la manutenzione, disattivare i componenti in background fa risparmiare di più; quando la finestra è già silenziosa, di meno.
Primi minuti dopo l’avvio
Sezione intitolata “Primi minuti dopo l’avvio”| Metrica | Serie 1 (prima → dopo) | Serie 2 (prima → dopo) |
|---|---|---|
| Occupazione 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 occupata, MB | — | 2 821 → 1 581 |
| Memoria disponibile, MB | — | 5 370 → 6 610 |
| Lettura da disco, KB/s | — | 826 → 433 |
| Scrittura su disco, KB/s | 634 → 418 | 709 → 298 |
| Rete (ricezione), KB/s | — | 1,15 → ~0 |
Il trattino indica che in quella serie la metrica per la fase non è stata registrata.
Composizione e memoria
Sezione intitolata “Composizione e memoria”Istantanea dell’inventario 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 maggiori consumatori di memoria prima dell’ottimizzazione: 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 la lista è guidata da explorer.exe (170 MB), msedgewebview2 (119 MB), SearchHost.exe (115 MB) e StartMenuExperienceHost (106 MB).
La memoria disponibile è cresciuta di 1,0–1,5 GB, e il volume dei commit è calato del 52 %. Cosa di tutto questo si possa davvero «liberare» e perché la somma dei working set dei processi non sia la stessa cosa della memoria libera è analizzato in «Quanta memoria si può realmente liberare in Windows».
Sotto pieno carico
Sezione intitolata “Sotto pieno carico”Brevi prove sintetiche (serie 2, mediane di due ripetizioni):
| Scenario | Variazione della capacità di throughput | Occupazione CPU: prima / dopo |
|---|---|---|
| Un thread | +5,4 % | 21,9 / 22,6 % |
| Quattro thread (pieno) | +0,19 % | 88,9 / 89,4 % |
| Otto thread (pieno) | +0,50 % | 88,9 / 88,8 % |
| Carico sulla memoria | +11,2 % | 84,8 / 87,5 % |
| Cadenzato (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 % |
Sotto pieno carico a quattro thread il processo utile ha ricevuto circa l’89 % della capacità di quattro vCPU sia prima sia dopo l’ottimizzazione. Il restante ~11 % nella macchina virtuale non può essere dichiarato «rumore di Windows» eliminabile: la pianificazione dell’hypervisor non è visibile dalla traccia guest. I thread di lavoro erano distribuiti in modo uniforme (la dispersione del volume di lavoro tra essi — 0,994–0,997), non si è osservata carenza di CPU, e la coda della CPU in idle dopo l’ottimizzazione è praticamente vuota.
Dove finisce il background
Sezione intitolata “Dove finisce il background”Fonti misurate di attività in background nello stato «prima»:
- la scansione antivirus — la fonte principale nella finestra della serie 2: il processo
MsMpEng.exeha consumato 212 secondi di CPU in una finestra di idle di cinque minuti; - nello stato iniziale erano attivi il servizio di ricerca, il servizio SysMain, la telemetria, lo spooler di stampa e altri componenti — il profilo di ottimizzazione porta in stato disattivato circa 50 servizi in background e 58 attività pianificate;
- dopo l’avvio l’attività accompagna l’orchestratore degli aggiornamenti di Windows.
Disattivare i componenti in background non elimina del tutto il background: nello stato ottimizzato continuava a funzionare la valutazione della compatibilità delle applicazioni (circa 3,7 ms di CPU al secondo nella finestra di manutenzione), e il background residuo totale nell’idle consolidato è stato di 4,8 ms di CPU al secondo — circa lo 0,12 % della capacità di quattro vCPU (misurato tramite traccia).
Cosa è confermato
Sezione intitolata “Cosa è 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 occupata −49 % in idle e −44 % nella fase dopo l’avvio.
- Misurato: occupazione della CPU in idle −17 % in una finestra silenziosa e −67 % in una finestra con scansione; cambi di contesto −19 % e −92 %; DPC −78 % (finestra della serie 2); attività dopo l’avvio inferiore in entrambe le serie.
- Misurato: sotto pieno carico della CPU l’aumento della capacità di throughput è +0,19 % (4 thread) e +0,50 % (8 thread); con carico parziale e misto — da +5,4 a +11,2 %.
- Misurato: un carico di classe priorità in background è accelerato del 77,1 % — nello stato «prima» competeva con il lavoro in background di Windows stesso, inclusa la scansione antivirus.
- Osservato: le fonti principali del background sono la scansione antivirus, la manutenzione e le attività di compatibilità; dopo l’ottimizzazione il background residuo è prossimo a zero, ma non nullo.
Cosa non è confermato
Sezione intitolata “Cosa non è confermato”- Aumento degli FPS, riduzione dell’input lag o del frametime nei giochi reali: non misurato. Le prove sintetiche sulla CPU non modellano un gioco con GPU e non dimostrano l’effetto in gioco.
- Il contributo isolato di ogni singola disattivazione: è stato applicato un insieme di modifiche.
- Il trasferimento delle grandezze assolute su hardware fisico, altre build e altri profili di ottimizzazione.
- La stabilità su finestre lunghe: ogni fase è di 5 minuti; il lavoro in background di Windows arriva a ondate, perciò la «giornata media» non è stata misurata.
- Le misurazioni sono state eseguite in una macchina virtuale. La virtualizzazione introduce una propria quota di DPC/ISR e nasconde la pianificazione dell’host; su hardware fisico i valori assoluti saranno diversi. Le quote e la direzione del confronto «prima/dopo» in condizioni identiche si conservano.
- La metrica ISR è esclusa dalle tabelle: in una macchina virtuale il contatore ISR via PDH diverge dai gestori di interrupt via ETW di circa il 10 % e non converge in una somma esatta.
- La finestra «prima» della serie 2 conteneva una scansione attiva di Defender, e il carico dell’host tra le finestre era diverso (in media 44 % contro 24 %). Perciò le grandezze sono legate a finestre specifiche; la direzione è confermata da due serie.
- Nella serie 1 parte della fase di idle è stata interrotta da una pausa esterna della macchina virtuale di circa 26 secondi; la cattura è terminata dopo la ripresa, non ci sono eventi persi.
- Le prove di carico — due ripetizioni: è statistica descrittiva, la significatività statistica non è stata valutata.
- Parte del guadagno in idle è legata alla disattivazione dei componenti di protezione di Microsoft Defender. Un sistema senza protezione antivirus è un compromesso consapevole, non un’ottimizzazione senza costi; disattivare la protezione va fatto comprendendone il prezzo.
- Lo strato di misurazione (traccia e contatori) crea esso stesso un piccolo carico in background; è presente in entrambi gli stati.
Lo studio e gli strumenti utilizzati appartengono allo sviluppatore di BoosterX, perciò lo sviluppatore ha un interesse diretto nei risultati. La metodologia e i limiti di applicabilità sono descritti sopra, e le conclusioni possono essere verificate sui dati aperti e sulle fonti pubbliche elencate.
Conclusione pratica
Sezione intitolata “Conclusione pratica”La riduzione del rumore in background è un effetto reale, riprodotto due volte: metà dei processi e dei thread, metà dei commit di memoria, un ordine di grandezza in meno di attività su disco e rete in idle. È 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 di FPS.
Cosa non ci si deve aspettare: un aumento delle prestazioni sotto pieno carico. Se la CPU è già caricata di lavoro utile per circa l’89 % della capacità, disattivare l’attività in background non aggiungerà il restante 11 % — nella macchina virtuale non appartiene a Windows. Più il sistema è impegnato nel momento del confronto, maggiore è l’effetto visibile: in una finestra di manutenzione la differenza è multipla, in una finestra silenziosa è moderata.
Raccomandazione: valutate il background prima e dopo qualsiasi modifica sul vostro computer (Task Manager → «Prestazioni» e «Processi», Monitoraggio risorse), invece di orientarvi sulle percentuali altrui. Se l’obiettivo sono gli FPS in un gioco specifico, misurate proprio quelli 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; dopo le misurazioni le macchine sono state riportate allo stato iniziale. L’articolo non richiede al lettore di modificare parametri, quindi non serve alcuna azione di ripristino separata sul computer dell’utente.
Fonti primarie pubbliche
Sezione intitolata “Fonti primarie pubbliche”- Microsoft: Windows Performance Recorder — lo strumento di registrazione delle tracce ETW usato nella metodologia; verificato il 2026-09-20.
- Microsoft: About Event Tracing — il modello ETW e la 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 Task Manager); verificato il 2026-09-20. - Come studiamo Windows — livelli di prova e protocollo delle misurazioni.
- Service Host e componenti in background di Windows 11 — come Windows distribuisce i servizi in background tra i processi.
- Quanta memoria si può realmente liberare in Windows — analisi dettagliata della memoria dallo stesso esperimento.
- Desktop contro schermata di accesso — seguito: di cosa è fatto il rumore della sessione utente.
Cronologia delle modifiche
Sezione intitolata “Cronologia delle modifiche”- 2026-09-20: prima pubblicazione — due serie indipendenti di misurazioni dell’idle, fasi dopo l’avvio, inventario e prove di carico.
- 2026-09-20: precisata l’attribuzione dei risultati per serie (commit e memoria fisica occupata — solo serie 2; processi −49…−56 %); il disclaimer sul conflitto di interessi è stato portato alla formulazione canonica.