If your 8GB PC becomes sluggish when a game, browser and other apps are open together, Windows 11’s memory changes are relevant to investigate. A lower RAM reading alone cannot tell you whether gameplay improved. Start by checking the update, then compare memory pressure and frame delivery under the same workload.
What changed in Windows 11’s memory handling?
The changes detailed on 3 November 2026 focus on compression and paging decisions for 8GB PCs, prioritising interactive work, and reducing memory commitments in Windows and key apps. On systems with 8GB or less, Widgets is loaded when opened rather than kept loaded while closed. Some improvements depend on app updates.
These changes target everyday responsiveness and multitasking. The published desktop workloads do not establish a gaming FPS uplift. Treat a quicker Start menu, faster app switching and steadier gameplay as separate outcomes; this guide provides a way to investigate the last of those.
Check the Windows version before comparing
As of 4 November 2026, the stated update target is Windows 11 version 26H2, build 26300.9818 or later. Build 26300.9818 is associated with KB5127936, released on 28 October as an optional preview. Availability can vary by device, and installing a build does not prove every feature has reached that PC.
- Open Settings > System > About. Record installed RAM under Device specifications and the Windows version and OS build under Windows specifications.
- Open Settings > Windows Update and select Check for updates. The latest-update toggle can bring changes earlier; optional previews may also appear under Advanced options > Optional updates. Read the offered update’s details before choosing it.
- Keep Microsoft Edge, Microsoft 365 and Teams updated if you use them. Record their versions when they form part of your comparison.
- Restart when required, let update and setup activity settle, and record the new build before measuring. Keep the game version, graphics driver and settings unchanged where possible.
If the target update is not offered, leave that fact in your notes. Avoid forcing a different Windows installation solely to chase a presumed FPS gain. A comparison across a Windows update tests the combined update unless you can isolate individual changes.
Read memory pressure, not just RAM percentage
Windows can retain reusable data in RAM and reclaim it when needed. Compression also lets less-active data occupy less physical space. Neither a busy memory graph nor a large cache alone establishes a problem; look for symptoms during your actual game session.
Three measurements answer different questions. Available memory describes capacity Windows can make available to processes. A process’s working set describes pageable data currently resident in physical RAM. Committed memory tracks memory Windows has promised to support; its limit is backed by RAM and page files. Commit is not a counter of bytes currently stored in the page file.
| Measurement | What to look for | What it cannot prove alone |
|---|---|---|
| Available memory | Whether capacity remains constrained during the troublesome workload | The cause of a particular hitch |
| Committed memory and its limit | Whether allocation demand approaches what the system can support | How much data is being read from storage right now |
| Hard faults and storage reads | Whether retrieving pages from storage coincides with the slowdown | That every read came from the page file |
| Frame-time capture | Whether long frames become less frequent or severe | That memory management caused the change |
A hard page fault means a requested page must be read from its backing storage. That can be the page file or a memory-mapped file. It is not a report of faulty RAM, and occasional activity is not a diagnosis. Repeated faults coinciding with low available memory and hitches justify a closer look.
Keep the page file available for this comparison. Disabling it changes the commit limit and can prevent allocations from succeeding when demand is high. Reaching that limit can cause freezing or crashes; removing it is not a useful shortcut to testing the Windows memory changes.
Compare the same game with and without one background app
Use this as a diagnostic method, not a completed benchmark. First find out whether your normal background workload changes the symptom on the current build. That is a separate question from whether a Windows update improves it.
- Choose a repeatable benchmark or short saved-game route. Fix resolution, graphics preset, frame cap and capture duration. Use the same power setting and, on a laptop, the same plugged-in state.
- Press Ctrl + Shift + Esc and open Task Manager > Performance > Memory. Note Available and Committed before launch and during a representative part of the session. Use the Processes view to identify the app you plan to compare.
- For a closer look, open Resource Monitor from Windows Search. In Memory, watch Hard Faults/sec for the game and relevant apps; in Disk, check read activity and file paths. Note when the hitch occurs. Switching away from the game changes the workload, so treat manual observations as clues rather than precise timing evidence.
- Use a frame-time capture tool such as PresentMon to record the route. Keep its version, capture metric and configuration consistent. Compare the frame-time trace alongside average FPS; a similar average can conceal occasional long frames.
- Run the route several times with your usual apps open. Close one non-essential app normally, repeat the same runs, then reopen it and repeat. Keep required game services and security protection running.
- Record the range of results rather than only the best run. Give both conditions equivalent warm-up runs and keep cache handling consistent. If the difference is smaller than the variation between runs, call the result inconclusive.
Closing a browser or another app changes more than memory demand: it can also change CPU and storage activity. If the game improves, you have evidence to investigate that app’s contribution, not proof that RAM was the only cause.
Did Your Shader Stutter Fix Work? How to Test Without Cache Bias
Interpret the result before choosing a fix
| Repeated observation | Reasonable interpretation | Next step |
|---|---|---|
| App switching improves, game traces remain similar | Desktop responsiveness changed without a demonstrated gaming gain | Report the two outcomes separately |
| Closing one app repeatedly reduces hitches and memory pressure | That background workload is worth investigating | Repeat with the app restored and compare CPU and disk activity too |
| RAM use drops but frame delivery stays the same | The memory reduction has no demonstrated gaming benefit in this test | Keep the change only if its other benefits matter to you |
| Hitches persist without a matching memory-pressure pattern | The current evidence does not identify RAM pressure as the cause | Broaden the investigation rather than keep removing apps |
For a before-and-after update comparison, repeat both background-app conditions on the same PC with equivalent settings and warm-up. Record any unavoidable driver or game changes. If several components changed together, do not assign the result to compression, Widgets or Windows scheduling alone.
If memory pressure remains repeatable under the workload you need, compare that demand with your game’s requirements and the PC’s supported upgrade options. Better management does not add physical RAM. An 8GB result also does not establish what happens on a 16GB or 32GB system.
When memory evidence is weak, move on to a broader frame-time investigation.
High FPS but Game Still Stutters? How to Fix Frame Time Spikes
FAQ
No gaming uplift is established by the desktop responsiveness and multitasking workloads discussed here. Compare the same game route and capture settings on your PC; report app switching and gaming results separately.
Not by itself. Windows can retain useful data in RAM and reclaim it. Check available memory, commit demand and the timing of symptoms during play before deciding that memory pressure needs attention.
No. A hard page fault requires a page to be retrieved from backing storage, which may be a page file or a memory-mapped file. The counter alone does not identify a hardware error or prove the cause of stutter.
Keep it available during diagnosis. A page file contributes to the system commit limit. Removing that capacity can leave memory allocations unsupported under heavy demand and cause freezing or crashes; it does not demonstrate that gameplay became smoother.
