Jump to content
Search Community

Performance Issues on Mobile

icdindia test
Moderator Tag

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

Hi,

 

I am aware my question is not complete but I need help to help you help me :P Do let me know what more I can provide to find a final solution.

We have created an entire website using GreenSock animation. There is one master timeline. Other timelines only perform certain animations. 

 

We are using TweenMax along with eraser.js, howler.js, slick.js, splittext.js, jquery-ui.js.

 

The issues is that the website keeps on crashing on mobile devices, including iPhone 6s plus. This is because website is alot RAM heavy and does not work well on any device which has less ram. It includes iPhones, iPads, most android smartphones. It works flawlessly on devices with good ram (OnePlus3).  I have used all browsers on the phones on which the website crashed. It is impossible to find the issue as I do not get any error log on crash. I have reach the conclusion that the issue is RAM based on the observation that after restarting the phone the website works fine for a few minutes before crashing again.

 

I have tried to debug it using chrome inspect element but have not been able to reach any conclusion. 

 

Following are the elements that I have looked at. 

- svg animation, I only have 1 single svg animation in the beginning of the website,

- dom elements. The number of dom elements was too much because of splittext which is not resolved,

- using x and y instead of left and top for better performance,

- using scale in only one animation

- using autoAlpha everywhere instead of opacity

 

I kindly request you to provide me more details on how can I debug my website. Following is the link : www.icdlabs.in/final

If you require any specific part of the code, I will post it here, please do let me know. 


Thanks in advance. 

 

Link to comment
Share on other sites

I'm sure you can appreciate how difficult it would be for us to debug something like this having never seen the code before.

 

I took a brief look at app.js here: http://www.icdlabs.in/final/js/app.js

 

I noticed that it appears that you are calling CustomEase.create() many times using the same path data. CustomEase.create is a bit processor intensive. My guess is you would only feel the hit when that js gets processed (when the app first loads, not when the animation actually runs) but we suggest that you create the ease once like so:

 

//create ease
CustomEase.create("myCustomEase", "M0,0 C0,0 0.025,0.309 0.03,0.318 0 ... ")

//use same ease in multiple animations

