How to detect lacking hardware to prevent crashes for users

I have a backup comp, an old 2011 Mac that actually ran three.js fine in Firefox until recently. Recently the render loop freezes the entire OS solid.

It runs the latest ECMAscript though, so I’m wondering what other kind of detection I could run to sniff this out for browsers on a live site?

[EDIT] - after some more testing, it is related somehow to my code because I can run other threejs in Firefox still. However, I can run MY code in all other browsers too, so it’s something unique to my code + old Mac hardware + Firefox. The OS slows to about 1 action every 60 seconds, and I could see there are no console errors, it just freezes basically.

If there’s any way I could detect it ahead of time that’d be cool so I don’t crash my grandma’s comp :slight_smile:

Hi !

I think in general sniffing hardware do adapt performance does not give good result, because for example you can have a poor computer but run your browser in windowed mode. Or you can have a good one but have expensive tasks in the background. And even your own app can be unevenly demanding, so in order to keep high FPS, you must detect FPS not hardware.

Here is a simplified version of the system I made in my work-in-progress game :

function loop() {

    requestAnimationFrame( loop );
    renderer.render( scene, camera );
    delta = clock.getDelta();

    /* detect FPS drops or climaxes and optimize accordingly */

    if ( delta > optimizer.OPTFPS ) {


    } else if ( delta < optimizer.DEOPTFPS ) {




Then in the “optimizer” module :

const OPTFPS = 1 / 45 ;	// FPS under which optimization must occur
const DEOPTFPS = 1 / 57 ; // FPS above which de-optimisation will occur

var optiLevel = 0 ;

function optimize() {
	switch ( optiLevel ) {
		case 0 :

            Perform here the first layer of optimization, like switching to no anti-alias renderer,
            stop rendering dynamic shadows... It depends on your app

			optiLevel = 1 ;

			break ;

		case 1 :

			// perform here the second layer of optimization

			optiLevel = 2 ;

			break ;



function deOptimize() {
	// Do the reverse of optimize()


Hey that is a pretty slick optimizer, I’ll bookmark that.
In this case, the hardware issue is so bad that fps is something like .001. So I think what I may do is a “pre-flight” attempt to render just one frame, and queue up the real loop depending on that.

What is your game by the way?

1 Like

It’s weird, I wonder if it’s just because of lacking hardware…

It’s a 3D platformer, and I want to make it playable on smartphone, so I had to think of a very broad way to adapt the game to any device capabilities, I’m quite happy with this system.