Shell Extension Speed Test Methodology (2026)

How we measure right-click delay — reproducible method over marketing claims

Everyone has an anecdote: “Google Drive ruins my context menu,” “NVIDIA adds a full second,” “WinRAR is fine.” Anecdotes are not enough when you are deciding what to disable. This page documents a repeatable way to measure how much a shell extension adds to Windows Explorer right-click latency, plus a sample results table with plausible millisecond ranges from a controlled reference setup.

Hardware, sync backlog, and background load change absolute numbers. Use the method to rank extensions on your PC. Use our table as a starting prior — not a warranty.

Related reading: Top 10 shell extensions that slow Windows 11 and the interactive overview at /tools/slowest-extensions.

What We Are Measuring

When you right-click, Explorer asks registered handlers to contribute menu items (and sometimes icons or status). For legacy IContextMenu extensions, that work often happens before the menu is painted. The visible symptom is dead time: cursor change, frozen Explorer, then the menu.

We care about added delay:

Extension cost ≈ time_with_extension − time_baseline

Baseline means the same folder, same user session state, with the candidate handler disabled (or the product uninstalled).

We record:

• Cold click — First right-click after reboot + idle settle (worst case; DLLs and helper services initializing)
• Warm click — Subsequent clicks on the same item after the handler is already loaded

Vendors love to quote warm numbers. Users feel cold numbers after every reboot and large update.

Reference Lab Conditions (Disclose Them)

Publish the environment with every table. Ours for the sample data below:

If you test inside a live OneDrive tree while 40,000 files are hashing, you are measuring sync pressure — not only the context menu DLL.

Tools

ShellExView (NirSoft)

Primary control surface. List context menu handlers, disable one product’s CLSIDs, restart Explorer, retest. Prefer disable over uninstall while iterating so you can revert quickly. Download notes: ShellExView.

Stopwatch method (good enough for ranking)

1. Reboot. Sign in. Wait 120 seconds.
2. Open the target folder. Do not right-click yet.
3. Start a stopwatch as you right-click; stop when the menu is fully painted and interactive.
4. Repeat 10 times for warm values (discard the first if you are isolating warm-only).
5. For cold values, reboot between trials or disable/enable the handler and restart Explorer with a fixed settle time — full cold isolation is tedious, so many labs do 3 cold trials and accept wider variance.

Phone stopwatches introduce ~50–100 ms human error. That is acceptable when comparing a 180 ms handler to a 1,200 ms handler. It is not acceptable for declaring a 20 ms “winner.”

Process Monitor (when the hang is mysterious)

Filter to explorer.exe, capture during one slow right-click, then look for long gaps before QueryContextMenu-era activity, network calls from sync clients, or repeated file opens. Procmon explains why a click stalled; it does not replace a disable/enable A/B for attribution.

High-resolution timing scripts and ETW exist for lab work. They are optional. Transparency beats theatrical precision.

Protocol (Step by Step)

1. Inventory — Note which products are installed. Disable unrelated third-party context menus so the candidate is not fighting five other stalls.
2. Baseline — Candidate disabled. Measure cold (if practical) and warm averages.
3. Enable candidate — Only that product’s handlers on. Reboot or restart Explorer with the same settle rules you used for baseline.
4. Measure — Same folder, same view mode (details vs icons), same file selection count (one file, not multi-select, unless that is the scenario).
5. Delta — Subtract baseline. Report cold and warm separately.
6. Sanity check — Disable again; confirm times return near baseline. If they do not, something else changed (update, sync storm, antivirus).
7. Document — App version, driver version for GPU menus, and whether the classic menu was forced system-wide.

Never compare a cold Google Drive click on Monday to a warm WinRAR click on Friday and call it science.

Sample Results Table (Plausible Lab Deltas)

Values below are approximate added milliseconds on the reference setup for the legacy / full menu path, warm vs cold. Your PC will differ. Cloud clients vary sharply with online state.

Caveats (read these before citing the table):

• Numbers are deltas, not absolute click times.
• Absolute click time also includes Explorer itself, Defender, and every other still-enabled handler.
• GPU and cloud figures move after driver or client updates.
• Measuring only the modern Windows 11 menu understates legacy-only handlers.

For narrative rankings and fixes, see Top 10 shell extensions that slow Windows 11. For a browsable impact view, use /tools/slowest-extensions.

How to Interpret Results Without Fooling Yourself

• Rank order is more stable than absolute ms. Google Drive beating WinRAR on cold start is a durable pattern; “exactly 1,237 ms” is not.
• Cold vs warm must stay labeled. Mixing them invents fake drama.
• One huge outlier (network timeout, dialog behind the window) should be discarded and noted — not averaged blindly.
• Disabling is the ground truth. If disable does not improve the click, the DLL was not your bottleneck.

What We Deliberately Do Not Claim

• That a single blog table replaces your own measurement
• That uninstalling everything “safe” is correct security advice
• That modern-menu-only apps are free (they can still cost time; the load path differs)
• That Process Monitor screenshots alone prove guilt without a disable test

Methodology first. Rankings second. Marketing last.

Minimal DIY Checklist

1. Pick one target folder; keep it constant.
2. Baseline with ShellExView disables.
3. Enable one product; reboot or controlled Explorer restart.
4. Record cold and warm averages.
5. Compute delta; sanity-disable.
6. Write down app versions.
7. Compare to the table above only as a relative hint.

If you publish your own results, include the protocol. Otherwise you are contributing noise.

Frequently Asked Questions

Q: Why do my right-click times differ from your table? A: CPU, storage, sync state, antivirus, and how many extensions are already loaded change the numbers. Treat published milliseconds as relative rankings on a reference PC, not a guarantee for every machine.

Q: Is a phone stopwatch accurate enough? A: For ranking major offenders, yes — if you average multiple trials and keep the target folder identical. For sub-50 ms differences, use higher-resolution timing or Process Monitor; stopwatch noise dominates tiny gaps.

Q: Should I measure the modern menu or Show more options? A: Measure both when possible. Many slow legacy handlers only run when the classic menu opens. If you restored the classic menu system-wide, every click includes that cost.

Q: Does Process Monitor replace ShellExView? A: No. ShellExView finds and disables handlers. Process Monitor shows file/registry I/O and timing clues while a hang happens. Use ShellExView for control of the experiment; use Procmon when you need evidence of what a DLL touched during the delay.

Q: Can vendors optimize and invalidate old numbers? A: Yes. Cloud clients and GPU drivers change often. Re-run the same protocol after major app updates instead of treating a 2026 table as permanent truth.

Q: Where can I see ranked slow extensions and interactive data? A: See the top 10 slow extensions guide and the slowest extensions tool for ranked results and browsing by impact. This methodology article explains how those kinds of numbers should be collected.