CLAUDE.md's Performance section tells the anecdote:
A profiled "the 3D highway is laggy" report turned out to be three plugins doing per-frame querySelectorAll … The GPU was idle.
and generalizes:
Profile the main thread, not the GPU, when a renderer "feels laggy" — the offender is usually an unrelated plugin's per-frame DOM work.
The anecdote is a valid, useful example, but "usually" states a probability/base-rate claim backed by a single incident. The actually-defensible and equally useful rule is procedural, not statistical: profile the main thread before concluding anything about the renderer, because any plugin's DOM work shares that thread and is cheap to rule in/out — regardless of how often it turns out to be the actual cause.
Suggest rewording to drop the "usually" framing (which nothing here establishes) in favor of the procedural instruction, e.g.: "Profile the main thread first, before blaming the renderer — plugin DOM work is cheap to rule out and has been the real cause before (see [incident])."
CLAUDE.md's Performance section tells the anecdote:
and generalizes:
The anecdote is a valid, useful example, but "usually" states a probability/base-rate claim backed by a single incident. The actually-defensible and equally useful rule is procedural, not statistical: profile the main thread before concluding anything about the renderer, because any plugin's DOM work shares that thread and is cheap to rule in/out — regardless of how often it turns out to be the actual cause.
Suggest rewording to drop the "usually" framing (which nothing here establishes) in favor of the procedural instruction, e.g.: "Profile the main thread first, before blaming the renderer — plugin DOM work is cheap to rule out and has been the real cause before (see [incident])."