Three.js Debug Profiler
Find root causes and optimize measured bottlenecks without breaking playability.
Follow the changed behavior's scope. Reuse the lead's existing reproduction and evidence; verify the affected path after a fix. A passing focused check only needs broader testing when shared behavior changed or an unresolved risk warrants it. Return measurements and defects to the lead for the consolidated verification pass.
Reference
references/debug-playbook.md — ordered triage for blank canvas, asset and audio loading, loop/animation/physics, input and mobile, the profiling sequence, and the __THREE_GAME_DIAGNOSTICS__ shape. Read it when debugging or profiling anything non-obvious.
Debug
- Reproduce locally with the same command and URL the user had.
- Read console, page, and network errors.
- Check canvas display size against drawing-buffer size.
- Check renderer, context, and loop ownership — more than one active loop is a common cause.
- Check camera aspect, near/far, lights, materials, fog, scene contents, transforms.
- Check asset paths, loaders, CORS, and base path.
- Check animation delta units, physics update order and fixed timestep, collider and body ownership, input listeners, pointer and touch behavior, resize, and audio context unlock when audio is involved.
- Fix the root cause in the module that owns it, then retest the exact broken path.
Profile
- Reproduce in the correct build mode — production preview when user-facing performance matters.
- Baseline the scenario: FPS and frame time, draw calls, triangles, geometries, textures, memory, bundle.
- Classify the bottleneck as CPU, GPU draw, GPU fragment, GPU vertex, memory, or network.
- Change one thing — instancing, shared resources, culling, LOD, DPR cap, cheaper shadows or post, texture discipline.
- Re-measure the same scenario and confirm visuals and playability held.
Report
Lead with the root cause or the measured bottleneck. Then files changed, baseline and post metrics, commands, screenshots, the broken path retested, and residual risks.
1---2name: threejs-debug-profiler3description: Debug and profile Three.js browser games: blank canvases, render and runtime bugs, asset and audio loading, animation, resize, mobile input, plus performance profiling of draw calls, triangles, textures, memory, shader and post-processing cost, and bundle size.4---5
6# Three.js Debug Profiler
7
8Find root causes and optimize measured bottlenecks without breaking playability.
9
10Follow the changed behavior's scope. Reuse the lead's existing reproduction and evidence; verify the affected path after a fix. A passing focused check only needs broader testing when shared behavior changed or an unresolved risk warrants it. Return measurements and defects to the lead for the consolidated verification pass.
11
12## Reference
13
14`references/debug-playbook.md` — ordered triage for blank canvas, asset and audio loading, loop/animation/physics, input and mobile, the profiling sequence, and the `__THREE_GAME_DIAGNOSTICS__` shape. Read it when debugging or profiling anything non-obvious.
15
16## Debug
17
181. Reproduce locally with the same command and URL the user had.
192. Read console, page, and network errors.
203. Check canvas display size against drawing-buffer size.
214. Check renderer, context, and loop ownership — more than one active loop is a common cause.
225. Check camera aspect, near/far, lights, materials, fog, scene contents, transforms.
236. Check asset paths, loaders, CORS, and base path.
247. Check animation delta units, physics update order and fixed timestep, collider and body ownership, input listeners, pointer and touch behavior, resize, and audio context unlock when audio is involved.
258. Fix the root cause in the module that owns it, then retest the exact broken path.
26
27## Profile
28
291. Reproduce in the correct build mode — production preview when user-facing performance matters.
302. Baseline the scenario: FPS and frame time, draw calls, triangles, geometries, textures, memory, bundle.
313. Classify the bottleneck as CPU, GPU draw, GPU fragment, GPU vertex, memory, or network.
324. Change one thing — instancing, shared resources, culling, LOD, DPR cap, cheaper shadows or post, texture discipline.
335. Re-measure the same scenario and confirm visuals and playability held.
34
35## Report
36
37Lead with the root cause or the measured bottleneck. Then files changed, baseline and post metrics, commands, screenshots, the broken path retested, and residual risks.
majidmanzarpour