Inconsistent performance of GSAP animations in Safari for iOS

[Vinny GG]

Hello, GSAP Community!
 

I'm facing an inconsistent performance issue when using GSAP for animations on iOS devices, specifically in the Safari browser. The same code works perfectly in Chrome for iOS and in browsers on Android, but in Safari the animations have a noticeable lag, appearing to miss frames, especially in animations synchronized with scrolling.
 

Tested browsers:
• Safari on iOS: has lag.
• Chrome on iOS: runs smoothly.
• Browsers on Android: perfect performance.

We've tried a few solutions:

1. Optimizing CSS properties for transformations (translate3d, will-change, etc.).

2. Adjusting the refresh rate of animations and force3D.

3. Reducing the complexity of animations to see if it's a load issue.

4. We've consulted other forums and followed tips like enabling/disabling specific GSAP settings, but to no avail in Safari.
 

This behavior appears to be specific to the Safari browser on iOS and seems to be a common issue reported by other developers.

I would like to know if the community has any more specific recommendations or solutions to work around this Safari limitation. Any tips on how to improve the performance of animations in Safari for iOS?

Code Example:

See the Pen vEBdQVZ?editors=1111 by Vinicius-Gouveia (@Vinicius-Gouveia) on CodePen.

[ryan_labar]

Hi @Vinny GG

 

Have you tried the scrollTrigger normalizeScroll? https://gsap.com/docs/v3/Plugins/ScrollTrigger/static.normalizeScroll()/

[GSAP Helper]

Yeah, performance is a deep topic. In our experience, Safari is just terrible with a lot of things like rendering performance as well as a ton of known browser bugs. Totally unrelated to GSAP. 

 

I see you're doing a gsap.ticker.add(() => {...}) - I'd make sure you're not accidentally duplicating that anywhere. And are you sure you definitely need that (it runs on every single tick forever)?

I know you've tried a lot of suggestions you've seen, but here are some general tips: 

1. Try setting will-change: transform on the CSS of your moving elements. 
2. Make sure you're animating transforms (like x, y) instead of layout-affecting properties like top/left. 
3. Definitely avoid using CSS filters or things like blend modes. Those are crazy expensive for browsers to render.
4. Be very careful about using loading="lazy" on images because it forces the browser to load, process, rasterize and render images WHILE you're scrolling which is not good for performance. 
5. Make sure you're not doing things on scroll that'd actually change/animate the size of the page itself (like animating the height property of an element in the document flow)
6. Minimize the area of change. Imagine drawing a rectangle around the total area that pixels change on each tick - the bigger that rectangle, the harder it is on the browser to render. Again, this has nothing to do with GSAP - it's purely about graphics rendering in the browser. So be strategic about how you build your animations and try to keep the areas of change as small as you can.
7. If you're animating individual parts of SVG graphics, that can be expensive for the browser to render. SVGs have to fabricate every pixel dynamically using math. If it's a static SVG that you're just moving around (the whole thing), that's fine - the browser can rasterize it and just shove those pixels around...but if the guts of an SVG is changing, that's a very different story. 
8. data-lag is a rather expensive effect, FYI. Of course we optimize it as much as possible but the very nature of it is highly dynamic and requires a certain amount of processing to handle correctly.
9. I'd recommend strategically disabling certain effects/animations and then reload it on your laptop and just see what difference it makes (if any). 

Ultimately there's no silver bullet, like "enable this one property and magically make a super complex, graphics-heavy site run perfectly smoothly even on 8 year old phones" 

I hope this helps!

[Vinny GG]

17 hours ago, ryan_labar said:

Hi @Vinny GG

 

Have you tried the scrollTrigger normalizeScroll? https://gsap.com/docs/v3/Plugins/ScrollTrigger/static.normalizeScroll()/

We already applied it and it didn't solve it
 

[Vinny GG]

17 hours ago, GSAP Helper said:

Yeah, performance is a deep topic. In our experience, Safari is just terrible with a lot of things like rendering performance as well as a ton of known browser bugs. Totally unrelated to GSAP. 

 

I see you're doing a gsap.ticker.add(() => {...}) - I'd make sure you're not accidentally duplicating that anywhere. And are you sure you definitely need that (it runs on every single tick forever)?

I know you've tried a lot of suggestions you've seen, but here are some general tips: 

