3.3 Different ways to add GSAP to a WordPress site

When working with WordPress and BricksBuilder, there is no single correct way to add GSAP. In practice, there are several valid methods, and each has different strengths, weaknesses, and ideal use cases. Choosing the right setup early will save you a lot of frustration later ⚙️

The main goal is always the same:

1. Load GSAP core correctly
2. Load any GSAP plugins you need
3. Load your own animation code
4. Make sure the loading order is reliable
5. Keep the setup maintainable as your site grows

A useful mental model is:

$$
\text{Animation setup} = \text{library files} + \text{your custom code} + \text{correct load order}
$$

If even one of these parts is missing, your animations may fail, partially work, or behave unpredictably.

---

The main ways to add GSAP in WordPress

There are five common approaches you should know:

1. Add GSAP via a CDN
2. Add GSAP by hosting the files locally
3. Add GSAP through your theme or child theme
4. Add GSAP directly inside BricksBuilder custom code areas
5. Add GSAP using a plugin or code management tool

You do not need to use all of them. Usually, you will pick one main strategy and stay consistent.

---

1. Adding GSAP via CDN

A CDN (Content Delivery Network) is one of the fastest and easiest ways to start. Instead of storing GSAP files in your WordPress installation, you load them from an external URL.

How it works

You include a script tag that points to the GSAP file hosted elsewhere, for example:

<script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js"></script>

If you need a plugin such as ScrollTrigger, you also load that after GSAP core:

<script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/ScrollTrigger.min.js"></script>

Then your own animation script comes after both:

<script>
document.addEventListener("DOMContentLoaded", function() {
  gsap.to(".box", {
    y: -50,
    duration: 1
  });
});
</script>

Why beginners like this method

1. It is quick to set up
2. You do not need to upload files manually
3. You can test GSAP in just a few minutes
4. It works well for learning and experimentation

Advantages

1. Very easy to start

   You can add one or two script tags and immediately verify that GSAP is working.

2. No file management

   You do not need to download library files or place them in theme folders.

3. Good for testing

   If you want to create a simple “GSAP is working” test animation, CDN is often the fastest route.

4. Convenient in Bricks

   You can place the CDN script in site-wide code areas and begin quickly.

Disadvantages

1. External dependency

   Your site relies on another server to deliver the script.

2. Less control

   If you want strict control over versions, caching, or file location, local hosting can be better.

3. Can become messy

   If you scatter CDN snippets across multiple places in WordPress, it becomes harder to manage.

4. Potential policy issues

   Some projects or clients prefer fewer external dependencies for privacy, compliance, or performance reasons.

Best use cases

1. Learning GSAP for the first time
2. Building a quick prototype
3. Testing whether GSAP works in your site
4. Smaller projects with simple needs

Important loading order

If using CDN, always load in this order:

1. GSAP core
2. Plugins
3. Your custom script

For example:

<script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/ScrollTrigger.min.js"></script>
<script>
document.addEventListener("DOMContentLoaded", function() {
  gsap.registerPlugin(ScrollTrigger);

  gsap.from(".hero-title", {
    y: 60,
    opacity: 0,
    duration: 1
  });
});
</script>

---

2. Hosting GSAP locally on your WordPress site

This means you download the GSAP files and place them in your own website files, usually inside your theme or child theme.

How it works

Instead of linking to an external CDN URL, you load a file from your own site, such as:

<script src="/wp-content/themes/your-child-theme/assets/js/gsap.min.js"></script>

You might structure your files like this:

your-child-theme/
  assets/
    js/
      gsap.min.js
      ScrollTrigger.min.js
      custom-animations.js

Why this method matters

Local hosting gives you more control. Many developers prefer this setup for professional projects because it is easier to manage consistently over time.

Advantages

1. Full control over files

   You decide which version of GSAP is loaded and when it gets updated.

2. No reliance on third-party delivery

   Everything comes from your own site.

3. Cleaner long-term setup

   Especially useful if your site grows and uses many custom scripts.

4. Better for structured development

   You can organize scripts, versions, and custom code more cleanly.

Disadvantages

1. Slightly more setup work

   You need to upload files and reference them correctly.

2. Requires basic file organization

   You should understand where theme files live and how WordPress loads assets.

3. Version updates are manual

   If you want a newer GSAP version, you must replace the files yourself.

Best use cases

1. Production websites
2. Projects that need better maintainability
3. Client sites where you want stable, controlled asset loading
4. More advanced setups with multiple custom scripts

Recommended approach

If you are serious about using GSAP regularly, this is one of the best long-term methods ✅

---

3. Adding GSAP through a theme or child theme

This is not really separate from local hosting—it is more the WordPress-native way to do it properly.

Instead of just pasting script tags somewhere, you use WordPress functions to enqueue scripts.

