Desktop contro schermata di accesso: quanto costa una sessione utente
In questa pagina
Risposta breve
Sezione intitolata “Risposta breve”Un desktop con sessione attiva costa più della schermata di accesso, ma molto meno di quanto sembri: in inattività stazionaria occupa circa 0.012 core contro 0.0074 sulla schermata di accesso, cioè 1.6 volte tanto. Il vero costo della sessione utente è la prima ora dopo l’accesso: la scansione di Defender e l’ondata di aggiornamenti dello Store insieme consumano circa il 79% di tutta l’attività CPU della finestra di cinque ore. La shell in sé è quasi gratuita: explorer, sihost, dwm e il feed del menu Start insieme spendono circa il 2.3% del budget.
Stato: misurato in un’unica esecuzione di 5 ore su Windows 11 26H2 in una macchina virtuale. Il confronto con la schermata di accesso è stato fatto sulla stessa build e sullo stesso snapshot. Il trasferimento su hardware fisico, altre build e finestre notturne non è stato verificato.
Affermazione verificabile
Sezione intitolata “Affermazione verificabile”Abbiamo verificato quattro affermazioni:
- Un desktop con sessione attiva costa molto più dell’inattività della schermata di accesso.
- Il costo principale della sessione è il funzionamento costante della shell.
- La sessione utente cambia sensibilmente il profilo di rete in inattività.
- I meccanismi pianificati di Windows (aggiornamenti, timer di servizio) si comportano nella sessione come senza di essa.
Ambito della ricerca
Sezione intitolata “Ambito della ricerca”- Windows 11 Pro, build 26300.9457 (26H2), macchina virtuale 4 vCPU / 8 GB;
- installazione pulita senza software di terze parti; sospensione e aggiornamenti di configurazione non sono stati disattivati;
- due esecuzioni sullo stesso snapshot: schermata di accesso senza sessione utente (6 ore) e desktop con sessione attiva (4 ore e 46 minuti, interrotta in anticipo);
- accesso effettuato manualmente; l’osservazione è iniziata dopo la conferma dell’avvio della shell;
- snapshot al minuto: CPU dei processi, insiemi di servizi in esecuzione, memoria e connessioni stabilite.
Le misurazioni non includevano hardware fisico, lavoro reale al computer, carico GPU e finestre notturne (le attività di manutenzione giornaliere non sono entrate nel campione).
Metodologia
Sezione intitolata “Metodologia”Per ogni processo, una volta al minuto, venivano registrati i secondi CPU accumulati; la differenza tra snapshot adiacenti fornisce il consumo nell’intervallo. I servizi erano tracciati tramite gli insiemi di istanze in esecuzione e le transizioni; la rete tramite le connessioni stabilite al momento dello snapshot. Il rumore del monitoraggio stesso (circa 3.6% CPU) è escluso dall’interpretazione. Entrambe le esecuzioni sono state confrontate su valori normalizzati all’ora.
Risultati
Sezione intitolata “Risultati”Confronto riepilogativo
Sezione intitolata “Confronto riepilogativo”| Metrica | Schermata di accesso | Desktop | Differenza |
|---|---|---|---|
| CPU in media per finestra, core | 0.0098 | 0.0492 | ×5.0 |
| CPU dell’ora stazionaria, core | 0.0074 | 0.0120 | ×1.61 |
| CPU della prima ora dopo l’accesso/avvio, core | 0.0185 | 0.2942 | ×15.9 |
| Avvii di processi di sistema all’ora | 26.1 | 79.5 | ×3.05 |
| Minuti con attività superiore a 1 CPU-s | 5% | 13.5% | ×2.4 in quota |
| Connessioni stabilite all’ora (minuti-endpoint) | 88.3 | 228.1 | ×2.58 |
| Connessioni permanenti | 1 | 3 | ×3 |
Fatto chiave: la cifra media «×5» è quasi interamente composta dalla prima ora. Le ore stazionarie del desktop sono omogenee (0.0118–0.0127 core) e non derivano.
Prima ora: due ondate
Sezione intitolata “Prima ora: due ondate”| Ondata | Quota | Cosa accadeva |
|---|---|---|
| Scansione di accesso di Defender | ~55% CPU dell’ora | Il processo antivirus ha lavorato circa 0.7 core per 8 minuti di fila; la scansione è iniziata subito dopo l’accesso |
| Aggiornamento Store e USO | ~27% CPU dell’ora | Installazione di 24 applicazioni, download di circa 880 MB tramite Delivery Optimization, incluso il peering |
L’ondata dello Store è importante a parte: in questa esecuzione gli aggiornamenti sono arrivati tramite Microsoft Store e Delivery Optimization, non tramite il classico Windows Update. Il picco di rete all’accesso è 67 volte maggiore del livello stazionario.
Inattività stazionaria: chi lavora
Sezione intitolata “Inattività stazionaria: chi lavora”| Fonte | Secondi CPU all’ora | Commento |
|---|---|---|
| Struttura svchost complessiva | 13–14 | Timer dei servizi |
| Kernel (System) | 8 | Parte del lavoro di Defender e dell’infrastruttura |
| Antivirus fuori scansione | ~3 | Controlli periodici |
| Shell (explorer, sihost, dwm, feed del menu Start, ricerca, widget, OneDrive) | 4.1 | 2.3% del budget; il «desktop inattivo» è quasi gratuito |
Tre quarti della differenza negli avvii dei processi sono dati dai meccanismi periodici della sessione utente: l’host in background delle attività UWP (ciclo di circa 13 minuti), RuntimeBroker e SoftLanding ogni 15 minuti.
Rete: tre connessioni permanenti e due nuovi timer
Sezione intitolata “Rete: tre connessioni permanenti e due nuovi timer”Sulla schermata di accesso vive una sola connessione permanente. Sul desktop ce ne sono tre: due sono mantenute dal feed del menu Start (contenuto MSN: meteo, notizie, riquadri live) dal primo minuto e senza interruzioni, la terza è un servizio di sistema di notifiche. Il costo CPU del feed per tutta la finestra è inferiore a 2 secondi CPU, ma la connessione stessa vive sempre.
Nuovi timer della sessione: OneDrive si sincronizza ogni 32–33 minuti con due connessioni, gli aggiornamenti di Edge vengono controllati ogni alcune ore. I controlli delle firme di Defender procedono a cluster ogni 30–40 minuti. Tutto il traffico è diretto all’infrastruttura Microsoft; non sono state osservate connessioni estranee.
Timer di servizio
Sezione intitolata “Timer di servizio”L’aggiornamento dei criteri di gruppo sul desktop si ripete ogni 16–17 minuti contro circa 80 minuti sulla schermata di accesso. Il servizio applicazioni (AppXSvc) e la protezione delle licenze (sppsvc) hanno mantenuto lo stesso ritmo. Cinque servizi della sessione vivono costantemente, incluse le notifiche utente e Clipboard.
Memoria
Sezione intitolata “Memoria”Non ci sono perdite di sistema: l’antivirus dopo la scansione ha rilasciato 81 MB, la shell è cresciuta solo nei primi 30 minuti e ha raggiunto un plateau. Il numero di processi è 130–153 contro 84–98 sulla schermata di accesso.
Cosa è confermato
Sezione intitolata “Cosa è confermato”- Misurato: un desktop stazionario costa 1.61 volte più della schermata di accesso in termini di CPU; la prima ora dopo l’accesso è il costo principale della sessione (79% della CPU della finestra).
- Misurato: il feed del menu Start mantiene due connessioni permanenti per tutta la sessione; OneDrive si sincronizza ogni 32–33 minuti.
- Misurato: l’ondata dello Store all’accesso ha scaricato circa 880 MB tramite Delivery Optimization; il picco di rete all’accesso è 67 volte maggiore di quello stazionario.
- Misurato: la shell (explorer, dwm, feed del menu Start, ricerca, widget) in inattività stazionaria spende circa il 2.3% di CPU.
- Osservato: gli aggiornamenti sono arrivati tramite Store/DO, non tramite il classico WU; le attività di manutenzione notturne non sono entrate nel campione.
Cosa non è confermato
Sezione intitolata “Cosa non è confermato”- Il comportamento su hardware fisico e su altre build di Windows.
- Le finestre notturne e le attività di manutenzione giornaliere (l’esecuzione è diurna, interrotta in anticipo).
- L’influenza della disattivazione del feed del menu Start o di OneDrive su queste cifre: abbiamo solo misurato il loro contributo, la disattivazione non è stata testata.
- L’influenza su FPS e sulle prestazioni finali nei giochi: non misurata.
Limitazioni
Sezione intitolata “Limitazioni”Un’esecuzione per stato, macchina virtuale, finestra diurna. Il lavoro in background di Windows arriva a picchi, quindi il trasferimento dei valori assoluti su altro hardware e su un’intera giornata non è giustificato. I processi più brevi di un minuto e il traffico UDP (DNS, NTP) non sono visibili completamente. Parte dei log non registrava eventi durante la seconda esecuzione; le transizioni dei servizi sono state ricostruite dagli snapshot.
Conclusione pratica
Sezione intitolata “Conclusione pratica”Il «rumore di fondo di Windows» si scompone in tre cose diverse, e vanno contrastate in modi diversi. Le ondate post-login (scansione Defender e aggiornamenti Store) danno la maggior parte della CPU — non si possono spegnere con impostazioni fini, ma finiscono da sole. I metronomi di sistema (polling WMI, controlli di licenza, timer di OneDrive) sono un fondo stabile ma piccolo. La shell è quasi gratuita.
Conseguenze pratiche: non misurate l’«ottimizzazione» sulla prima ora dopo l’accesso se non isolate le ondate; per minimizzare la rete disattivate il feed del menu Start e OneDrive, se non servono; aspettarsi il «silenzio» subito dopo il login non è giustificato.
Ripristino dello stato
Sezione intitolata “Ripristino dello stato”Il sistema non è stato modificato: entrambe le esecuzioni sono pura osservazione senza modifiche a impostazioni, servizi e registro. La macchina virtuale è stata riportata allo snapshot pulito dopo le misurazioni.
Fonti e confini
Sezione intitolata “Fonti e confini”Le misurazioni sono state eseguite da BoosterX Research sulla macchina virtuale descritta. La ricerca appartiene allo sviluppatore di BoosterX, lo sviluppatore ha un interesse diretto nel risultato; la metodologia e le limitazioni sono descritte sopra, le osservazioni di partenza possono essere ripetute secondo la metodologia aperta.
- Microsoft: Delivery Optimization, verificato 2026-09-22.
- Microsoft: Connected User Experiences and Telemetry, verificato 2026-09-22.
Ultima verifica: 2026-09-22.