Windows 11 Insider Preview 26220 Adds Explorer Preload and Cleaner Context Menu

  • Thread Author
Microsoft has pushed the first public preview build of Windows 11 for 2026 into the Insider channels, and at its centre is a focused set of fixes and experiments for File Explorer — including an optional background preload and a reorganized right‑click menu — alongside a handful of other quality and usability tweaks that signal Microsoft is reprioritizing everyday performance and polish.

A modern File Explorer interface with Quick access, folders, and a context menu.Background​

Windows’ File Explorer is one of the operating system’s most visible and frequently used surfaces. Over multiple Windows 11 development cycles it accumulated new capabilities (tabs, richer cloud integration, WinUI styling) while inheriting new pain points: a persistent “cold‑start” pause when opening Explorer, a tall and cluttered context menu, and occasional responsiveness regressions that affected daily productivity. Microsoft’s engineering response in the current Insider preview is deliberately incremental — move work out of the click path, tighten the menu surface, and gather telemetry before any broad consumer rollout. This preview flight is distributed as Windows 11 Insider Preview Build 26220.7271 (KB5070307) to Dev and Beta channel Insiders. Microsoft labels the Explorer changes as explorations, meaning they’re experimental and subject to change based on telemetry and Feedback Hub input. That staged, opt‑in evaluation pattern is consistent with how Microsoft has handled subtle UX and performance modernizations in recent years.

What arrived in the preview: headline changes​

File Explorer preloading (experimental)​

  • An optional setting called Enable window preloading for faster launch times appears in File Explorer → View → Options → Folder Options → View.
  • When enabled, Windows keeps a lightweight portion of Explorer warmed in the background (during idle time) so the first visible window paints and becomes interactive faster. The feature is enabled by default for Insiders who receive the experiment, but it can be toggled off.

Context‑menu reorganization​

  • Several less‑frequent commands (for example, Compress to ZIP, Copy as path, Set as desktop background, Rotate left/right) are grouped into a new Manage file flyout to shorten the top‑level menu.
  • Cloud provider sync options (OneDrive and third‑party providers) are moved into provider‑specific submenus; device/cloud actions like Send to My Phone are repositioned for logical grouping.
  • Microsoft treats the wording and grouping as provisional and may rename the flyout or shuffle items during testing.

Other items in the same preview​

  • The build bundles several unrelated previews and quality improvements, including an Xbox Full Screen Experience on more PC form factors, the ability to uninstall Store‑managed apps from the Library page, and platform or reliability fixes across the shell. Those items are part of the broader KB5070307 flight and are being evaluated in parallel with the Explorer experiments.

Why these changes matter​

File Explorer is opened dozens of times a day by many users; even a half‑second per open adds up into tangible time loss and a perception of slowness. Microsoft’s engineering insight here is straightforward and pragmatic: improve perceived responsiveness by warming only the parts of Explorer necessary for the initial UI paint rather than attempting an immediate, risky rearchitecture of enumeration, thumbnailing or preview handlers. That pattern mirrors previous approaches such as Edge’s Startup Boost and Office’s scheduled prelaunch experiments.
Decluttering the context menu addresses a separate but equally common complaint: as cloud features and third‑party shell extensions piled into Explorer, the vertical menu grew long and hard to scan. Grouping infrequent items reduces pointer travel and makes the top level easier to use on laptops and tablets where a long menu can occupy most of a screen. Both changes target very high‑frequency interactions and therefore have outsized effect when they work well.

Technical sketch: what preloading likely does (and does not)​

Microsoft’s public notes are intentionally high level. Hands‑on reporting and community testing point to the following likely scope for the background preload:
  • What it likely warms:
  • The UI skeleton (address bar, command bar, toolbar controls) and common controls so the first paint completes quickly.
  • Small caches and shell wiring commonly needed for the initial view.
  • Registration of a small, controlled subset of preview/thumbnail handlers to avoid UI thread stalls on first open.
  • What it does NOT aim to change:
  • It’s not a rewrite of the enumeration engine: scanning network shares and deep folder trees, resolving OneDrive placeholder metadata, or expensive thumbnail generation are still done on demand.
  • It doesn’t alter third‑party shell extension APIs; poorly implemented handlers can still delay certain operations until they’re loaded.
