Quiet idle: Windows background before and after optimization
On this page
Short answer
Section titled “Short answer”Disabling background Windows components does make idle time quieter: in two independent measurement series, the number of processes fell by 49–56 %, idle CPU usage by 17–67 %, and memory commit by 52 % in the second series. But under full CPU load, throughput grew by only 0.2–0.5 %. “Quiet idle” is a confirmed reduction in background work and resource contention, not an FPS gain: the final gaming effect was not measured in this study.
Status: the direction of the effect was reproduced in two independent series on the same Windows 11 build in a virtual machine. The magnitudes differ between series because Windows background work comes in bursts: in a window with a Microsoft Defender scan, the CPU usage difference reaches −67 %, in an already quiet window — −17 %.
Testable claim
Section titled “Testable claim”We tested four claims:
- Disabling background components noticeably reduces system activity at idle.
- It noticeably reduces activity in the first minutes after boot.
- It noticeably reduces memory consumption.
- It gives a measurable performance gain under full CPU load.
Scope of the study
Section titled “Scope of the study”- Windows 11 Pro, build 26300.9457 (26H2);
- virtual machine: 4 vCPU, 8 GB RAM, VMware virtualization;
- two states of one installation: the original (“before”) and after applying the BoosterX optimization profile (the build current on the measurement dates);
- two independent measurement series: 2026-09-18 and 2026-09-19; the states were compared on independent disk copies so that measurements would not affect each other;
- phases: 5 minutes after boot, 5 minutes of stabilization, 5 minutes of idle;
- short synthetic loads: 1, 4 and 8 threads, memory load, paced load and priority mixes.
The measurements did not include real games, GPU load, physical hardware or long windows (hours and days).
Methodology
Section titled “Methodology”The protocol follows “How we research Windows”:
- each phase was recorded with an ETW trace (Windows Performance Recorder, lightweight CPU, disk, file and network profiles) and performance counters at a 5-second interval (system) and 15-second interval (per process);
- the “after boot” phase was started by a controlled reboot and began at an uptime of about one minute;
- the number of lost events was checked in each trace — in all the windows presented it is zero;
- averaging was performed only over complete five-second intervals within the phase boundaries (59 intervals per phase);
- in series 2, the first “before” run was excluded because the virtual machine went to sleep; the repeat was used;
- load trials were run twice, medians are given; CPU usage is normalized to four vCPU.
“Before” and “after” are states of one Windows installation: “after” was obtained by applying the optimization profile, “before” is the original state. The set of settings was changed as a whole, so the isolated contribution of an individual disabling was not evaluated.
Results
Section titled “Results”Series 1 (2026-09-18) — settled idle without active maintenance:
| Metric | Before | After | Change |
|---|---|---|---|
| CPU usage, % | 2.48 | 2.06 | −17 % |
| DPC + ISR, % CPU | 1.73 | 1.59 | −8 % |
| Context switches, /s | 469 | 381 | −19 % |
| Processes (average) | 134.9 | 69.3 | −49 % |
| Threads (average) | 1 444.6 | 738.7 | −49 % |
| Total CPU of all processes, % | 1.22 | 1.06 | −13 % |
| Available memory, MB | 5 490 | 6 518 | +1 028 |
| Disk read, KB/s | 22.6 | 24.4 | +8 % |
| Disk write, KB/s | 311.3 | 262.1 | −16 % |
| Network (receive), KB/s | 132.6 | 2.2 | −98 % |
| Network (send), KB/s | 43.2 | 4.7 | −89 % |
Series 2 (2026-09-19) — the same idle window, but in the “before” state a background Microsoft Defender scan was running:
| Metric | Before | After | Change |
|---|---|---|---|
| CPU usage, % | 33.37 | 11.03 | −67 % |
| Context switches, /s | 3 737 | 291 | −92 % |
| Processes (average) | 142.3 | 61.9 | −56 % |
| Threads (average) | 1 494.7 | 637.1 | −57 % |
| Available memory, MB | 5 174 | 6 653 | +1 479 |
| Used physical memory, MB | 3 017 | 1 538 | −49 % |
| Memory 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 % |
| Disk read, MB/s | 7.42 | 0.01 | −99.9 % |
| Disk write, MB/s | 4.57 | 0.23 | −95.0 % |
There was almost no network activity at idle in series 2 in either state (tens of bytes per second), so network rows are not given for it. The difference between series is not a contradiction but a property of the background itself: when Windows is performing maintenance, disabling background components saves more; when the window is already quiet — less.
First minutes after boot
Section titled “First minutes after boot”| Metric | Series 1 (before → after) | Series 2 (before → after) |
|---|---|---|
| CPU usage, % | 3.42 → 2.59 | 14.62 → 11.88 |
| Context switches, /s | 1 114 → 600 | 1 257 → 393 |
| Processes | 132 → 74 | 139 → 64 |
| Threads | — | 1 719 → 746 |
| Used physical memory, MB | — | 2 821 → 1 581 |
| Available memory, MB | — | 5 370 → 6 610 |
| Disk read, KB/s | — | 826 → 433 |
| Disk write, KB/s | 634 → 418 | 709 → 298 |
| Network (receive), KB/s | — | 1.15 → ~0 |
A dash means that in that series the metric was not recorded for the phase.
Composition and memory
Section titled “Composition and memory”Inventory snapshot at idle (series 1):
| Before | After | |
|---|---|---|
| Processes | 136 | 70 |
| Threads | 1 679 | 842 |
| Total working set, MB | 3 841 | 1 868 |
| Total private bytes, MB | 1 524 | 660 |
The largest memory consumers before optimization: the antivirus process MsMpEng.exe (257 MB), explorer.exe (213 MB), StartMenuExperienceHost (144 MB), msedge.exe (133 MB), SearchHost.exe (122 MB). After optimization, the list was topped by explorer.exe (170 MB), msedgewebview2 (119 MB), SearchHost.exe (115 MB) and StartMenuExperienceHost (106 MB).
Available memory grew by 1.0–1.5 GB, and memory commit fell by 52 %. What of this can actually be “freed” and why the sum of process working sets is not the same as free memory is analyzed in “How much memory can actually be freed in Windows”.
Under full load
Section titled “Under full load”Short synthetic trials (series 2, medians of two repeats):
| Scenario | Throughput change | CPU usage: before / after |
|---|---|---|
| Single thread | +5.4 % | 21.9 / 22.6 % |
| Four threads (full) | +0.19 % | 88.9 / 89.4 % |
| Eight threads (full) | +0.50 % | 88.9 / 88.8 % |
| Memory load | +11.2 % | 84.8 / 87.5 % |
| Paced (1 ms pauses) | +5.4 % | 64.3 / 67.7 % |
| Mixed priorities | +8.5 % | 21.2 / 22.5 % |
| Background priority | +77.1 % | 38.8 / 65.2 % |
Under full four-thread load, the useful process received about 89 % of the capacity of four vCPU both before and after optimization. The remaining ~11 % in a virtual machine cannot be declared eliminable “Windows noise”: hypervisor scheduling is not visible from a guest trace. Worker threads were distributed evenly (the spread of work volume between them — 0.994–0.997), no starvation was observed, and the CPU queue at idle after optimization is practically empty.
Where the background goes
Section titled “Where the background goes”Measured sources of background activity in the “before” state:
- antivirus scanning — the main source in the series 2 window: the process
MsMpEng.execonsumed 212 CPU-seconds during the five-minute idle window; - in the original state, the search service, the SysMain service, telemetry, the print spooler and other components were running — the optimization profile puts about 50 background services and 58 scheduled tasks into a disabled state;
- after boot, activity accompanies the Windows update orchestrator.
Disabling background components does not eliminate the background entirely: in the optimized state, the application compatibility assessment continued to run (about 3.7 ms CPU per second in the maintenance window), and the total residual background in settled idle was 4.8 ms CPU per second — about 0.12 % of the capacity of four vCPU (measured from the trace).
What is confirmed
Section titled “What is confirmed”- Reproduced (two independent series): number of processes −49…−56 %, threads −49…−57 %, available memory +1.0–1.5 GB.
- Measured (series 2): commit −52 % at idle; used physical memory −49 % at idle and −44 % in the after-boot phase.
- Measured: idle CPU usage −17 % in a quiet window and −67 % in a window with scanning; context switches −19 % and −92 %; DPC −78 % (series 2 window); activity after boot is lower in both series.
- Measured: under full CPU load, throughput gain +0.19 % (4 threads) and +0.50 % (8 threads); under partial and mixed load — from +5.4 to +11.2 %.
- Measured: a background-priority-class load sped up by 77.1 % — in the “before” state it competed with Windows’ own background work, including antivirus scanning.
- Observed: the main sources of background are antivirus scanning, maintenance and compatibility tasks; after optimization the residual background is close to zero, but not zero.
What is not confirmed
Section titled “What is not confirmed”- FPS gain, reduced input lag or frametime in real games: not measured. Synthetic CPU trials do not model a game with a GPU and do not prove a gaming effect.
- The isolated contribution of each individual disabling: a set of changes was applied.
- Transfer of absolute magnitudes to physical hardware, other builds and other optimization profiles.
- Stability over long windows: each phase is 5 minutes; Windows background work comes in bursts, so an “average day” was not measured.
Limitations
Section titled “Limitations”- The measurements were performed in a virtual machine. Virtualization introduces its own share of DPC/ISR and hides host scheduling; on physical hardware the absolute values will be different. The shares and the direction of the “before/after” comparison under identical conditions are preserved.
- The ISR metric is excluded from the tables: in a virtual machine, the ISR counter via PDH diverges from interrupt handlers via ETW by about 10 % and does not add up to an exact sum.
- The “before” window of series 2 contained an active Defender scan, and the host load differed between windows (on average 44 % versus 24 %). Therefore the magnitudes are tied to specific windows; the direction is confirmed by two series.
- In series 1, part of the idle phase was interrupted by an external virtual machine pause of about 26 seconds; the capture completed after resumption, there are no lost events.
- The load trials are two repeats: this is descriptive statistics, statistical significance was not evaluated.
- Part of the idle gain is due to disabling Microsoft Defender protection components. A system without antivirus protection is a deliberate trade-off, not optimization without costs; protection should be disabled with an understanding of the price.
- The measurement layer (trace and counters) itself creates a small background load; it is present in both states.
The study and the tools used belong to the BoosterX developer, so the developer has a direct interest in the results. The methodology and the limits of applicability are described above, and the conclusions can be verified against the open data and the public sources listed.
Practical takeaway
Section titled “Practical takeaway”The reduction of background noise is a real, twice-reproduced effect: half as many processes and threads, half the memory commit, an order of magnitude less disk and network activity at idle. This is useful in itself — for system responsiveness, background tasks, temperature, fan noise and battery life — and does not require promises of FPS.
What should not be expected from it: a performance gain under full load. If the CPU is already loaded with useful work at ~89 % of capacity, disabling background activity will not add the remaining 11 % — in a virtual machine they do not belong to Windows. The more the system is busy at the moment of comparison, the greater the visible effect: in a maintenance window the difference is manyfold, in a quiet window — moderate.
Recommendation: evaluate the background before and after any changes on your own computer (Task Manager → “Performance” and “Processes”, Resource Monitor), rather than relying on someone else’s percentages. If the goal is FPS in a specific game, measure exactly that before and after the change.
State restoration
Section titled “State restoration”Both series were performed in isolated virtual machines on independent disk copies; after the measurements the machines were returned to their original states. The article does not require the reader to change any parameters, so a separate restoration action on the user’s computer is not needed.
Public primary sources
Section titled “Public primary sources”- Microsoft: Windows Performance Recorder — the ETW trace recording tool used in the methodology; checked 2026-09-20.
- Microsoft: About Event Tracing — the ETW model and lost event checking; checked 2026-09-20.
- Microsoft: Microsoft Defender Antivirus in Windows — Defender processes and services, including
MsMpEng.exe(“Antimalware Service Executable” in Task Manager); checked 2026-09-20. - How we research Windows — evidence levels and measurement protocol.
- Service Host and background components of Windows 11 — how Windows places background services across processes.
- How much memory can actually be freed in Windows — a detailed analysis of memory from this same experiment.
- Desktop versus sign-in screen — a continuation: what the noise of a user session consists of.
Change history
Section titled “Change history”- 2026-09-20: first publication — two independent series of idle measurements, after-boot phases, inventory and load trials.
- 2026-09-20: attribution of results by series clarified (commit and used physical memory — series 2 only; processes −49…−56 %); the conflict-of-interest disclaimer brought to the canonical wording.