Windows 11 e progetto 20/20: il piano per ridurre uso di RAM e spazio su disco

Una parte rilevante delle prestazioni percepite di un sistema operativo dipende da ciò che accade quando l’utente non sta facendo nulla. Il consumo di memoria a riposo rappresenta un indicatore concreto dell’efficienza architetturale, ed è proprio su questo parametro che Microsoft aveva già tentato un intervento mirato anni fa. Un progetto interno, noto come “20/20”, mirava a ridurre del 20% sia l’uso di RAM in idle sia la dimensione dell’installazione di Windows. L’iniziativa non è mai arrivata a conclusione, ma il problema che intendeva risolvere è oggi più attuale che mai, in un contesto in cui Windows 11 continua a richiedere risorse elevate anche su hardware moderno.

Il riferimento a questo progetto è riemerso in un post su X di Mikhail Parakhin, ex responsabile di Windows e Bing, proprio mentre Microsoft torna a parlare apertamente di ottimizzazione, reattività e riduzione del footprint di sistema.

Su una configurazione tipica, Windows 11 può occupare tra 5 e 6 GB di memoria subito dopo l’avvio, una soglia significativa se confrontata con versioni precedenti come Windows 7 o Windows 10 nelle loro prime release. Il tentativo di contenere questo valore si scontra con una trasformazione profonda del sistema operativo, sempre più orientato a servizi persistenti e integrazione cloud.

Windows 11: servizi in background e memoria sempre attiva

La crescita del consumo di RAM in Windows 11 deriva in larga parte dall’espansione dei servizi attivi in background.

Componenti come Windows Defender eseguono scansioni in tempo reale, mentre il servizio Search Indexer mantiene aggiornati gli indici dei file per garantire ricerche istantanee. A questi si aggiungono moduli di telemetria, sincronizzazione cloud tramite OneDrive e aggiornamenti automatici gestiti dal servizio Windows Update.

Sono processi che non si limitano a occupare memoria in modo statico: mantengono thread attivi, cache in memoria e strutture dati persistenti, con un impatto diretto sulla cosiddetta “baseline memory usage”. L’approccio utilizzato privilegia la reattività percepita: dati già pronti in RAM riducono i tempi di risposta, ma al costo di un consumo costante anche in assenza di interazioni.

Il software gratuito RAMMap permette di studiare l’uso della memoria RAM in Windows: è sviluppato da Microsoft, consente di stabilire quali processi occupano più risorse e permette di scoprire (e risolvere) anomalie con i memory leak.

Applicazioni web e overhead del motore Chromium

Un cambiamento meno evidente ma altrettanto significativo riguarda il modo in cui le applicazioni vengono sviluppate.

Sempre più software per Windows utilizzano tecnologie basate su browser, in particolare framework come Electron o integrazioni tramite WebView2. Di fatto tante applicazioni eseguono ora una propria istanza del motore Chromium, con processi separati per rendering, JavaScript e gestione della GPU.

Il risultato è un aumento consistente del consumo di memoria per singola applicazione. Programmi diffusi come client di messaggistica o strumenti di collaborazione possono occupare centinaia di megabyte anche quando inattivi.

Una stack grafica frammentata

Windows 11 non si basa su un unico framework di interfaccia. Sotto il suo ombrello convive una combinazione di tecnologie storiche e moderne: Win32 per le applicazioni legacy, WinUI 3 per lo sviluppo più recente. A queste si affiancano elementi basati su tecnologie Web, inclusi componenti sviluppati con React.

Questa eterogeneità comporta la presenza simultanea di più pipeline di rendering, ciascuna con le sue dipendenze e strutture in memoria.

Il sistema deve mantenere compatibilità retroattiva e allo stesso tempo supportare nuovi modelli di sviluppo, con un inevitabile aumento dell’overhead. Il passaggio graduale verso WinUI 3 rappresenta un tentativo di ridurre questa complessità, ma richiede la riscrittura di porzioni significative del codice di sistema.

Il progetto 20/20 e i limiti architetturali

Ridurre del 20% il consumo di RAM in idle non è un intervento superficiale: richiede modifiche profonde alla gestione dei servizi, alla struttura delle librerie condivise e alla logica di caricamento dei componenti.

Il progetto 20/20 si inseriva in un periodo in cui Microsoft stava espandendo le funzionalità di Windows, introducendo integrazioni cloud, nuovi modelli di sicurezza e, successivamente, funzionalità legate all’intelligenza artificiale.

Sono direttrici che cozzano contro l’obiettivo di ridurre l’uso delle risorse: ogni nuova funzionalità implica nuovi processi, nuove dipendenze e nuove esigenze di caching. Limitare l’uso della memoria avrebbe richiesto compromessi sul piano funzionale o una revisione radicale dell’architettura, con costi elevati in termini di sviluppo e compatibilità.

Le comunicazioni più recenti indicano che Microsoft intende intervenire su tre aree principali. La prima riguarda la riduzione della memoria di base, attraverso una gestione più aggressiva della deallocazione e una revisione delle dipendenze tra componenti. La seconda punta alla riduzione della latenza nelle interazioni, intervenendo sullo scheduling dei thread e sulla priorità dei processi legati ad applicazioni effettivamente utilizzate dall’utente.

La terza area coinvolge la convergenza verso framework nativi, in particolare WinUI 3, con l’obiettivo di eliminare livelli intermedi e ridurre l’overhead delle interfacce.

Pressioni esterne e nuovi vincoli hardware

Il contesto competitivo ha assunto un ruolo determinante. I sistemi basati su architetture ARM, come quelli utilizzati da Apple con i chip della serie M, hanno introdotto standard più elevati in termini di efficienza energetica e gestione della memoria. Allo stesso tempo, l’aumento dei costi della RAM ha reso meno scontata la disponibilità di grandi quantità di memoria nei dispositivi consumer.

Un sistema operativo che richiede più risorse rispetto ai concorrenti rischia di diventare meno competitivo, soprattutto in ambito mobile e portatile. La pressione verso Microsoft, inoltre, non arriva solo dal mercato, ma anche dagli utenti, sempre più sensibili a problemi di prestazioni che un tempo passavano inosservati.

Il ritorno a obiettivi simili a quelli del progetto 20/20 suggerisce che Microsoft riconosce la necessità di intervenire in profondità, non solo a livello superficiale ma nella struttura stessa del sistema operativo.