This constrained warming approach shifts timing rather than semantics: the system does the same work, but some initialization happens while the PC is idle so the click‑to‑interactive interval feels shorter.

Trade‑offs and real‑world impacts​

Memory and battery​

Preloading increases resident memory usage by keeping Explorer components resident. Early tests and independent reporting show measurable memory increases on low‑RAM systems; one hands‑on analysis reported Explorer’s working set roughly doubling under the experiment on constrained devices, with only modest improvement in perceived speed in some scenarios. That means small or HDD‑backed PCs may see limited net gain and a non‑trivial memory cost. Administrators should weigh this trade‑off for managed fleets and low‑end hardware.

Boot time and idle behaviour​

Because preloading occurs during idle time, machines that regularly suspend or have short idle windows may not benefit as much. There’s also a theoretical risk that aggressive preloading could extend boot‑time I/O or slightly alter battery drain during the first session; Microsoft’s staged rollout and the toggle are designed to catch and mitigate such regressions before a broad consumer push.

Third‑party shell extensions​

A persistent complicating factor for Explorer performance is synchronous third‑party shell extensions that execute on the UI thread. Preloading can hide some of that latency for the first open, but it doesn’t eliminate the fundamental issue: badly implemented extensions will still block certain operations or cause instability. Power users and enterprises should continue to audit shell extensions if they see hangs or crashes.

Discoverability and muscle memory​

Power users who relied on top‑level advanced commands will need to adjust to the new groupings. While grouping improves scanability for most people, it adds a click for users who frequently used those commands — a short–term productivity cost that Microsoft appears willing to accept for net long‑term benefit. The company’s willingness to iterate wording and arrangement during Insider testing should help reduce friction.

How to enable, disable, and test the feature​

  • Open File Explorer.
  • Select the View menu → Options → Folder Options → View tab.
  • Locate Enable window preloading for faster launch times and check or uncheck the box to enable or disable the experiment.
  • If you see unexpected behavior after enabling, toggle the setting off, restart Explorer (or sign out/sign in), and report the issue using Feedback Hub under Files, Folders and Online Storage → File Explorer Performance.
For administrators:
  • Pilot the change in a representative ring that includes low‑RAM devices and machines with common third‑party shell extensions.
  • Verify boot, sign‑in, and battery metrics on test devices.
  • If the preload causes unintended side effects, use the toggle to opt test devices out while providing precise telemetry and repro steps to Microsoft via Feedback Hub.

Deeper look at the context‑menu reorganization​

The context menu rework focuses on reducing vertical clutter and improving scanability:
  • Top level retains core verbs (Open, Cut/Copy, Rename, Delete) and common actions.
  • Manage file flyout nests:
  • Compress to ZIP
  • Copy as path
  • Set as desktop background
  • Rotate left/right
  • Cloud provider submenus contain provider‑specific sync actions such as Always keep on this device and Free up space, making provider actions discoverable under their related headings rather than interleaved at the top level.
This grouping improves pointer ergonomics on smaller screens and reduces the visual weight of the top‑level menu. However, it increases the depth for advanced actions and could confuse users who expect those verbs to appear immediately. The experimental label and opt‑in distribution give Microsoft room to refine names and placements.

Other notable items in the build — quick summary​

  • Xbox Full Screen Experience: Microsoft continues expanding a console‑like FSE for certain PC form factors, improving controller and UI behaviour for gaming sessions.
  • Store Library uninstall: testers saw the ability to uninstall Store‑managed apps directly from the Library page — a small but useful management improvement for app lifecycle control.
  • Quality and reliability fixes: the flight includes numerous bug fixes across thumbnailing, dark‑mode rendering, and shell stability from previous preview cycles; these incremental fixes are the practical foundation that makes UI experiments safe to test.

Cross‑verification and fact‑checking​

