FOUC prevention for Interactions with GSAP

Updated

Learn how Webflow automatically prevents Flash of Unstyled Content (FOUC) for Interactions with GSAP.

In web design, animations that use from or from/to transitions can cause elements to briefly appear before their animation starts. This effect, called Flash of Unstyled Content (FOUC), can be jarring for visitors. Webflow now automatically prevents FOUC when you use Interactions with GSAP — no action needed on your end.

How Webflow prevents FOUC

Webflow uses JavaScript to inject the CSS rule visibility: hidden !important; to hide elements that have initial animation states (i.e., from or from/to).

When Webflow is ready to initialize the animation, it adds the class w-mod-ix3 to the document root. This class removes the visibility: hidden style, allowing the animation to run smoothly without any flash.

FAQs

Do I need to do anything if I already have a custom-coded solution for this?

You don’t need to make any retroactive changes. However, we recommend testing by removing your custom-coded solution to see if Webflow’s built-in FOUC prevention works for your setup. If it doesn’t, let us know what you’re trying to achieve and share the site where the automatic FOUC prevention didn’t work so we can improve our approach in the future.

Can I choose which interactions to opt out of?

At this time, it’s not possible to opt out. The behavior applies automatically to all interactions. If you have specific use cases that would benefit from an opt-out option, let us know what you’re trying to achieve and share the affected site so we can review the behavior in detail.

What happens if a visitor has JavaScript disabled in their browser?

The CSS that hides elements isn’t injected for those visitors, so they may experience FOUC.

Why does FOUC prevention only apply to some of my animations?

Automatic FOUC prevention works only when your animation’s targeting translates to a valid CSS selector. Because the GSAP targeting system is highly flexible, some targeting patterns work perfectly at runtime but can’t be expressed as CSS.

If your targeting uses complex scoping or dynamic selectors, FOUC prevention won’t apply automatically. In these cases, you’ll need to add custom code in your page head to initially hide elements (using data attributes or classes), then reveal them once your animations are ready.

Why use visibility: hidden instead of opacity: 0?

opacity: 0 hides content visually, but it doesn’t prevent screen readers from accessing it or stop keyboard navigation from tabbing through it.

visibility: hidden ensures the content is completely unavailable until it’s ready to appear, creating a consistent and accessible experience for all visitors.

Why does an element flash or appear in the wrong state when multiple animations target it?

This can happen with page transitions or when combining different animation triggers (e.g., page load + hover, or page load + scroll). If the same element is targeted by multiple animations with different initial states, the FOUC prevention system can’t determine which starting value to use. This can lead to flashing, jumping between states, or animations competing to load on page initialization.

To fix this, you can use one of these options:

  • Switch conflicting animations to “Animate to” tweens instead of “Animate from.” Only from or from/to tweens trigger FOUC prevention, so if your element’s default CSS state is already where it should start, using to tweens avoids conflicts.
  • Use separate elements for each animation context — e.g., one for your fade-out, another for your fade-in. This ensures each element has a single, clear initial state.
  • Restructure your animations so they all expect the same initial state.
  • Add custom code in your page head to manually apply your own FOUC prevention logic.