Microsoft’s quiet fix for File Explorer is a rare example of a company acknowledging a persistent UX problem and shipping an opt‑in mitigation — but it only buys you half the benefit unless you also flip a setting most users don’t know about. The upshot: if you switch File Explorer’s default from the cloud‑heavy Home view to This PC and (when available) enable Microsoft’s new preloading experiment, Explorer finally feels fast again — often matching the snappiness many users remember from Windows 10. That combination is the practical fix Windows power users are deploying today, and it’s worth understanding exactly why it works, what Microsoft actually changed, and the trade‑offs you should consider before applying it across many machines. m])
Background
Why File Explorer felt slower in Windows 11
When Microsoft redesigned the Windows 11 shell, it modernized many UI surfaces by introducing WinUI/XAML elements on top of the legacy Win32 core. That modernization brought a cleaner look and new capabilities, but it also introduced new composition and initialization costs. File Explorer — a highly optimized, frequently used surface in Windows 10 — became a hybrid: a Win32-backed file enumerator married to WinUI front-end components. Every cold launch now potentially touches XAML rendering code, thumbnail/preview handlers, shell extensions and cloud provider integrations, all before the window becomes fully interactive. Independent technical writeups and engineering analyses have repeatedly pointed to this WinUI/Win32 fusion as a major cause of the perceived cold‑start lag.
Meanwhile, Microsoft layered deeper cloud and productivity integrations into the File Explorer Home view: recent files pulled from Office.com, OneDrive placeholders and recommendations driven by Microsoft 365. Those networked queries and cloud enumerations can extend the first usable paint time if File Explorer tries to popula. In other words, two different factors combined to make a first open feel sluggish: the UI architectural overhead and the cloud‑backed content Home tries to show.
What Microsoft changed (the shorthand)
In the Windows Insider preview stream (builds in the 26220.xxx range), Microsoft began
experimenting with background preloading of File Explorer to reduce cold‑start latency. The change is explicitly experimental and appears as a checkbox in Folder Options labeled “Enable window preloading for faster launch times.” If the experiment is enabled on your device, Windows keeps a lightweight portion of Explorer warmed in memory so the first visible window paints and becomes interactive much faster. Microsoft also reorganized some context menu items in the same preview builds to reduce clutter, but the preloading toggle is the practical performance lever.
That solves the symptom (first‑open pause) by doing the work before you click — a pragmatic engineering trade‑off akin to Edge’s Startup Boost or Office prelaunch tasks. But it doesn’t change the root architectural costs; it simply moves initialization into idle time so perceived latency drops.
Overview: The two easy user fixes that actually make File Explorer feel fast
- Change File Explorer’s default start page from Home (Quick access) to **This Ploud queries and “recent files” enumeration that often causes the first paint to stall. Microsoft documents this setting in Folder Options and recommends Home for cloud‑first users, but many performance‑minded users prefer This PC for speed and predictability.
- If your PC receives Microsoft’s preloading experiment, enable it for instantaneous first opens; if you prefer not to have Explorer resident in memory you can uncheck the toggle. The best‑perceived experience combines both: preloading plus oat gives you the fast launch from preloading and avoids Home’s cloud-driven population cost.
Both changes are reversible and low risk for personal machines; they’re the fastest path to restoring a responsive Explorer.
The Home view: where the real bottleneck usually lives
What Home does and why it costs time
File Explorer’s Home view is designed as a productivity hub: it surfaces recent files, pinned items, and — increasingly — cloud‑driven recommendations and Office.com favorites. That’s useful if you live in Microsoft 365 and rely on cloud files, but it also means the Home view often triggers:
- Network calls to OneDrive or Microsoft 365 to enumerate recent/recommended items.
- checks for cloud placeholders.
- Extra UI elements that the WinUI renderer must initialize and paint.
- Thumbnail and preview handler invocations for recently used media.
If those calls are slow (on metered or intermittent networks), or if shell extensions and preview handlers are costly, the visible Explorer window can appear to hang while Home populates. Many hands‑on tests and community benchmarks show that opening Explorer to a local root (This PC) generally paints faster because it avoids these cloud and recent‑item workloads.
Real‑world symptom examples
- Opening Explorer after sign‑in shows a spinning “Working on it…” message while Home loads.
- Folders synced with OneDrive or SharePoint take longer to show content.
- The first right‑click or context menu can also be delayed if a pane or cloud provider triggers initialization.
These are not hypothetical: numerous community posts and mainstream outlets documented the difference between Home and This PC and recommended switching the default for immediate gains.
Step‑by‑step: Make File Explorer fast right now
- Open File Explorer (Win + E).
- Click the three‑dot menu (•••) on the toolbar and choose Options.
- In the General tab, find Open File Explorer to: and change it from Home to This PC.
- Click Apply, then OK.
That’s it — no registry tricks required. You’ll notice the difference immediately on most machines because Explonices every time it opens. For those who want to keep Home but avoid its cloud queries, you can also clear Quick access history and disable recent items in the Folder Options privacy section.
If your device is in the Insider preview that includes the preloading experiment, you’lggle here: File Explorer → View → Options → Folder Options → View tab →
Enable window preloading for faster launch times. If you like an instant open, leave it checked; if you want Explorer to behave only when you start it, uncheck it.
A deeper tweak: disabling Automatic Folder Type Discovery (registry tweak)
Power users and admins have long used a registry hack that forces Explorer to treat folders as generic (“NotSpecified”) instead of scanning folder contents to apply special templates (Pictures, Music, Videos, etc.). That “automatic folder type discovery” scan can cause slowdowns on directories with thousands of files; forcing a universal generic template often produces big improvements for heavy‑file folders.
- The tweak writes a FolderType = NotSpecified value under the Bags registry tree (HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\AllFolders\Shell). Many community guides document the exact path and process. It’s effective, reversible and targeted — but it removes automatic view selection, which some users appreciate.
Important cautions:
- Always back up the registry or create a restore point before applying this change.
- In managed (enterprise) devices the key may be reset by group policy or conflict with IT controls.
- The tweak addresses one class of lag (folder sniffing) but does not remove cloud‑query delays or WinUI composition costs.
If you want the fastest possible folder opens for heavy directories (Downloads, large media folders, project directories), this is a surgical fix — but it’s not necessary for the majority of users who will get most of the benefit from the This PC + preloading combo.
Why preloading helps — and what it doesn’t fix
Preloading reduces the
perceived cold start latency by doing initialization work dExplorer is warmed, the first visible paint is immediate and the window becomes interactive without the multi‑second pause many users reported.
What preloading helps:
- The initial click‑to‑interactive delay that annoyed users most.
- The impression of a slow OS when repeatedly opening Explorer from cold.
What preloading doesn’t fix:
- Runtime stutters when navigafolders (that’s often I/O or thumbnail work).
- Slow right‑click menus caused by dodgy shell extensions.
- Architectural overhead from mixing WinUI and Win32 — preloading masks the symptom but doesn’t remove the added composition cost.
Memory and power trade‑offs
Early reports and testing indicate the memory hit from the lightweight preloaded Explorer instance is modest on modern hardware, but it is a background resident process and therefore consumes RAM and — on laptops — some platform power. If you run very memory‑constrained systems or prefer minimal background processes, the toggle is visible and reversible. Microsoft intentionally exposed the user control to let people opt out.
Enterprise and admin considerations
- Staged experiment: Preloading arrived as an Insider experiment and may be staged server‑side. Enterprises relying on fixed user experience should be cautious until the change reaches General Availability and Microsoft provides management controls. Community notes expect eventual Group Policy or MDM options if Microsoft ships the dowsf
- Group Policy and device management: In managed fleets, IT may prefer to set defaults centrally (for example, forcing This PC as the default or disabling preloading) to ensure predictable performance and compliance. Test in a pilot cohort before wide deployment.
- Security and auditing: Because Explorer can invoke cloud providers and preview handlers, administrators should audit privacy and DLP implications when enabling cloud features or exposing AI Actions and similar integrations in Explorer. Microsoft’s UX changes also reorganize some cloud provider items into submenus, which can change discoverability for end users.
Critical analysis — strengths, risks and what Microsoft still owes users
Strengths of Microsoft’s approach
- Pragmatism: Preloading is a low‑risk, reversible mitigation that reduces the most visible pain point quickly.
- Control: Exposing a user toggle in Folder Options respects user choice for performance versus memory use.
- Incrementalism: Microsoft can collect telemetry and iterate, which is sensible given Explorer’s huge compatibility surface and thousands of shell extensions in the wild.
Risks and limitations
- Symptom patching, not refactoring: Preloading masks latency but leaves the WinUI/Win32 hybrid costs and cloud‑integrated surfaces intact. Long‑term performance and consistency require architectural investment. Analysis from independent engineering writers underscores that the WinUI composition model adds measurable rendering overhead.
- Resource trade‑offs: Keeping an Explorer skeleton resident increases memory footprint and may slightly affect boot behavior and battery life on portable devices. For many systems this is acceptable; for low‑RAM laptops it’s a meaningful trade‑off.
- Feature discoverability vs. performance: Microsoft’s Home view provides helpful cloud features for many users. Pushing users toward This PC to regain speed highlights a tension between default cloud‑first desformance. Microsoft has to choose between better defaults or more aggressive engineering work to make Home fast by default.
Where Microsoft should go next
- Publish a technical deep‑dive: explain exactly what components the preload warms and document memory budgets and telemetry results so admins can make informed choices.
- Provide enterprise management controls: expose Group Policy/MDM policies for toggling preloading and setting default Explorer start behavior at scale.
- Reduce WinUI overhead: longer term, invest in reducing the lifted‑compositor tax or provide a lean mode for Explorer that avoids heavy WinUI elements on low‑spec hardware. Independent analyses suggest this is the structural fix that will restore Windows 10–era responsiveness without background tricks. (techindeep.com)
How to measure if the changes help on your machine
- Baseline: close all Explorer windows and use a stopwatch (or a scripted timer) to measure time from Win + E to first interactive state (able to click inside the window). Repeat three times and average.
- Change default to This PC, clear Explorer history, and rerun the test.
- If your device has the preload toggle, turn it on and repeat the tests (note memory before/after in Task Manager).
- Use Resource Monitor or Performance Monitor to watch explorer.exe private working set and CPU during cold opens to quantify the memory and CPU trade‑offs.
Recommended metrics:
- Click‑to‑interactive time (user‑perceived latency).
- Explorer.exe private working set (MB).
- Boot time delta if you suspect preload increases startup costs.
These simple checks will give you objective evidence whether the UI tweak or preloading improved day‑to‑day responsiveness on your configuration.
Practical final recommendation
For most users who want a snappy, low‑risk improvement today:
- Set File Explorer to open to This PC (Folder Options → General → Open File Explorer to: This PC). This is the single best, zero‑risk step to remove cloud fetches from your first paint.
- If your system receives Microsoft’s preload experiment and you want instant opens, enable Enable window preloading for faster launch times in Folder Options → View. If you prefer no background resident, uncheck it.
- If you have heavy folders that remain sluggish, consider the FolderType = NotSpecified registry tweak after backing up and testing on one machine first. Use it as a last targeted optimization.
These steps provide an immediate, practical experience improvement without waiting for a major engineering refactor. They also keep your options open: you can always re‑enable Home or turn preloading off if your workflow or device profile changes.
Microsoft’s preload experiment is a useful stopgap and the Home → This PC flip is an under‑appreciated, reversible speed hack. Together they restore Explorer’s usability for most users — which is perhaps the best outcome we could ask for in the short term. But the underlying architectural costs remain, and a truly future‑proof solution will require Microsoft to reduce the WinUI/Win32 composition tax and make cloud integrations optional or non‑blocking by default. Until that work lands, turning a couple of switches will get your File Explorer back to feeling like a tool, not a bottleneck.
Source: MakeUseOf
Microsoft finally fixed File Explorer — but only if you disable this manually