Key technical claims and changelog items have been corroborated across multiple independent outlets and community mirrors:
  • The build number and KB (Build 26220.7271 / KB5070307) and the Dev/Beta distribution are consistently reported across coverage and community posts.
  • The Folder Options toggle text Enable window preloading for faster launch times and the presence of a Manage file flyout are reproduced in hands‑on previews and forum posts.
  • Early, device‑level testing that measures memory impact and limited speed gains on constrained hardware has been published by independent sites; those reports highlight the trade‑offs and encourage measured testing before any enterprise deployment.
Where reporting diverges — for example, precise memory numbers or battery impact on a given configuration — those are environment‑dependent and should be treated as provisional. Independent measurements vary by hardware, installed shell extensions, and the device’s power/profile settings; corroborate with local tests for your fleet.

Critical analysis — strengths, risks, and what to watch​

Strengths​

  • Pragmatic engineering: Microsoft targets high‑frequency pain points with low‑risk timing changes. Preloading the UI skeleton is a focused optimization that can yield perceptible gains without deep compatibility work.
  • User control and staged testing: The visible toggle and Insiders‑first rollout give users and admins agency to opt out while Microsoft collects telemetry. That reduces risk for managed deployments.
  • Improved scanability: A shorter top‑level context menu will make everyday file operations faster for most users, especially on compact screens.

Risks and limitations​

  • RAM and battery trade‑offs: On low‑RAM systems the preload increases memory pressure and may deliver diminishing returns. Early reports show only modest speedups in some scenarios while doubling Explorer’s working set on constrained devices. That memory pressure can exacerbate paging and reduce overall responsiveness on old hardware.
  • Third‑party compatibility: The change doesn’t eliminate synchronous shell extension hazards; badly written extensions remain a source of hangs and regressions. Enterprises should continue to monitor and catalogue shell extensions in use.
  • Hidden complexity for power users: Grouping advanced verbs one click deeper imposes a short‑term cost on workflows that relied on single‑click access to those actions. Microsoft will need to balance discoverability and efficiency as the experiment evolves.

What to watch next​

  • Does Microsoft widen the experiment to more Insiders or to a limited public rollout in early 2026? Early reporting suggests an early‑2026 staged rollout is plausible but not guaranteed; treat any date expectations as provisional until Microsoft publishes formal guidance.
  • Will telemetry show consistent gains across hardware classes, or will benefits concentrate only on mid‑range and higher systems?
  • Will Microsoft add fine‑grained controls (for example, only preload on AC power or only on devices with ≥X GB RAM) to avoid penalizing constrained devices?

Practical recommendations​

  • Insiders and enthusiasts: install the preview to test on personal hardware, toggle the preload on and off, and measure perceived responsiveness versus memory use. Submit Feedback Hub reports with repro steps if you encounter regressions.
  • Power users: try the new context menu layout in a lab environment first. Map the frequently used commands and consider keyboard shortcuts or Quick Access items if the extra click slows your workflow.
  • IT administrators: pilot the build in a representative ring that includes devices with low RAM, HDD storage, and common third‑party shell integrations. Confirm that the preload behavior doesn’t conflict with boot, sign‑in, or power policies before broad deployment.

Conclusion​

This first Windows 11 preview build of 2026 places a pragmatic bet: small, reversible changes that shave friction from daily workflows will matter more to most users than sweeping architectural rewrites. The optional File Explorer preload is a low‑risk experiment to make the shell feel faster by shifting initialization into idle time, and the reorganized context menu trims everyday visual clutter. Both moves reflect a sensible, telemetry‑driven approach — but they carry trade‑offs that matter in constrained environments, especially around memory use and third‑party behavior.
For now the changes live behind an Insider gate and an opt‑out toggle so Microsoft can validate benefits and surface any regressions before a wider rollout. Organizations and enthusiasts should test carefully, report findings, and weigh the benefits against the resource cost on their hardware. If the telemetry is positive and Microsoft tunes the features responsibly, millions of day‑to‑day Explorer interactions could become noticeably smoother — but until then, the preview is best treated as an invitation to evaluate, measure, and feed disciplined feedback into the process.
Source: Neowin https://www.neowin.net/news/first-p...is-out-with-fixes-for-file-explorer-and-more/
 

