GSAP "filter:blur" animation is super glitchy on first load only (Chrome browser).

[Akufeninc]

The blur animation on the peach coloured text is super glitchy when you visit the website for the first time only (Chrome browser).
https://witnessestohistory.museeholocauste.ca/

You can recreate the issue by visiting in "Incognito mode", or clearing your cache.

If you refresh your browser or visit another page, the same animation runs super smoothly.

My current animation setting is :
 

this.tl.staggerFromTo(this[splitKey], this.duration, { css: { opacity:0, scale:1.3, filter:"blur(10px)", z:0 } }, { css: { opacity:1, scale:1, filter:"blur(0px)", z:0 }, ease:this.easing}, this.stagger[splitKey]);

I have tried all of the following :

- this.tl.progress(1).progress(0); (before playing my timeline)
- z:0.01
- backface-visibility: hidden
- will-change: transform, filter
- -webkit-font-smoothing: subpixel-antialiased
- gsap.set(this[splitKey], { force3D:true })
- Adding a huge delay before the animation starts to prevent overlapping of effects / images loading
- Adding page cache
- Adding a "loader" with a blur animation out to prepare the GPU for the effect, since it seems to run smoothly the second time (didn't work)

See the Pen by (@) on CodePen.

[ZachSaucier]

Hey Akufeninc and welcome to the GreenSock forums. Interesting (albeit very performance intensive) effect!

 

55 minutes ago, Akufeninc said:

The blur animation on the peach coloured text is super glitchy when you visit the website for the first time only (Chrome browser).
https://witnessestohistory.museeholocauste.ca/
You can recreate the issue by visiting in "Incognito mode", or clearing your cache.
If you refresh your browser or visit another page, the same animation runs super smoothly.

This almost always means that it's a loading issue, not an issue with GSAP. Most likely resources are still loading or the page is still being set up so that takes away from the resources allowed to be animating. Like I said already, your animation is very performance intensive so you'll likely see some sluggishness on some devices regardless. 

 

You can try waiting for everything  to load and be setup before starting the animation. I'm betting that will help a bit. But I'm afraid there's not much we can help you with.

[Akufeninc]

Hi Zach and thank you for the quick response
 

1 hour ago, ZachSaucier said:

This almost always means that it's a loading issue, not an issue with GSAP. Most likely resources are still loading or the page is still being set up so that takes away from the resources allowed to be animating. Like I said already, your animation is very performance intensive so you'll likely see some sluggishness on some devices regardless. 

I get that it's a very performance intensive animation, but how can we explain that it always runs super smooth once we refresh the page?

The lag only (and always) occurs in a fresh incognito mode, or with cache cleared... other than that, if you refresh the page after your first view and navigate the rest of the website, it will look super smooth!

Regarding the loading, as I mentioned in my 7th point, I've already tried adding a huge delay on the animation, to make sure that all the other assets and images were fully loaded. Still, the lag appears on the first load only :S

[ZachSaucier]

5 minutes ago, Akufeninc said:

how can we explain that it always runs super smooth once we refresh the page?

Like I said, I am guessing it's due to other things being set up (other content loaded, etc.). Unfortunately we don't have the time or capacity to debug exactly what the cause is for you. If you have a GSAP question please ask and we'll do our best to help!

[ichise.yuya]

The root cause is Metal PSO (Pipeline State Object) shader compilation, not asset loading.

I hit the exact same symptom and traced it through hours of measurement. Sharing the findings in case it helps others.

On macOS, Chrome's filter rendering goes through Apple's Metal API. The first time a specific combination of CSS properties (including filter: blur(...)) is rendered on a page, Metal needs to compile a Pipeline State Object (PSO) for that shader. Once compiled, it gets cached to disk, which is why the glitch disappears on reload — the PSO is already on disk.

How to verify this yourself:

1. Fully quit Chrome.
2. Delete the Metal shader cache:

    

    

   rm -rf "$(getconf DARWIN_USER_CACHE_DIR)com.google.Chrome.helper/com.apple.metal"/*

   rm -rf "$(getconf DARWIN_USER_CACHE_DIR)com.google.Chrome/com.apple.metal"/*

    
3. Relaunch Chrome and load your page — the GSAP blur glitch comes back.
4. Reload without clearing — glitch is gone.

You can also watch the cache fill up live by checking the byte counts of functions.list and libraries.list inside those directories. Each entry is 56 bytes after a 36-byte header, so (size - 36) / 56 gives the PSO count. This lets you measure exactly which CSS operations trigger new shader compilations.

A non-obvious catch I also found:

CSS @keyframes animations of filter and GSAP-driven filter animations compile different PSOs in Metal. So you cannot "pre-warm" a GSAP blur animation by playing a CSS @keyframes blur animation earlier — the cache isn't shared between those two render paths. This is because CSS @keyframes on filter/opacity/transform can be offloaded to the compositor thread, while GSAP writes inline style.filter on the main thread every frame, which goes through a different pipeline.

Practical workaround for the first-load glitch:

Play the exact GSAP filter: blur(...) tween once at load time (off-screen or at opacity: 0.01) to warm the cache before the user sees the real animation. The duration matters — blur needs about 2 seconds of real animation time for Metal to finish compiling every intermediate value; shorter durations require multiple replays.

Hope this saves someone else the same debugging marathon. Happy to share more measurement details if anyone's interested.