A frame meter, and what it cannot see
Only counts are printed: the actual milliseconds differ on every machine. Each frame takes at least 20 ms here, because the busy loop asks for it.
A screen that refreshes 60 times a second gives your code 16.67 ms per picture, split between the CPU (your JavaScript and three.js's bookkeeping) and the GPU (the pixels). Performance work starts with measuring which side is late.
Change the code and press Run (Ctrl+Enter). Predict what will happen first, then break it on purpose and read what changes. Your edits are saved and match the lesson page.
Ready for more? This phase has 4 hands-on exercises with automatic checks.
Practice questions
Write the code in the editor, run it, then open the model answer to compare.
Write a function budgetFor(hz) that returns the frame budget in milliseconds and the draw-call count you could afford if each draw call cost 0.02 ms of CPU time and everything else took 6 ms.
Your page runs at 25 fps on a phone. Name the first experiment you run, and what each outcome means.
Explain it without notes
Why can timing renderer.render() with performance.now() mislead you?
How do you tell a CPU-bound page from a GPU-bound one with no special tools?
Console
Nothing logged yet.Expected console output
frames measured: 30
frames over the 16.67 ms budget: 30 of 30
median is above the budget: true
a 120 Hz screen allows 8.33 ms; a 30 fps cap allows 33.33 ms