1. Try setting will-change: transform on the CSS of your moving elements. 
2. Make sure you're animating transforms (like x, y) instead of layout-affecting properties like top/left. 
3. Definitely avoid using CSS filters or things like blend modes. Those are crazy expensive for browsers to render.
4. Be very careful about using loading="lazy" on images because it forces the browser to load, process, rasterize and render images WHILE you're scrolling which is not good for performance. 
5. Make sure you're not doing things on scroll that'd actually change/animate the size of the page itself (like animating the height property of an element in the document flow)
6. Minimize the area of change. Imagine drawing a rectangle around the total area that pixels change on each tick - the bigger that rectangle, the harder it is on the browser to render. Again, this has nothing to do with GSAP - it's purely about graphics rendering in the browser. So be strategic about how you build your animations and try to keep the areas of change as small as you can.
7. If you're animating individual parts of SVG graphics, that can be expensive for the browser to render. SVGs have to fabricate every pixel dynamically using math. If it's a static SVG that you're just moving around (the whole thing), that's fine - the browser can rasterize it and just shove those pixels around...but if the guts of an SVG is changing, that's a very different story. 
8. data-lag is a rather expensive effect, FYI. Of course we optimize it as much as possible but the very nature of it is highly dynamic and requires a certain amount of processing to handle correctly.
9. I'd recommend strategically disabling certain effects/animations and then reload it on your laptop and just see what difference it makes (if any). 

Ultimately there's no silver bullet, like "enable this one property and magically make a super complex, graphics-heavy site run perfectly smoothly even on 8 year old phones" 

I hope this helps!

Thanks for the help and recommendations. I will respond to each topic

We removed requestAnimationFrame() in order to use gsap.ticker.add(), I guess that's better due to lesser functions running every frame. The composition is not that complex.
1 - We're not using CSS transformations here

2 - We're not even using pin: true, it's straight position: sticky with top: 0, no other changes.

3 - We're not using CSS filters.

4 - We're using some loading="lazy" images, but they're way after the canvas.

5 - We're not doing this either.

6 - We've isolated the problem and it's a bit better, but not there yet.

7 - We're not using SVG animation here.

8 - No data-lag has been used.

9 - That's a good test, but scrolling on Safari is not smooth

I will make a video available showing the difference between browsers
https://cdn.discordapp.com/attachments/831999591032684604/1327263564288753694/RPReplay_Final1736514661.mov?ex=67826e05&is=67811c85&hm=7e9f1f5e45fb1699536e8d08b770ff13f2380226b9dd4f396a4a1e826f7d552e&
 

[Cassie]

Unfortunately the best advice is usually just to step things back for mobile. It's honestly a pretty sensible approach in general - from a UX perspective people generally just want speed and ease of use on mobile - they're on the move, often on slow connections, might have low battery, animations can be annoying and get in the way of the content when you have less real estate to work with.

I often create minimal versions of animations for mobile, keep it simple, stick to opacity and transforms, keep the really fun stuff for desktop.

[Cassie]

Looks like you're animating a three.js model with a video texture? That's a lot of work for a mobile browser! 

Maybe post on the three.js forum and see whether they have any perf optimisation suggestions.

[Vinny GG]

I found this site that has the same animation. However, this version works well on Safari.

What's different about theirs?
 

https://work.outloud.co/pohoda

My Site:
https://microsite-ezgage.buzzvel.work/

[Rodrigo]

Hi,

 

I tested both URLs on an iPad (iOS 17) in the latest chrome and safari and can't seem to spot many differences between both sites. Also is worth noticing that the URL that you claim it works, has a few hiccups if I scroll fast enough.

 

Unfortunately there is nothing we can do with a live production site and even with access to the code is really hard. We just don't have the time resources to start digging into a production site and find out what could be the problem and try different solutions, is just beyond the scope of the help we provide in these free forums. This falls more into the consulting side of things. You can post in the Jobs & Freelance forums in order to get help there .

 

Sorry I can't be of more assistance 😞

[aronanol]

Hi Vinny GG, did you found some way to fix that ? Got right now one project with three.js too, running on 60fps on firefox mobile, chrome mobile, just while scrolling on safari I got fps drop to 40fps , if I dont scroll everything is at 60ps. 

This one occurs only on safari IOS.