tl.to(thing1, 1, {x:100, ease:"myCustomEase");
tl.to(thing2, 1, {x:200, ease:"myCustomEase");

 

I see in some parts you are doing a lot of text animations of characters with opacity fades. I'd try removing those animations and see if mobile stuff runs better.

 

Since you have your site broken into chapters with animations for each, I would start by testing with just the code for chapter1, then add chapter2, test, then add chapter 3, then test. At the very least this will help you identify if an animation in a particular chapter is to blame or if there is a point that the timeline just has too much stuff in it. We've seen timelines run with thousands of tweens on mobile so I'm doubtful the amount of tweens in the timeline or something inside of GSAP is the problem.

 

that's really the best I can offer right now. 

 

  • Like 3
Link to comment
Share on other sites

Dear Carl,

 

Thanks a ton for the input. I really do understand what it takes to go through someone else's code. 

 

- I have tried removing all custom ease and still the website crashed,

- I have tried to remove the timelines for most of the chapters and still the website crashed,

- it really doesn't matter which Chapter I remove, the website crashed under all circumstances. I am not able to pin point any specific reason. 

 

This begs me to wonder if something is wrong with the way I am using GSAP. 

 

Can you please provide some more input on which other tweens might be responsible for the excessive load on the processor?

Also, is there any way to debug or identify what is causing the excessive cpu / ram usage? Is there any other tool that I can use to debug the website? 

 

Would you like to suggest a format that would be much less cpu intensive but give the same result? 

 

Thanks again for your effort. You are a life saver. 

 

Link to comment
Share on other sites

@icdindia

 

10 hours ago, icdindia said:

The issues is that the website keeps on crashing on mobile devices, including iPhone 6s plus. This is because website is alot RAM heavy and does not work well on any device which has less ram. It includes iPhones, iPads, most android smartphones. It works flawlessly on devices with good ram (OnePlus3).  I have used all browsers on the phones on which the website crashed. It is impossible to find the issue as I do not get any error log on crash. I have reach the conclusion that the issue is RAM based on the observation that after restarting the phone the website works fine for a few minutes before crashing again.

 

When you run out of RAM, it will use swap space on the device's internal memory (virtual memory), so that may not be the issue. But if different devices are constantly crashing without error logs, that should be huge red flag that your app is causing some sort of catastrophic failure. It takes a lot to cause a mobile device to crash.

 

Take a look at my task manager. Your app is at the top, and is completely off the charts. It should not be using that much CPU, GPU, or memory, especially when there is nothing really moving around on the screen.

 

nsazlPk.jpg

And here is what the FPS Meter looks like in Chrome. 84MB of GPU memory? Again, that is completely off the charts for what you're doing. 

 

54b7GC4.jpg

 

So what's going on behind the scenes? Here's what I recorded in the performance timeline.  

 

lkyrAvG.jpg

 

The purple areas of the graph show when the browser is rendering. It's constantly rendering, even when there is nothing really moving around on the screen. I don't know what it's rendering, but it sure is busy. Probably dealing with those 22,000 nodes your app created. Where or what those nodes are doing is beyond me, but they're most likely coming from that huge memory leak shown on the blue lines with the garbage collection. When you see sawtooth or steadily increasing patterns in your memory timeline, that's a good sign you have a memory leak.

 

So now the question is where and why these problems are happening. I tried to run your code through TypeScript to point out the errors, but it couldn't parse all of your code because there's a bunch of invalid code in it. It was able to parse enough to point out a bunch of global variables, which are can cause all sorts of trouble.

 

18 hours ago, icdindia said:

We have created an entire website using GreenSock animation. There is one master timeline. Other timelines only perform certain animations. 

 

That's probably where a lot of your problems are originating from. Timelines are designed for playing animations in a sequence, but your app is not linear. You can jump around to any part of it. So you're filling your memory up with animations and elements that might never be accessed. That'd be like going to Google Maps, and having it load the entire world before you could use it just in case.

 

At this point, I think you might be better off by just starting over. Trying to root all these problems seems like it might not be worth it.

  • Like 6
  • Thanks 1
Link to comment
Share on other sites

wow

great input.

 

Thanks a lot for your time and the details. I will plan how to move forward n will let you know if I am able to find a solution.

 

Will it be too much if I were to ask you for a suggestion for an architecture that will allow me to go back and forth and calling the correct animation instead of loading all the animations at the same time.

 

Should I be using jquery click function to call different tweens for each page instead of playing one timeline?

Or should I have one timeline for each chapter?

 

Do let me know what you think is the best way to go forward. 

 

Thanks a lot again. I really enjoyed working with GreenSock and I would recommend it to every other developer I meet. 

  • Like 2
Link to comment
Share on other sites

Hello @icdindia

 

I don't think this has to do with GSAP, but looks like your issue is all 12 of those animated gif's you have on the page.

  • chapter1.gif
  • chapter2.gif
  • chapter3.gif
  • chapter4.gif
  • chapter5.gif
  • chapter6.gif
  • chapter7.gif
  • chapter8.gif
  • chapter9.gif
  • chapter10.gif
  • chapter11.gif
  • chapter12.gif

Most of the animated gifs have dimensions of 200x200 (displayed at 40x40) with around 100 frames in each gif.

 

That is a crazy amount of frames to have the browser play along with several other 100 frame animated gifs. Those gif's should really be resized to be the original size of 40px by 40px in Photoshop, like you have in your markup. Your loading a bigger animated gif then what you need. Animated gifs are resource hogs, especially on mobile, and especially with such a high amount of frames repeating forever.

 

Keep in mind that when you load animated gif's into the page that they will immediately start to cycle (play) through their timeline regardless if they are hidden or have display none. Firefox is one of the only browsers that will actually stop the animated gif timeline when not visible. Whereas other browser like Chrome, IE, or MS Edge will keep your animated gifs animating even when hidden, causing wasting of RAM memory and other resources.

 

I bet if you comment out or remove all those animated gifs you will see an improvement in your site performance and not have all those memory leaks. Also do you really even need the animated gifs? With the size they are you cant even make out what is happening in the animated gif so in my opinion you cant even make out what is animating in the animated gif.

 

Just my observation and two cents :)

  • Like 5
Link to comment
Share on other sites

12 minutes ago, Jonathan said:

Just my observation and two cents :)

 

Thanks a lot for your observation and it really does help. Yes the gifs are important and is required by the designers.

 

