You do not run out of "GPU power" first. You run out of draw calls, then shader variants, then overdraw, then memory, and only then triangles. Knowing the order is most of the skill, because each wall has a completely different fix.

The order you hit them

#	Wall	Symptom	Rough ceiling	Fix
1	Draw calls	fps scales with object count, not detail	~1–2k/frame	Draw calls are the budget — instancing, merging
2	Shader compiles	700–1200 ms freezes mid-play	any lazy compile	Shader compilation is the hitch you can't find — pre-warm
3	Overdraw	fps collapses when you look at something	fill-rate bound	alpha-test not alpha-blend; depth prepass
4	Texture memory	tab crashes, or silent downscale	~1–2 GB VRAM	fewer, smaller, compressed, procedural
5	Triangles	gradual, honest slowdown	5–12 M/frame	LOD, frustum + distance culling
6	CPU sim	main thread pinned, GPU idle	~2k active entities	fixed timestep, spatial hash, workers

The reason this order matters: someone whose game runs at 15fps almost always starts optimising triangles, which is #5. It is nearly never #5.

Real measurements

From Claude of Duty — what a 6-sentence prompt actually produced — a browser FPS, Apple silicon laptop, 1512×982 at DPR 2 (3.34 megapixels internal, not the 2.07 the CSS size suggests):

	before	after
fps p50	12–17	28–30
fps p99	4–9	14–17
worst frame	728–1236 ms	66–82 ms
shader compiles during play	34–35	0
boot	9–12 s	3.7–4.6 s
triangles	5.9 M → 11.3 M after art passes

Read the worst-frame row twice. A 1.2 second frame in a game reporting "94 fps median." That is wall #2 masquerading as a performance mystery, and no amount of triangle reduction would have touched it.

A median frame time hides the exact thing that makes a game feel broken. Report p50/p95/p99 and the worst frame, always. See Verify with pixels, not assertions.

Wall 1 — draw calls

Every mesh.render() is a JS→GL boundary crossing: bind program, bind VAO, upload uniforms, issue the call. The GPU is barely involved. At ~1000 calls you're spending more time asking for triangles than drawing them.

The fix is always "make N objects into one call":

InstancedMesh — same geometry, N transforms, one draw call
merged static geometry (BufferGeometryUtils.mergeGeometries) for anything that never moves
texture atlases so variants don't force a material (and therefore a call) split

A million grass blades in one draw call is this idea taken to its limit: one draw call for a field that looks like a million individual objects.

Wall 3 — overdraw is the sneaky one

Fill-rate cost is pixels shaded, not triangles. A grass field where 40 alpha-blended blades overlap every pixel shades that pixel 40 times, and transparent geometry can't use the depth buffer to skip. This is why grass demos die on integrated GPUs.

Alpha-test (cutout), not alpha-blend. Cutout writes depth, so later blades are rejected for free. Blended geometry must also be sorted back-to-front on the CPU — a second cost.
Depth prepass. Draw depth-only first (cheap fragment shader), then the real pass with depthFunc: EQUAL. Every hidden pixel is now shaded exactly zero times.
Postprocessing is pure fill rate: each full-screen pass costs your whole resolution again. At 3.3 MP, a chain of eight passes is 26 MP of shading before you've drawn any scene.

Wall 4 — texture memory

A 4096² RGBA texture with mipmaps is ~89 MB. Twelve of them is a gigabyte. Note that renderer.info.memory.textures counts textures, not bytes — it will look fine right up until the tab dies.

Procedural generation (Generating textures, meshes and sound from code) sidesteps this differently than people expect: it doesn't reduce VRAM, it removes download and disk, and it lets you generate at exactly the resolution the camera will ever see.

Wall 6 — the CPU, and the thing nobody tells you

Three.js does per-object frustum culling on the CPU each frame. At 10,000 objects that's 10,000 matrix-vs-plane tests before any drawing. Set frustumCulled = false on instanced meshes with a manual bounding volume, and cull per-chunk yourself.

Also: new THREE.Vector3() inside update() is a bug. At 60fps with 500 entities that's 30,000 allocations/second feeding the garbage collector, which shows up as periodic hitches you'll misdiagnose as GPU stutter for a week. Preallocate in init(), reuse forever.

What's actually impossible

Being honest about the ceiling, from the Claude of Duty — what a 6-sentence prompt actually produced post-mortem — eleven independent critics scored its frames against real Call of Duty; every critic in every round picked the real game. The gaps were specific and instructive:

Material richness. Procedural surfaces read as noise, not photographed reality, at close range. This is the hard ceiling of generating texture from code.
Indirect light. No real global illumination. Approximations only.
Characters and hands. Organic form is where procedural generation is weakest.

So: browser 3D can hit stylised AAA convincingly, and cannot hit photoreal AAA. Which is an argument for choosing a style with a defensible look — see The ChronoBlock engine — your hardened starting point, where low-poly-no-textures is a permanent constraint precisely because it caps complexity forever.

Beyond the walls

WebGPURenderer (three.js r160+) buys compute shaders, storage buffers and indirect draw — meaning GPU-driven culling and simulation where the CPU never sees an entity. That moves walls #1 and #6 substantially. It costs you Safari-version breadth and it is a different API. Worth it when you're genuinely draw-call bound and have already instanced everything.