2 :-)
source | link

Apart from the comments from ZistolenZistoloen and John Conde, the first thing to do is test yourself the situation. Replicate the situation and environment reported by the users to see if the problem happens to you.

If you can't replicate completely the environment, at least try to do it as close as you can.

Test the load of the site in many browsers, preferably on private sessions and with a tor session or any similar service, that should generate a load with a completely different set of proxies which will affect the cache between the actual hosting company and your computer.

In a local session, against the development server, so a clean load of the site with verbose logging activated and check to see if there is any problem there. If there is a misconfiguration on the server, it may be keeping the browser active or on a waiting state which may cause problems. Although a crash seems unlikely.

Test in local environment, and clean cache the load on the system when the browser loads the page, that way you can see if there is any spike on resources.

If you developed the application, go one step at a time, deactivate the most intensive part of the JS and test the application, repeat until the system is stable. This procedure is more effective if you where able to replicate the situation reported by your users and managed to crash the browser.

91 request seems like a lot, and if there are strange, on unmet dependencies between elements that have not being loaded on time, that can cause problems on the V8 compiler of Chrome, which may not be as serious on spidermonkey due to the way it preprocesses the code.

Apart from the comments from Zistolen and John Conde, the first thing to do is test yourself the situation. Replicate the situation and environment reported by the users to see if the problem happens to you.

If you can't replicate completely the environment, at least try to do it as close as you can.

Test the load of the site in many browsers, preferably on private sessions and with a tor session or any similar service, that should generate a load with a completely different set of proxies which will affect the cache between the actual hosting company and your computer.

In a local session, against the development server, so a clean load of the site with verbose logging activated and check to see if there is any problem there. If there is a misconfiguration on the server, it may be keeping the browser active or on a waiting state which may cause problems. Although a crash seems unlikely.

Test in local environment, and clean cache the load on the system when the browser loads the page, that way you can see if there is any spike on resources.

If you developed the application, go one step at a time, deactivate the most intensive part of the JS and test the application, repeat until the system is stable. This procedure is more effective if you where able to replicate the situation reported by your users and managed to crash the browser.

91 request seems like a lot, and if there are strange, on unmet dependencies between elements that have not being loaded on time, that can cause problems on the V8 compiler of Chrome, which may not be as serious on spidermonkey due to the way it preprocesses the code.

Apart from the comments from Zistoloen and John Conde, the first thing to do is test yourself the situation. Replicate the situation and environment reported by the users to see if the problem happens to you.

If you can't replicate completely the environment, at least try to do it as close as you can.

Test the load of the site in many browsers, preferably on private sessions and with a tor session or any similar service, that should generate a load with a completely different set of proxies which will affect the cache between the actual hosting company and your computer.

In a local session, against the development server, so a clean load of the site with verbose logging activated and check to see if there is any problem there. If there is a misconfiguration on the server, it may be keeping the browser active or on a waiting state which may cause problems. Although a crash seems unlikely.

Test in local environment, and clean cache the load on the system when the browser loads the page, that way you can see if there is any spike on resources.

If you developed the application, go one step at a time, deactivate the most intensive part of the JS and test the application, repeat until the system is stable. This procedure is more effective if you where able to replicate the situation reported by your users and managed to crash the browser.

91 request seems like a lot, and if there are strange, on unmet dependencies between elements that have not being loaded on time, that can cause problems on the V8 compiler of Chrome, which may not be as serious on spidermonkey due to the way it preprocesses the code.

1
source | link

Apart from the comments from Zistolen and John Conde, the first thing to do is test yourself the situation. Replicate the situation and environment reported by the users to see if the problem happens to you.

If you can't replicate completely the environment, at least try to do it as close as you can.

Test the load of the site in many browsers, preferably on private sessions and with a tor session or any similar service, that should generate a load with a completely different set of proxies which will affect the cache between the actual hosting company and your computer.

In a local session, against the development server, so a clean load of the site with verbose logging activated and check to see if there is any problem there. If there is a misconfiguration on the server, it may be keeping the browser active or on a waiting state which may cause problems. Although a crash seems unlikely.

Test in local environment, and clean cache the load on the system when the browser loads the page, that way you can see if there is any spike on resources.

If you developed the application, go one step at a time, deactivate the most intensive part of the JS and test the application, repeat until the system is stable. This procedure is more effective if you where able to replicate the situation reported by your users and managed to crash the browser.

91 request seems like a lot, and if there are strange, on unmet dependencies between elements that have not being loaded on time, that can cause problems on the V8 compiler of Chrome, which may not be as serious on spidermonkey due to the way it preprocesses the code.