Your idle Three.js scene is not too heavy, it is redrawing 60 times a second for nothing

A developer writing on dev.to noticed his iPhone got hot to hold while he sat on a static Ludo board in one of his own Three.js games, waiting for his turn, with nothing on screen moving ^[1][2]. His first instinct, which he flags as the wrong one, was that Three.js is too heavy for small games and should be replaced with plain Canvas drawing ^[3]. That instinct costs you a rewrite and buys nothing, because the renderer was never the variable.

Here is the loop every Three.js tutorial hands you ^[4]:

```js function animate() { requestAnimationFrame(animate); renderer.render(scene, camera); } animate(); ```

Two things are load bearing. `requestAnimationFrame` schedules a callback right before the browser paints the next frame, and browsers repaint roughly 60 times a second, so the callback runs roughly 60 times a second ^[5]. And `renderer.render` clears the framebuffer and redraws every object in the scene from scratch ^[6]. The GPU has no concept of your scene being "basically static": a motionless board at 60fps costs exactly what a board mid-animation costs, because it is doing identical work ^[7]. Sixty renders a second is 3,600 full-scene redraws per minute of you staring at a menu ^[8]; ten seconds of deciding a move is 600 of them ^[9].

Switching to Canvas2D does not help. According to the same post, a 60fps loop repainting a full-screen 2D canvas heats a phone just as happily ^[10]. The loop is the defect, not the library.

The guard is a dirty flag: a boolean you flip when something on screen actually changes, checked before you draw ^[11].

```js let needsRender = true; function invalidate() { needsRender = true; }

function animate() { requestAnimationFrame(animate); const moving = tweens.update() || particles.update(); if (needsRender || moving) { renderer.render(scene, camera); needsRender = false; } } animate(); ```

The rAF loop keeps ticking; only the expensive call is conditional. You call `invalidate()` from input handlers, animations and the resize listener, anywhere a pixel genuinely changes <sup>[12]</sup>. A board waiting on input then renders zero frames <sup>[13]</sup>, and a turn-based game spends almost its entire life waiting <sup>[13]</sup>. When something is animating, every frame pays for a real render again, which is the behaviour you wanted all along <sup>[14]</sup>. If you are on @react-three/fiber, this is one prop: `frameloop="demand"` on the `<Canvas>`, plus `invalidate()` calls <sup>[15]</sup>.

Two caveats on the evidence. The post demonstrates the difference with a side-by-side pair of simulated phones, one climbing hot and staying there, one sitting cold until tapped, and does not publish measured temperature or power numbers <sup>[16]</sup>. And the text breaks off mid-sentence while starting a second argument, that the frames you do draw each cost about twice something <sup>[17]</sup>, so the per-frame half of the optimisation is not verifiable from what was published.

What to watch: grep your own projects for unconditional `renderer.render` inside a rAF callback, which is most of them if you started from a tutorial. Then check the coverage of your `invalidate()` calls, because the failure mode of render-on-demand is a frame that should have been drawn and was not: a stale board after a resize, or a hover state that never paints. That bug is visible and fixable. A hot phone in a user's hand is neither.