Microsoft has pushed the first public preview builds for Windows 11’s early 2026 development to Insiders, and the headlines are practical: targeted File Explorer fixes — including an optional background preloading toggle and a reworked right‑click menu — accompanied by additional shell and platform quality improvements designed to quiet high‑frequency user pain points.

Dark-mode Windows File Explorer on a laptop showing Documents and Pictures with a right-click menu.Background / Overview​

File Explorer remains one of the most visible and repeatedly used surfaces in Windows, and performance or usability regressions there are felt immediately by the largest number of users. Microsoft’s recent Insider flights move away from sweeping re‑architectures and instead are testing small, reversible experiments aimed at improving perceived responsiveness and usability while collecting telemetry before any broad consumer rollout.
Two related engineering threads explain Microsoft’s approach: first, reduce the perceived latency by doing predictable initialization during idle time rather than attempting expensive on‑demand work; second, surface the right controls that most users need and tuck away rarer operations to reduce menu clutter. These principles underlie the explorer experiments introduced in the current preview builds.

What landed in the preview builds: an at‑a‑glance summary​

  • Windows 11 Insider Preview Build 26220.7271 (KB5070307) — an early preview in the Dev and Beta channels — introduced:
  • An experimental optional setting called “Enable window preloading for faster launch times” in File Explorer’s Folder Options. When present, Windows warms a minimal part of Explorer in the background so the first visible window paints and becomes interactive faster.
  • A reorganized right‑click context menu that groups less‑used actions (Compress to ZIP, Copy as path, Set as desktop background, Rotate) into a new Manage file flyout and places cloud provider options into provider‑specific submenus to reduce vertical clutter.
  • A handful of other staged previews — Xbox Full Screen Experience on more PC form factors, the ability to uninstall Store‑managed apps from the Library page, and small accessibility and dictation experiments — shipped alongside the File Explorer work.
  • Windows 11 Insider Preview Build 26220.7523 (KB5072043) — a follow‑up flight in the same branch — focused on stability and fixes:
  • Addressed the widely reported File Explorer white flash in dark mode that occurred when navigating between pages, along with search reliability and indexing improvements.
  • Fixed a set of peripheral but impactful issues such as OneDrive/RemoteApp file‑opening errors and Voice Access improvements for Gallery view.
These changes are being evaluated in the Dev and Beta channels via controlled rollouts and feature‑gating, meaning not every Insider on the same build will see the same enabled experiences at the same time.

Deep dive: File Explorer preloading — what it is and what it is not​

The user problem: cold start and perceived sluggishness​

Many Windows users still experience a perceptible pause the first time File Explorer is opened after sign‑in, especially on lower‑powered devices, HDD systems, or machines with heavy shell extensions and cloud overlays. That pause is a perception of slowness even when subsequent navigation is fine, and it’s amplified by the frequency with which users open Explorer. Microsoft’s experiments target that initial impression.

What the preview feature does (practical description)​

The preview exposes an optional toggle labelled Enable window preloading for faster launch times in File Explorer → View → Options → Folder Options → View. When enabled on devices that receive the experiment, Windows keeps a lightweight part of Explorer warmed during idle time so that when you open a window the user interface paints and becomes interactive noticeably faster. The toggle is user‑controllable and, for Insiders receiving the experiment, reported to be enabled by default.

What the preview feature does not do (important limits)​

  • It is not a wholesale rewrite of Explorer’s enumeration, preview handler loading, thumbnailing, or cloud enumeration subsystems. The preloading approach focuses on time‑to‑first‑paint rather than making expensive file‑system operations themselves finish faster.
  • It won’t magically fix slow folder listings caused by network shares, overloaded preview handlers, or poorly written third‑party shell extensions. Those issues require targeted fixes in the respective subsystems.

Why Microsoft chose preloading​

Preloading is a pragmatic, low‑risk strategy that Microsoft has used elsewhere (Edge’s Startup Boost, Office’s prelaunch tasks): perform predictable initialization during idle time so the interactive path appears faster when the user asks for it. This trades modest background resource usage for lower perceptual latency on first open. Microsoft collects telemetry from Insiders to validate the trade‑off before any broader rollout.

Unverifiable / opaque areas​