Why enqueuing matters

In WordPress, scripts should ideally be added using wp_enqueue_script(). This gives WordPress better control over:

1. Dependencies
2. Loading order
3. Footer loading
4. Versioning
5. Conflict prevention

This is the professional way to load scripts.

Example using functions.php

Here is a clean example for a child theme:

function mytheme_enqueue_gsap_scripts() {
    wp_enqueue_script(
        'gsap',
        get_stylesheet_directory_uri() . '/assets/js/gsap.min.js',
        array(),
        '3.12.5',
        true
    );

    wp_enqueue_script(
        'gsap-scrolltrigger',
        get_stylesheet_directory_uri() . '/assets/js/ScrollTrigger.min.js',
        array('gsap'),
        '3.12.5',
        true
    );

    wp_enqueue_script(
        'custom-gsap-animations',
        get_stylesheet_directory_uri() . '/assets/js/custom-animations.js',
        array('gsap', 'gsap-scrolltrigger'),
        '1.0.0',
        true
    );
}
add_action('wp_enqueue_scripts', 'mytheme_enqueue_gsap_scripts');

Why this is powerful

Notice the dependency arrays:

1. array() for GSAP core
2. array('gsap') for ScrollTrigger
3. array('gsap', 'gsap-scrolltrigger') for your own script

This tells WordPress:

• load GSAP first
• then load ScrollTrigger
• then load your custom animation file

So WordPress handles the order for you.

Advantages

1. Most professional WordPress method
2. Reliable dependency handling
3. Cleaner than random script tags
4. Scales well on larger projects
5. Works well with child themes

Disadvantages

1. Requires access to theme files
2. Needs some PHP comfort
3. Slightly harder for complete beginners

Best use cases

1. Serious WordPress projects
2. Child-theme-based workflows
3. Sites with reusable custom functionality
4. Cases where you want clean script architecture

Important note for Bricks users

If you use BricksBuilder, this method is still excellent. Bricks does not replace WordPress script best practices. Bricks is your builder, but WordPress is still the underlying system.

So if you are comfortable using a child theme, this is often one of the best foundations for GSAP.

---

4. Adding GSAP directly in BricksBuilder custom code

BricksBuilder gives you several places to add code, which makes it attractive for people who want a simpler workflow.

This can include:

1. Page settings custom code
2. Template-level custom code
3. Site-wide custom code
4. Header or footer script areas
5. Code elements inside the builder

This method is often the most approachable for non-developers because it avoids editing theme files.

Typical workflow

You might:

1. Add the GSAP CDN script globally
2. Add plugin scripts globally
3. Add your custom animation JS in Bricks custom code or in a code element

For example:

<script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js"></script>
<script src="https://cdn.jsdelivr.net/npm/gsap@3/dist/ScrollTrigger.min.js"></script>

Then later, in a custom code area:

<script>
document.addEventListener("DOMContentLoaded", function() {
  gsap.registerPlugin(ScrollTrigger);

  gsap.from(".card", {
    opacity: 0,
    y: 40,
    duration: 0.8,
    stagger: 0.15
  });
});
</script>

Advantages

1. Very convenient

   You can manage code from inside the builder interface.

2. No need to edit theme files

   This lowers the technical barrier significantly.

3. Great for page-specific animations

   If an animation is only used on one page, this can be very practical.

4. Fast iteration

   You can tweak and test quickly while designing the page.

Disadvantages

1. Can become disorganized

   If you place scripts in many different templates and pages, it becomes hard to track them.

2. Dependency management is manual

   You need to make sure GSAP is loaded before your custom script.

3. Less ideal for large codebases

   As your project grows, a theme-based script setup can be cleaner.

4. Risk of duplication

   You may accidentally load GSAP multiple times in different places.

Best use cases

1. Learning and experimenting inside Bricks
2. Small to medium projects
3. Page-specific animations
4. Users who prefer builder-based workflows over theme development

Practical recommendation

For many Bricks users, a very sensible hybrid approach is:

1. Load GSAP and plugins globally
2. Add small page-specific animation code where needed
3. Move larger reusable animation logic into a dedicated script later

This gives you simplicity and room to grow 📌

---

5. Adding GSAP with a plugin or code manager

Another option is to use a WordPress plugin that lets you inject scripts globally or conditionally.

This might be:

1. A header/footer code injection plugin
2. A custom code manager plugin
3. A performance/plugin asset manager that supports script loading
4. Sometimes a dedicated integration workflow depending on your stack

How it works

You paste CDN script tags or custom JavaScript into a plugin-managed area, often:

1. Site-wide header
2. Site-wide footer
3. Specific pages
4. Specific post types
5. Conditional locations

Advantages

1. No theme editing
2. Easy for non-developers
3. Can be safer than editing core theme files
4. Useful if you do not want to touch PHP

