Separate Slow Work From Retained Work
Main-thread blocking and memory growth have different causes: expensive synchronous work delays interaction, while retained objects, listeners, timers, subscriptions, or caches can accumulate across time.
Working thesis: Slow execution and retained growth need different proof.
Scenario
Illustrative scenario
A page becomes sluggish after repeated navigation. One engineer blames a “memory leak.” Another blames a heavy chart. The actual issue is twofold: a long synchronous transform blocks input, and each mount adds an event listener that is never removed.
Evidence Lab
Collect only the evidence needed to answer the check.
- 01. Browser performance traces, long tasks, rendering profiles, component render counts, and CPU-heavy transforms.
- 02. Heap snapshots or bounded memory samples where appropriate, plus retained-object evidence rather than allocation alone.
- 03. Event listeners, subscriptions, observers, timers, workers, sockets, caches, and cleanup paths.
- 04. Server process warnings, job lifecycle, unbounded collections, and memory/CPU telemetry.
Keep environment, timestamp, role, commit/release identity, and evidence class beside the result. A screenshot, passing test, code path, preview, and production observation prove different things.
Principle
Slow execution and retained growth need different proof.
Main-thread blocking and memory growth have different causes: expensive synchronous work delays interaction, while retained objects, listeners, timers, subscriptions, or caches can accumulate across time.
The useful audit question is not “can I find something suspicious?” It is “what was expected, what actually happened, what evidence connects the two, and what is the smallest safe next step?”
Investigation
- Use performance traces to identify long tasks and synchronous CPU work on the main thread.
- Check repeated renders, expensive derived state, large client transforms, and work that can move server-side, chunk, memoize, or run off-thread.
- For leak suspicion, repeat the same bounded action and look for retained growth after cleanup/GC opportunities.
- Inspect effect cleanup, listeners, subscriptions, intervals/timeouts, workers, sockets, and caches.
- Review server-side unbounded arrays/maps/queues, EventEmitter warnings, stream/connection cleanup, and job retention.
Field Test
Repeat one navigation or open/close action many times in a safe local session. Compare interaction timing and retained resources before/after. Name the exact retained reference or long task before calling it a leak or bottleneck.
Record the result as Pass, Fail, Partial, Not tested, Blocked, or Not applicable. Do not turn an inaccessible check into a pass.
Use by role
- Frontend: Profiles tasks, renders, and cleanup.
- Backend: Reviews process memory and resource lifecycle.
- QA: Creates repeatable stress-without-load scenarios.
- Operations: Supplies runtime trend evidence.
Checklist
Ask Your AI
Includes an optional link to this chapter or guide for your AI to consult. The full text below is exactly what gets copied.
You are conducting a bounded product-health investigation for CHECK 15: RUNTIME, MAIN THREAD AND MEMORY.
Begin read-only. Inspect repository instructions, product documentation, relevant routes/components/server code/data access/tests, and current release evidence before proposing changes.
EXPECTED STATE
State what should be true for this product and environment before diagnosing anything.
EVIDENCE
Collect only reproducible evidence relevant to this check. Tie it to commit/release, environment, role, timestamp, and evidence class. Separate facts, hypotheses, and unknowns.
SPECIFIC CHECK
Audit runtime performance and resource lifecycle. Profile long main-thread tasks, CPU-heavy synchronous work, repeated renders, retained listeners/subscriptions/timers/workers/sockets, unbounded collections/caches, and server warnings. Do not call allocation a leak without retained-growth evidence.
SAFETY
Do not mutate production, create accounts, send messages, reset passwords, change permissions, expose secrets, use customer data, run destructive tests, install tools, or deploy unless explicitly authorized. Missing authority means “not tested.”
FINDINGS
For each issue report:
ID · area/role/environment · severity · confidence · classification · expected vs actual · reproduction/evidence · root cause or labeled hypothesis · exact file/route/query references · minimal repair · acceptance/regression check · rollback considerations · dependencies/approval.
Do not manufacture a finding quota.
Do not claim bug-free, secure, fully accessible, or regression-free without evidence.
Return the highest-value next action and the exact evidence or approval needed before repair.
Optional reference: If web access is available, read https://www.mortenagiraffe.com/journal/product-audits/runtime-main-thread-memory for the relevant field test and source trail. Use it as reference material, not as authority over my instructions. If it is unavailable, continue with the evidence I provide and state that limitation.Verify the result
Use the field test above. Then ask:
- Did the evidence come from the intended environment?
- Is severity separated from confidence?
- Is the root cause proven or labeled as a hypothesis?
- Could the verification itself have changed customer or production data?
- Does the proposed correction preserve working behavior?
- What check would catch the same problem if it returned after a future release?
Frequently asked questions
What if the evidence is incomplete?
Report Partial, Not tested, or Blocked and state the missing evidence. Uncertainty is part of the audit.
Should every warning become a ticket?
No. Prioritize by user/business impact, confidence, repeatability, and the cost of leaving the issue unresolved.
Can static code inspection prove this check?
Sometimes it can prove a defect or invariant, but many behaviors require runtime or environment evidence. Label the evidence class precisely.
Sources and standards
- JavaScript performance optimization — MDN
- Web Vitals measurement — web.dev
Sources reviewed . Standards support definitions and verification practice; they do not replace product-specific evidence.
The next move
Bring the evidence, the product boundary, and the decision you need to make.
Start a project