Microsoft’s public notes intentionally omit low‑level implementation details: the exact memory footprint, CPU/battery tradeoffs on ultra‑constrained hardware, and which Explorer subsystems are warmed are not disclosed. Those are measurable — and important — variables that Insiders and enterprise pilots will need to verify in real hardware. Treat the implementation scope as partially unverifiable until Microsoft publishes deeper engineering notes or telemetry summaries.

Deep dive: context‑menu reorganization — still everything you need, just one click deeper​

The problem: an increasingly tall, cluttered menu​

Over years of Windows evolution, the right‑click menu has accumulated legacy verbs, third‑party shell extension entries, cloud‑provider sync actions, and new OS features, producing a very tall menu that’s hard to scan—especially on small screens or when using touch. Microsoft’s change targets this usability pain.

What changed in the preview​

  • A new Manage file flyout consolidates less‑frequent actions such as:
  • Compress to ZIP (and related archive options)
  • Copy as path
  • Set as desktop background
  • Rotate right / Rotate left
  • Cloud provider sync options (OneDrive and third‑party providers) are moved into provider‑specific submenus, and device/cloud actions like Send to My Phone are repositioned for logical grouping.
  • Frequently used verbs such as Open, Open with, and Open folder location are promoted together to reduce pointer travel for common workflows.

Usability trade‑offs​

  • For casual users and most workflows, the top‑level menu will be cleaner and faster to scan.
  • Power users and scriptable workflows that relied on muscle memory for top‑level advanced commands may need a short adjustment period. The relocated functions remain accessible one click deeper; nothing is removed.

Accessibility & keyboard navigation concerns​

Nested flyouts introduce potential accessibility regressions (focus order, screen‑reader labels, discoverability). Microsoft explicitly notes the Manage file label may change and solicits Feedback Hub reports, signaling awareness that keyboard and assistive technology behavior must be verified across the change. Enterprises with assistive‑technology needs should validate the new layout in pilot rings.

What the December follow‑up build fixed (26220.7523 / KB5072043)​

After the initial experiments, Microsoft rolled a stability‑focused update that addressed glaring regressions introduced earlier in preview flights:
  • Fixed the white flash that some Insiders saw when navigating Explorer under dark mode, a regression that was visually jarring and widely reported.
  • Improved File Explorer search performance and indexing by eliminating duplicate indexing operations and enhancing handling of system and secondary drive locations, which should produce faster, more reliable searches and reduce extraneous resource use.
  • Fixed OneDrive/RemoteApp file opening error scenarios and improved Voice Access in Gallery view.
These fixes show Microsoft balancing experiments with reactive quality work: when an experiment causes a noticeable regression, the engineering teams prioritize fast remediation in subsequent flights.

Broader context: why this matters for different user groups​

Home users and enthusiasts​

  • Immediate benefit: cleaner menus and snappier perceived Explorer launches on constrained devices. The optional toggle means you can try preloading and turn it off if you prefer legacy behavior.
  • Try it in the Dev/Beta channel only on non‑critical machines. If you rely on specialized third‑party shell extensions, expect to test those integrations.

Power users and IT pros​

  • Power users who extend Explorer with many third‑party shell extensions should pilot the change: preloading shifts initialization timing and may expose latent bugs in poorly maintained extensions.
  • Enterprise admins should run a short compatibility sweep in a pilot ring. The team delivering these previews explicitly frames the changes as telemetry‑driven experiments; plan to use the Folder Options toggle as a remediation if you see higher‑than‑acceptable resource consumption or compatibility regressions.

Accessibility and assistive tech communities​

  • Nested flyouts require careful keyboard and screen‑reader verification. Microsoft’s preview notes and early community testing emphasize this risk; organizations supporting accessibility should validate workflows (keyboard navigation, Narrator/JAWS/VoiceOver interactions) before broad deployment.

OEMs and device makers​

  • OEMs shipping low‑spec handhelds and tablets will be particularly interested in preloading telemetry: the balance between background memory reservations and improved perceived launch time is a hardware‑dependent trade‑off that must be validated on representative kits.