Removing them does improve the performance a bit but the website is still crashing and memory leak is still at large. :(

 

Though I will look into reducing the size of the gifs to reduce the overall load on the website. 

 

Thanks. 

 

 

Link to comment
Share on other sites

Great detective work, Blake.

 

I still remain doubtful that a timeline that is too big is really the problem, especially since he said the crash still happened after removing most of the chapters.

 

We've seen plenty of ScrollMagic sites that make you scroll for a mile through a massive timeline without these types of problems.

 

However if there are  22,000 nodes being repainted constantly, that is absolutely concerning.

 

--

 

Jonathan,

 

Nice find with the gifs. I don't have much experience there but it will certainly be interesting to see what happens when they are removed.

 

--

 

icdindia,

 

There are definitely ways you could create the chapter animations on demand via function calls on click. Or you could re-architect the whole thing as a Single Page Application (SPA), but I really think your time is best spent finding the root cause of the issue. Unfortunately, my best advice there is to keep removing things until the problem goes away... or remove everything and add parts until the problem occurs. In addition to removing the JS animations you should probably remove the html that goes with them as well to make the node-count smaller too.

 

  • Like 4
Link to comment
Share on other sites

2 hours ago, OSUblake said:

@icdindia

The purple areas of the graph show when the browser is rendering. It's constantly rendering, even when there is nothing really moving around on the screen. I don't know what it's rendering, but it sure is busy. Probably dealing with those 22,000 nodes your app created. Where or what those nodes are doing is beyond me, but they're most likely coming from that huge memory leak shown on the blue lines with the garbage collection. When you see sawtooth or steadily increasing patterns in your memory timeline, that's a good sign you have a memory leak.

 

@OSUblake 

thanks for pointing me in the right direction. I did some reverse engg and found that the high number of nodes was due to the SVGs that I had used in the website. After removing the SVGs it has come down to 9k(max) from 42k(max) but still this is a lot.  I have not updated the code on the server so you wont be able to see the effect but I am still working on it and will get back to you as soon as I have more data.

 

Currently my focus is to reduce the js heap which is at 20mb at the moment. If you can provide some input how I can find which line is leading to the js heap, i would highly appreciate it. 

 

Thanks a lot for your time. It is highly appreciated. 

Link to comment
Share on other sites

On 7/20/2017 at 7:49 AM, Carl said:

Great detective work, Blake.

 

I still remain doubtful that a timeline that is too big is really the problem, especially since he said the crash still happened after removing most of the chapters.

 

We've seen plenty of ScrollMagic sites that make you scroll for a mile through a massive timeline without these types of problems.

 

I might have used a bad analogy there. I was not trying to suggest that the length of a timeline might be affecting performance, rather what's on a timeline and what's it's doing. 

 

In this case, there are a bunch of callbacks that run most of the logic for the app. Putting all those callbacks on a timeline might seem benign, but it can create all sorts of problems, like unintentionally triggering other callbacks.

 

That could be what's happening here. Jumping around your timeline is triggering callbacks, creating new timeline and SplitText objects, resulting in a memory leak. 

 

There's also a bunch of other stuff in your code that could be contributing to that or other problems. This is what your code looks like when I use it with TypeScript. All those red marks you see on the code map to the right are potential errors in your code, and there's about 270 of them.

 

0FW0eWF.jpg

 

 

Some of those errors are pretty basic, like not using a var to declare masterTL and prevPageID, resulting in global variables. You don't even need TypeScript to point that out. Had you been using JavaScript in strict mode, the browser would have thrown an error.

"use strict";

masterTL = new TimelineMax(); // => Error: masterTL is not defined

 

But most of the errors are caused by not checking for null and undefined values. $audioFile is an error because you're doing a strict null check, which won't catch undefined. To check for both null and undefined values, you should do it like this.

if ($audioFile != null) {

}

 

Using getLabelBefore() is an error because it can return null. If that happens, the value of prevPage will be "null-=1", which is probably not what you want. The browser will also throw an error when it tries to call replace on prevPageID.

 

There's just a bunch of stuff like that to go through and fix. That's why I recommended starting over.

 

  • Like 3
Link to comment
Share on other sites

@OSUblake thanks for the input.

 

Also, I found that position: fixed was causing a lot of trouble on mobiles. After removing it, the project is much faster. I will look into the bugs that you have pointed out and will try to resolve them. Starting afresh is not an option due to time limitation but thanks a lot for your help.

 

I will let you know how I was able to finally resolve all the issues. Thanks for your time. 

  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...

Hi All,

 

Thanks for the priceless time that you have spent on your input. I come here to give you some good news.

 

I have been able to solve the problem for at least iOS devices and I just couldn't have done this without everyone's input.

 

The issue was mostly with the HTML CSS and not a lot with javascript. 

 

So, when it comes to mobile, resources are limited and I had a lot of dom elements and a lot of css position fixed.

The final solution was many fold :

 

1) Reducing 22k dom elements to 6k dom elements,

I had 12 svg images. The need for so many svg elements was to have a crisp image on all devices and do minor svg animation using css. Removing most of the svg images and replacing them with 2x GIF images, reduced the number of dom elements to 6k approx. The size of the GIF images was also considerably less than SVG images. 

 

2) Replacing position fixed with position absolute

Position fixed was leading to increase memory usage and was not working well especially on ios devices. I did not go into the depth of the reason behind it but moving to position absolute improved the performance quite a bit.

 

3) Using display none for inactive html blocks

I have a single page application without the use of any ajax or angularjs. So, when I use autoAlpha to hide the blocks, it leaves the dom element active on the page. Making display none, it removes the element from the browser memory and it does not increase the memory usage. Again I did not have time to go indepth of how this is working but basically by turning on an off parts of the html, the performance has improved dramatically. 

 

4) Reducing GIF animations

Although GIF animations are one of the core elements on the website, but they lead to reduced FPS and increased load on memory. Reducing the number of GIF animations have improved the performance but we have not eliminated them completely. There still are a lot of GIFs on a single page but they are necessary for the product and worth the sacrifice. 

 

I hope people who come to read this article, learn from my mistakes. I will put up a blog entry in a few weeks, with supporting articles.

 

Thanks again for your support. The website will launch in a few days and we will submit it for showcase on your website. It will be an honour for us, if it is selected to be displayed on showcase list.

  • Like 2
  • Thanks 1
Link to comment
Share on other sites

thank you all for your support, it is highly appreciated. Please have a look at the final product. I would suggest using an iPhone 6 or better along with your headphone for the best experience. 

 

www.theministryofutmosthappiness.com 

 

Please consider posting our website as a showcase on your website.  In case you require any further details, you can write to me at vikrant at icdindia dot com 

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.
×
×
  • Create New...