Three.js Mobile Fallback Strategy

What this builds

A complete capability-detection and degradation system that wraps any Three.js scene, probing real GPU capabilities at init time and continuously monitoring runtime performance to dynamically scale scene complexity. The system assigns one of four rendering tiers (full, reduced, minimal, static) and provides a unified API for scene code to query its current tier and react accordingly.

• WebGL2/WebGL1 feature probe with actual draw-call benchmark, not just API presence checks.
• GPU renderer string parsing for known-weak chipsets (Mali-G52, Adreno 610, Intel UHD 620, Apple A11).
• Runtime FPS monitor that triggers tier demotion when frame time exceeds budget for N consecutive frames.
• Texture resolution capping, shadow map disabling, post-processing stripping per tier.
• Static image/CSS fallback for devices with no WebGL at all.
• Transparent to scene code: a single tier object gates every visual feature.

When to use / when not to

• Use this whenever a Three.js scene ships to a general audience (marketing site, product page, editorial experience) and must not break on low-end devices.
• Use this when the brief says "works on mobile" and the scene has shadows, post-processing, or >50k triangles.
• Do NOT use this for a kiosk, internal tool, or any app where you control the hardware. Just target that hardware directly.
• Do NOT use this as a substitute for optimizing the scene itself. A scene that needs 200 draw calls on desktop still needs to be reduced to 50, not just hidden on mobile. See three-js-fundamentals for geometry reuse and instancing fundamentals.
• For scroll-specific mobile performance (layer budgets, ScrollTrigger count management, thermal throttle resilience), see scroll-mobile-performance-strategy, which covers the 2D/CSS animation side. This toolkit covers the 3D/WebGL side exclusively.