Practical guidance: test plan and rollout checklist​

  • Establish a pilot ring with representative hardware (SSD vs. HDD, high vs. low RAM, devices with common third‑party shell extensions).
  • Enable the Insider preview flight (Dev/Beta) and confirm whether the preloading experiment is present on test machines.
  • Measure:
  • Time‑to‑first‑paint of File Explorer (cold starts).
  • Memory and CPU usage with preloading enabled vs. disabled during idle.
  • Battery drain on mobile/handheld devices over a representative session.
  • Validate functional behavior:
  • Verify top‑level and Manage file flyout commands.
  • Run automated accessibility checks and manual keyboard/screen‑reader tests.
  • Stress test with commonly deployed shell extensions and cloud overlay providers.
  • If regressions are unacceptable, disable preloading via Folder Options → View → “Enable window preloading for faster launch times” and report telemetry via Feedback Hub.

Strengths of Microsoft’s approach​

  • Practical, incremental improvement: By focusing on perceived latency and menu clutter, Microsoft can deliver visible usability gains with low disruption. The opt‑out toggle shows respect for varying preferences and environments.
  • Telemetry‑driven staging: Rolling experiments through Insiders and server‑gated feature flags reduces the blast radius for regressions and allows iterative tuning.
  • Rapid remediation cycle: The December follow‑up build that removed the white‑flash regression demonstrates a commitment to quickly fix high‑impact issues surfaced by testers.

Risks and open questions​

  • Memory and battery trade‑offs: Preloading reserves resources even when Explorer isn’t actively used; the exact footprint and battery impact on ultra‑low‑power devices is not published and must be measured. This is the primary risk to device OEMs and laptop/tablet users. Flagged as a verification item.
  • Third‑party compatibility: Shifting initialization timing can expose latent bugs in shell extensions and overlays. Enterprises with heavy customizations must validate integrations.
  • Accessibility regressions: Nested flyouts need robust focus and labeling to preserve keyboard and screen‑reader usability; early testing should prioritize these scenarios.
  • Feature fragmentation and confusion: Staggered rollouts and differing channel behavior can create confusion about who has an experience and why. Clear internal communication and update guidance are necessary for managed fleets.
  • Unverified implementation details: Microsoft’s public notes omit low‑level data; until engineering publishes resource‑use figures, assumptions about efficiency remain provisional. Treat such claims cautiously.

How this fits into Microsoft’s broader Windows strategy​

The Explorer experiments align with a larger trend in Microsoft’s product approach: prioritize the user experience by reducing perceived latency, gate new experiences behind experiments and hardware entitlements, and iterate rapidly based on Insider telemetry. The same pattern has appeared in Edge (Startup Boost), Office (scheduled prelaunch), and other shell work. These are small, cumulative changes that restore polish to high‑frequency surfaces without destabilizing the broader platform.

Final assessment — what to expect next​

  • For Insiders: try the feature on test hardware, report regressions via Feedback Hub, and watch for subsequent builds refining the experience.
  • For IT teams: run quick compatibility pilots and prepare a short guidance note (how to toggle preloading, what to test) for end users.
  • For general users: expect a staged rollout if Insider telemetry is positive. The changes are designed to be reversible and low‑impact for the majority of configurations.
Microsoft’s current preview work on File Explorer is not a headline‑grabbing redesign; it’s the kind of iterative polish that improves millions of daily interactions. The experiment is well‑scoped and user‑controllable, but its success will hinge on measured telemetry across diverse hardware, careful handling of accessibility, and continued attention to third‑party compatibility. If those tests go well, the result should be a noticeably snappier, less cluttered File Explorer in mainstream Windows 11 releases — a quiet but meaningful win for everyday productivity.
Note: The reported build numbers and changelogs cited in this article are taken from the Windows Insider announcements and independent reporting on the Dev/Beta Insider flights; Microsoft’s public notes describe behavior at a high level and intentionally omit low‑level implementation specifics, which is why resource‑use and exact warming mechanics are flagged as items requiring direct measurement in any deployment.
Source: Neowin https://www.neowin.net/amp/first-pr...is-out-with-fixes-for-file-explorer-and-more/
 

Back
Top