When you right-click in File Explorer, the shell determines what you clicked, works out which handlers are registered for that class of thing, loads each one, and asks it what to contribute. This happens synchronously while you wait. Several distinct things can make it slow, and they are worth separating because they call for different responses.
Handler initialisation. A handler is code from an installed application, loaded into the Explorer process. If it does non-trivial work when initialising, the menu waits. The more handlers apply to what you clicked, the more this accumulates. This is the cause most commonly discussed and the one an inventory plus toggles can help you isolate.
Filesystem and network latency. A handler that inspects the selected item — reading a file header, checking a repository status, querying a sync service — is bound by how fast that inspection completes. On a local SSD this is invisible. On a network share, a mapped drive that has gone to sleep, or a cloud-synced folder with a placeholder file, the same handler behaves very differently. This is why a delay that appears only on certain paths is often not really about which handlers you have.
Selection size. Right-clicking one file and right-clicking four hundred are different operations. Handlers may examine each item.
Something outside the menu entirely. Explorer itself, a filesystem filter driver, or endpoint security software intercepting the operation can produce a pause that looks like a menu problem and is not.
The honest position is that ContextCleaner does not measure any of this. It contains no timing instrumentation and reports no durations, and any tool in this category claiming to identify "the slow handler" by measurement is worth a sceptical look at how. What ContextCleaner does provide is the two things elimination actually requires: a complete inventory — including handlers from 32-bit applications and packaged apps that a single registry sweep would miss — and changes cheap enough to iterate on, because each is one apply, one undo step on disk, and no Explorer restart. Bisecting twenty handlers takes about five rounds. That gets you to a specific suspect, which is a far better position than disabling everything and hoping.
One practical note: because handlers are labelled with the contexts they apply to, you can often skip most of the work. If the delay only occurs on folders, only handlers registered for directory classes are candidates.