Disadvantages

1. Another plugin dependency
2. May encourage “script dumping”
3. Can become messy if overused
4. Not always ideal for structured long-term development

Best use cases

1. Quick implementation
2. Projects where theme editing is restricted
3. Users uncomfortable with functions.php
4. Simple or transitional setups

Important warning

If you use plugins for script injection, be extra careful not to load:

1. GSAP in the plugin
2. GSAP again in Bricks
3. GSAP again in the theme

That can cause confusion, wasted requests, and potential conflicts.

---

Comparing the methods

Here is the practical difference between the common approaches:

1. CDN only

   Best for speed, learning, and quick tests

2. Local files + child theme enqueue

   Best for professional, maintainable projects

3. Bricks custom code

   Best for convenience and builder-centered workflows

4. Code injection plugin

   Best when you want simplicity without editing theme files

5. Hybrid approach

   Often the best real-world solution

A good hybrid setup might look like this:

1. Load GSAP globally through the child theme or Bricks global custom code
2. Load plugins globally only if widely used
3. Put page-specific animation logic where it is easiest to manage
4. Move repeated logic into reusable external JS files later

---

Which method should you choose as a BricksBuilder user?

If your JavaScript and CSS skills are still developing, the best path is usually not the most “developer-pure” one, but the one that is both safe and manageable.

I would recommend this progression:

1. Start with CDN + Bricks custom code

   This is the easiest way to understand how GSAP works and create your first animations.

2. Move to global loading

   Once you know you want GSAP site-wide, place GSAP in a single global location.

3. Graduate to child theme enqueueing

   As your projects become more advanced, move to a cleaner WordPress-native setup.

This progression lets you learn without getting blocked by technical setup too early 🎯

---

Recommended setups by experience level

1. Absolute beginner

   Use:

   1. CDN for GSAP
   2. Bricks custom code for your animation scripts

   Why:

   1. Fastest setup
   2. Easiest to understand
   3. Minimal technical friction

2. Beginner to intermediate

   Use:

   1. Global GSAP loading in Bricks
   2. Page-level or template-level custom JS where needed

   Why:

   1. Cleaner than pasting scripts everywhere
   2. Still easy to manage
   3. Good balance of simplicity and structure

3. Intermediate and beyond

   Use:

   1. Child theme
   2. Proper wp_enqueue_script()
   3. External custom JS files

   Why:

   1. Better architecture
   2. Better reuse
   3. Better long-term maintenance

---

What “correct loading order” really means

This is one of the most important concepts in GSAP setup.

If your script runs before GSAP is available, you will get errors like:

gsap is not defined

If your plugin runs before GSAP core, the plugin may fail.

The correct dependency chain is:

1. GSAP core
2. Any GSAP plugins
3. Plugin registration
4. Your animation code
5. Only after the DOM elements exist

Conceptually:

$$
\text{Working animation} \Rightarrow \text{library loaded first} \land \text{target exists when code runs}
$$

That is why many examples use:

document.addEventListener("DOMContentLoaded", function() {
  // animation code here
});

This makes sure the page structure exists before your code tries to animate it.

---

A simple decision framework

If you are unsure which path to choose, use this checklist:

1. Do I just want to test GSAP quickly?

   Choose:

   1. CDN
   2. Bricks custom code

2. Do I want a clean site-wide setup without editing theme files too much?

   Choose:

   1. Bricks global custom code
   2. Possibly a code manager plugin

3. Do I want the most robust and scalable setup?

   Choose:

   1. Child theme
   2. Local files or controlled external loading
   3. wp_enqueue_script()

4. Do I only need animations on one or two pages?

   Choose:

   1. Bricks page-level custom code
   2. But still avoid loading GSAP multiple times

---

My practical recommendation for your course path

Because you are using WordPress + BricksBuilder and you want to learn both GSAP and later Glaze, I would suggest this sequence:

1. First stage: easiest setup

   1. Add GSAP via CDN
   2. Add your custom test animation in Bricks
   3. Confirm GSAP works

2. Second stage: cleaner structure

   1. Load GSAP globally only once
   2. Keep custom animations organized by page/template

3. Third stage: professional setup

   1. Use a child theme
   2. Enqueue GSAP and plugins properly
   3. Store custom animations in dedicated JS files

This is ideal because it matches your learning curve:

1. Understand the tool
2. Use it comfortably
3. Structure it professionally

---

Final takeaway

The “best” way to add GSAP to WordPress depends on your current level and project complexity.

In short:

1. CDN is best for fast learning and testing
2. Bricks custom code is best for convenience
3. Child theme + enqueueing is best for long-term professional use
4. Plugins are useful when you want convenience without editing theme files
5. A hybrid setup is often the most practical real-world solution