Microsoft’s latest Windows 11 Insider experiment preloads parts of File Explorer to shave milliseconds off the “cold‑start” delay, but early hands‑on testing shows the optimization delivers only a modest perceptual improvement while adding a measurable memory cost and leaving the deeper causes of Explorer sluggishness untouched.
Background / Overview
File Explorer is the most‑used graphical surface in Windows, and its responsiveness shapes routine productivity for millions of users. Over successive Windows 11 releases, users and reviewers have repeatedly flagged a first‑open pause, inconsistent context‑menu responsiveness, and sporadic in‑window stuttering that together make everyday file management feel slower than it used to. Microsoft has acknowledged these complaints and is experimenting with
warm‑start approaches instead of a sweeping shell rewrite.
The current experiment appears in Windows 11 Insider Preview Build 26220.7271 (KB5070307) and exposes a user‑visible toggle in Folder Options labeled
“Enable window preloading for faster launch times.” This is explicitly an exploration: enabled for some Insiders by default, reversible via the toggle, and subject to telemetry and feedback before any broader rollout.
What Microsoft shipped in the Insider build
The feature in plain terms
- The build: Windows 11 Insider Preview Build 26220.7271 (KB5070307).
- The toggle location: File Explorer → View → Options → Folder Options → View tab → Enable window preloading for faster launch times.
Microsoft’s choice is conservative: rather than rearchitecting Explorer’s complex, extensible shell, the company is testing a lightweight warmed state kept resident after sign‑in so the first visible paint of a new Explorer window can occur faster. The implementation is reported to be a partial, dormant runtime rather than a full persistent UI instance.
Companion UI changes
Alongside preloading, Microsoft tidied the right‑click context menu by grouping less‑used verbs into a
Manage file flyout and moving cloud provider actions into provider‑specific submenus. The goal is to reduce menu height, lower per‑click dynamic queries, and improve scannability. These UI edits are intended to complement the preload by reducing other perceptible delays in common interactions.
Early hands‑on measurements: what the tests show
Independent reviewers and community testers ran side‑by‑side comparisons with the preload toggle on and off. The most widely circulated measurements come from hands‑on tests that consistently found three repeatable effects:
- Faster time‑to‑first‑paint for the initial Explorer window — a perceptual improvement that is most visible in slow‑motion video comparisons and on slower storage/hardware.
- A measurable increase in idle resident memory when the warmed instance is kept resident — commonly reported in the high tens of megabytes (roughly +30–35 MB in multiple tests).
- No material improvement to deeper runtime latencies — folder enumeration, context‑menu population (especially when third‑party shell extensions or cloud providers are involved), and preview/thumbnail handler stalls remain unaffected.
The clearest single data point repeated across testers measured Explorer’s idle resident memory at roughly
32.4 MB with preload disabled and about
67.4 MB with preload enabled — an extra ~
35 MB. That delta has been reproduced by multiple outlets and community posts under similar test conditions.
Why the improvement feels limited: technical analysis
Hybrid architecture and layered costs
The root cause of persistent Explorer sluggishness is architectural: Windows 11’s File Explorer is a hybrid of legacy Win32/COM shell components and modern WinUI/XAML elements from the Windows App SDK. That layering increases rendering and composition work compared with the leaner Win32‑centric path Windows 10 used for many Explorer surfaces. Preloading can hide initialization costs for the first paint, but it does not remove the extra composition and on‑demand work that occurs later.
What preloading likely warms
Based on Microsoft’s public description and precedent (Edge’s Startup Boost, Office prelaunch tasks), preloading likely does the following:
- Instantiate a UI skeleton (address bar, command bar, basic control wiring) and keep it dormant or suspended.
- Prime small caches used for the initial paint (icon caches, frequently used navigation state).
- Possibly register or lightly prime a limited set of preview/thumbnail handlers to avoid first‑use stalls for the most common types.
Even so, most costly operations — network enumeration for remote shares, OneDrive placeholder resolution, on‑demand preview handlers that do heavy I/O, and third‑party shell extension code run on interactions — occur later and therefore remain slow. Preloading changes
when some initialization happens, not
how much total work the shell must eventually do.
Cross‑checks and reproducibility
Multiple independent outlets and community threads converge on the same picture: the preload reduces first‑open latency perceptibly in controlled tests, usually costs roughly tens of megabytes of resident RAM, and does not cure context‑menu or enumeration lag. This consensus appears across reviews and community reproductions, increasing confidence that the hands‑on results are not an isolated measurement artifact.
Two important caveats remain:
- The measured memory delta is device dependent. Installed shell extensions, provider overlays (OneDrive or third‑party cloud clients), and the composition of cached resources will push the number up or down. Treat the ~35 MB figure as indicative, not absolute.
- Microsoft has not published low‑level implementation details or a formal memory budget for the preload mechanism, so internal heuristics and gating logic (for example, skipping preload on battery saver or low‑RAM devices) remain unverified until Microsoft documents them or releases telemetry summaries. Flag those elements as unverifiable claims for now.
Practical implications: who benefits and who should be cautious
Likely winners
- Users on HDDs or older, disk‑bound machines where cold‑start costs are dominated by storage latency will see the largest practical gains.
- Desktop users with abundant RAM who value immediate feel over a small background footprint are likely to prefer leaving preload enabled.
Use cases to approach cautiously
- Low‑RAM laptops (4–8 GB): A persistent warmed instance could push memory pressure into paging and slow overall responsiveness more than it helps Explorer launches. Administrators should pilot before enabling preload widely in such environments.
- VDI / multi‑user session hosts: The per‑session memory increase is multiplicative across sessions and could reduce density or require image adjustments. Enterprises running pooled desktops should test preload on representative images and await explicit management controls.
- Battery‑sensitive devices: If heuristics don’t respect battery‑saver modes, preloading could shift work to idle time and impact battery life. Tests so far have not flagged catastrophic battery drain, but it’s a plausible risk that needs validation on mobile hardware.
Enterprise and OEM considerations
Enterprises will reasonably expect:
- Group Policy or Intune controls to manage the feature centrally before enabling it across fleets. Early Insider builds expose only the per‑device Folder Options toggle; policy controls are not yet visible.
- A published, conservative resource budget (per‑session memory, CPU windows at sign‑in, battery gating) to model VDI density and power profiles. That budget is currently absent from Microsoft’s public notes.
- Compatibility test matrices that include backup agents, AV/EDR, shell‑extension‑delivering apps, and cloud providers — because preloading may initialize some third‑party components earlier and surface latent stability or telemetry interactions.
From an OEM perspective, perceived OS responsiveness influences upgrade messaging and customer satisfaction. Some OEMs have cited Windows 11 adoption headwinds tied to performance perceptions; pragmatic, telemetry‑backed fixes that can be rolled into OEM images with clear knobs will be favored.
Recommendations: what everyday users, power users, and admins should do now
Everyday users (concise)
- If you notice Explorer’s first‑open delay and have 8 GB+ RAM, leave the toggle enabled and decide by feel. The memory cost is modest for most modern desktops.
- If you run on a constrained laptop (4–8 GB) or notice overall slowdown after enabling preload, disable it in Folder Options and report findings through Feedback Hub.
Power users and enthusiasts
- Reproduce the test on your hardware: measure idle Explorer memory with preload off and on, capture a timed cold‑open sequence, and record behavior under typical load.
- Inspect installed third‑party shell extensions and cloud providers. If context‑menu lag persists, those components are likely the main cause, not the lack of preloading.
IT administrators (practical rollout checklist)
- Pilot preload in a controlled test pool that mirrors your fleet (device types, VDI images, managed laptops).
- Measure per‑session resident memory, sign‑in CPU spikes, and battery behavior on representative mobile hardware.
- Hold off broad rollout for VDI images until Microsoft documents management controls or publishes a formal policy option.
- Coordinate with third‑party vendors that provide shell extensions, preview handlers, and cloud sync clients to validate compatibility with a warmed Explorer state.
Strengths, risks, and what still needs verification
Notable strengths
- The preload is a low‑risk, incremental optimization that can deliver a visible UX improvement without deep architectural changes. It follows a proven pattern Microsoft used for Edge Startup Boost and Office prelaunch, which have historically been well received for perceptual speedups.
- The feature is opt‑out and telemetry‑driven, enabling Microsoft to tune heuristics before broader rollout. That conservative rollout philosophy reduces the chance of widespread regressions.
Potential risks
- Memory and density impact: The per‑instance memory increase is small on a single device but scales across VDI sessions and constrained laptops. Early reports show ~30–35 MB more resident memory in typical test setups, but this is device dependent.
- Battery and scheduling: If Microsoft’s heuristics don’t gate preload on battery saver or other low‑power modes, mobile devices could see reduced battery life. This remains an area that needs explicit validation.
- Third‑party extension exposure: Preloading may cause some third‑party shell extensions or cloud provider code to initialize earlier, potentially surfacing stability issues that were previously latent. Enterprises should validate compatibility thoroughly.
Unverified or unverifiable claims (flagged)
- Microsoft’s internal heuristics for when to skip preload (for example, exact RAM thresholds, battery gating, or session host optimizations) have not been published; assertions about those policies are presently unverifiable. Administrators should treat telemetry from Insider runs as provisional until Microsoft documents official controls.
- The long‑term plan for migrating Explorer’s internals to WinUI 3 or other frameworks — and whether preloading is a stopgap vs. a step toward a deeper refactor — remains a product roadmap question Microsoft has not publicly committed to in detail. Readers should not conflate the current experiment with a confirmed architectural path.
Final verdict: pragmatic, visible, but narrow
Preloading File Explorer is a pragmatic, targeted attempt to improve how Windows 11
feels without destabilizing a compatibility‑sensitive shell. For many users — especially those on slower storage or with comfortable memory budgets — the tweak will make first opens feel snappier and reduce the annoyance of a perceptible cold‑start pause. The implementation’s conservative, reversible nature is the right approach for a component used so widely.
However, the feature is a
band‑aid rather than a cure: it masks initialization costs for the initial paint but does not address the structural sources of Explorer sluggishness such as enumeration performance, context‑menu extension behavior, and preview/thumbnail handler cost. The measurable memory cost (~30–35 MB in common tests) is small but relevant for VDI, low‑RAM devices, and enterprise imagery planning.
Closing recommendations
- Trial the feature on representative hardware and workflows before enabling it broadly. Measure idle Explorer memory, first‑open timings, and battery behavior under realistic conditions.
- For enterprise and VDI environments, wait for explicit management controls (Group Policy / Intune options) and a published resource budget before a fleet‑wide rollout.
- If context‑menu lag or slow enumeration remains a problem, diagnose installed shell extensions and provider integrations — preloading is unlikely to help these cases.
The preload experiment shows Microsoft is responsive to user feedback about Explorer responsiveness and is choosing a measured path to improve the daily experience. The approach is technically sensible and likely to become a welcome quality‑of‑life improvement for many users — provided Microsoft pairs it with sensible heuristics, clear management controls, and continued work on the deeper performance problems that preloading alone cannot fix.
Source: Пепелац Ньюс
https://pepelac.news/en/ampposts/id13687-early-tests-windows-11-file-explorer-preloading-flops/