Use case
three.js performance testing on real phones
Your three.js scene is silky at 60 fps on a MacBook and renders at 11 fps on a Galaxy A52 — and you found out from a client, on launch day. DoesItRunOn finds out for you, automatically, on real devices, before anyone else does.
The three.js mobile trap
Three.js makes beautiful scenes easy — and mobile-hostile defaults easier. Full-resolution render targets on high-DPR screens, post-processing chains, real-time shadows, unmerged draw calls: each is invisible on a desktop GPU and catastrophic on a mid-range phone's fill-rate budget. The r3f/three.js optimization advice all ends the same way: “test on real devices.” Nobody tells you how to do that repeatably.
Measure, tweak, re-run
With DoesItRunOn you point a run at your deployed scene (or a preview URL), optionally script the camera path or interaction that matters, and get back FPS and frame-time numbers per device. Halve your shadow map, drop DPR to 1.5, bake the lighting — then re-run and see the delta on the exact hardware that was struggling, instead of guessing.
For agencies: a deliverable, not a promise
If you ship award-site work, “smooth on mid-range Android” becomes a report you can attach to the handoff — median and p95 FPS across a named device list — rather than a claim the client tests with their own five-year-old phone in the meeting.
See your numbers on real hardware
Join the waitlist — early members lock in launch pricing and vote on the device pool.