Jump to content


Runtime benchmark index, to check if device can handle it

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts

How can I test the performance of the visitor's device on page load? So that if it does <20 FPS I can skip animations altogether


I didn't find anything like this in the documentation

Link to comment
Share on other sites



Once I had in mind creating a fps to check how the created animations were working, for many resons I didn't even started but the few things that I had in mind was using the requestAnimationFrame method.


One thing that you could use is the ticker property of the engine (api reference) in order to check how many times the engine is updating. To read more detailed info about it check the following posts:






Jack explains with a little more detail how the ticker property works under the hood and maybe this can help you getting started.


Hope this helps,



Link to comment
Share on other sites

Hi Federico,


Welcome to the GreenSock forums.


I saw you tweet about this issue, thanks so much for posting it here. Twitter's character limit makes it pretty difficult to communicate about technical issues. 


Right now we don't provide stress tests, but I can give you some tips on what you can do. 

First there are a few things to keep in mind. 


All the calculations that GSAP performs are highly optimized and run extremely fast. It would be very uncommon that any JavaScript execution taking place inside the engine would cause an issue with your site. 99.99% of the performance issues you may encounter with GSAP will be due to browser rendering performance. 


In short, GSAP is just running some math to change numeric values over time. Most likely those values are being applied to css properties. When the browser needs to repaint / render the updates, that is where the heavy lifting takes place. Browsers vary greatly in their ability to quickly and repeatedly redraw the DOM. 


That being said, the only way to stress test a device is create an animation, wait for it to play, and then figure out how long it took. Whatever test you create the end user will have to see. Keep in mind that in order to create a decent stress test, you are going to have to create a test that is well, reasonably stressful, and by its very nature won't look good on a number of older devices.


Do you really want the first thing your mobile users see be a poor looking animation?

Sure, chances are most animations are going to run VERY well on iOS and modern Android devices, but the type of animation you have in mind may be too much for older hardware. 


You can use some properties of TweenLite.ticker to get an accurate sampling of fps.

ticker.time is the current time in seconds

ticker.frame is the number of the current frame


View the codepen demo here

See the Pen e95ae74f13bb1a9c9eb3c4734f18e113 by GreenSock (@GreenSock) on CodePen



Notice after the animation runs you see how long the animation took and the fps.


You can uncomment the line of code that has 

//.call(alert, ["wait a little bit"], window)

to simulate a processor hangup as JavaScript execution will halt when an alert() fires.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.