3.3 Different ways to add GSAP to a WordPress site

WhenIf workingyou want to use GSAP in WordPress—especially together with WordPressBricksBuilder—there are several valid ways to include it. Which one is “best” depends on how comfortable you are with code, how reusable your setup should be, and BricksBuilderhow much control you want. 🎯

This topic is important because many animation problems are not caused by GSAP itself, but by how it was loaded, therewhen isit nobecomes singleavailable, corrector waywhere toyour addcustom GSAP.code runs.

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 ⚙️

Thefour main goal is always the same:

Load GSAP coreapproaches correctly Load any GSAP plugins you need Load your own animation code Make sure the loading order is reliable 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. Addadding GSAP via a CDN directly in the page or template
2. Addadding GSAP byglobally hostingvia theWordPress files locallyenqueueing
3. Addadding GSAP through youra code snippets/plugin-based workflow

bundling GSAP in a custom theme or child theme workflow

For a WordPress + BricksBuilder user, you do not need to master all of them immediately. But you should understand the pros and cons of each, because later—when your projects grow—you may want to switch from a quick setup to a cleaner, more scalable one.

---

before we compare the methods: what does “adding GSAP” actually mean?

When you “add GSAP” to a website, you usually need to load:

the core GSAP library Addoptionally one or more plugins, such as:

ScrollTrigger ScrollToPlugin TextPlugin others depending on your needs your own custom animation code, which uses GSAP

A simple mental model is:

first the browser loads GSAP then it loads any GSAP directlyplugins insidethen BricksBuilderit customloads your own script that says what should animate

If this order is wrong, your code areasmay fail.

For example, this will only work if GSAP has already been loaded:

gsap.to(".box", {
  x: 200,
  duration: 1
});

And this will only work if both GSAP and ScrollTrigger are already loaded and registered:

gsap.registerPlugin(ScrollTrigger);

gsap.to(".box", {
  scrollTrigger: ".box",
  y: 100,
  duration: 1
});

So whenever we discuss “ways to add GSAP,” we are really discussing:

where the files come from Addwhere GSAPthey usingare ainserted into WordPress pluginin what order they are loaded whether they are loaded on one page or codethe managementwhole toolsite how easy it is to maintain later

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

---

1.method Adding1: adding GSAP via CDN directly in a page, template, or code block

This is usually the fastest way to get started. 🚀

A CDN (Content Delivery Network) is onea ofhosted URL from which the fastestbrowser andloads easiesta waysJavaScript to start.file. Instead of storing GSAP files ininside your WordPress installation,theme, you loadlink themto it from an external URL.source.

Howhow itthis works

You includeplace a <script> tag thatsomewhere pointsin toyour thesite GSAP file hosted elsewhere,output, for example:

<script

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

If you need

in a custom code area in Bricks in the page/template footer in a header/footer injection plugin suchin asa ScrollTrigger,custom youHTML/code alsoelement load that after GSAP core:

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 your own animation script comes after both:

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

Why beginners like this method

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

Advantages

Very easy to start

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

No file management

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

Good for testing

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

Convenient in Bricks

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

Disadvantages

External dependency

Your site relies on another server to deliver the script.

Less control

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

Can become messy

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

Potential policy issues

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

Best use cases

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

Important loading order

If using CDN, alwaysalso load in this order:

GSAP core Plugins Your custom script

For example:that:

<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(to(".hero-title"box", {
    scrollTrigger: ".box",
    y: 60,
    opacity: 0,100,
    duration: 1
  });
  });
</script>

---

where

2.you Hostingmight GSAPdo locallythis on yourin 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 worksBricks

InsteadPossible ofplaces linking to an external CDN URL, you load a file from your own site, such as:include:

<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. Bricks Fullpage controlsettings overor files

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

No reliance on third-party delivery

Everything comes from your own site.

Cleaner long-term setup

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

Better for structured development

You can organize scripts, versions, andtemplate-level custom code more cleanly.

Disadvantages

Slightly more setup work

You need to upload files and reference them correctly.

a

RequiresCode basicelement filein organization

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

Bricks

Version updates are manual

If you want a newerplugin GSAPthat version,allows youheader/footer must replace the files yourself.

Best use cases

Production websitesscripts Projectstheme options or site settings that need better maintainability Client sites where you want stable, controlled asset loading More advanced setups with multipleallow custom scripts

Recommendedwhy approachbeginners often like this method

IfBecause it is:

quick visual easy to test ideal for learning

You can create a section in Bricks, give it a class like .box, paste in a script, and immediately see something move.

advantages

very easy to start

no theme file editing required no enqueue function needed minimal WordPress knowledge needed

good for experiments

useful when learning GSAP basics useful when building a one-off prototype useful when testing a small effect on a single page

page-specific loading

you can load GSAP only where needed this can be helpful if only one landing page uses animation

disadvantages

harder to maintain

scripts may end up scattered across pages, templates, and code blocks later you may forget where a certain animation was added

dependency/order issues

if your custom script runs before GSAP is loaded, it breaks if ScrollTrigger is loaded after your code, it breaks

not ideal for larger projects

many pages with animation become messy updating versions across many pages becomes annoying

possible duplication

you might accidentally load GSAP multiple times that can lead to confusion or performance issues

when to use it

Use this method if:

you are seriousjust aboutlearning usingyou want to test a small animation quickly you are building a simple one-page effect you are not yet ready to work with theme files or enqueue functions

when not to use it

Avoid relying on this as your long-term default if:

your site has many animated pages you want a clean, scalable setup you work on client projects that need easier maintenance you want centralized control over scripts

practical recommendation

For a beginner in BricksBuilder, this is an excellent sandbox method. Learn here first. But do not assume it is always the best production architecture.

---

method 2: adding GSAP regularly,properly via WordPress enqueueing

This is the WordPress-native way, and in many cases the best long-term solution ✅

WordPress has a built-in system for loading CSS and JavaScript files called enqueueing. Instead of manually printing <script> tags wherever you want, you tell WordPress which scripts to load, and WordPress handles output and ordering more cleanly.

why enqueueing matters

When scripts are enqueued properly, WordPress can better manage:

dependencies load order footer vs header loading conditional loading conflicts with themes/plugins

This makes your setup more robust.

a basic example

You would typically add this to your theme’s functions.php file, or better, to a child theme:

function mytheme_enqueue_gsap() {
    wp_enqueue_script(
        'gsap',
        'https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js',
        array(),
        '3.12.5',
        true
    );

    wp_enqueue_script(
        'gsap-scrolltrigger',
        'https://cdn.jsdelivr.net/npm/gsap@3/dist/ScrollTrigger.min.js',
        array('gsap'),
        '3.12.5',
        true
    );

    wp_enqueue_script(
        'my-gsap-animations',
        get_stylesheet_directory_uri() . '/js/animations.js',
        array('gsap', 'gsap-scrolltrigger'),
        '1.0',
        true
    );
}
add_action('wp_enqueue_scripts', 'mytheme_enqueue_gsap');

Your custom animation code would then live in a separate file, for example /js/animations.js:

gsap.registerPlugin(ScrollTrigger);

gsap.to(".box", {
  scrollTrigger: ".box",
  y: 100,
  duration: 1
});

what this code means

Let’s unpack it carefully:

wp_enqueue_script(...)

tells WordPress to load a JavaScript file

'gsap'

this is the script handle WordPress uses it as an internal name

'https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js'

this is the file URL

array()

this means GSAP core has no dependency in this setup

'3.12.5'

this is the version string useful for cache-busting and clarity

true

load in the footer generally good for performance and safer for DOM-related code

For ScrollTrigger, this line matters a lot:

array('gsap')

That tells WordPress:

“Load ScrollTrigger only after gsap has loaded.”

And here:

array('gsap', 'gsap-scrolltrigger')

you tell WordPress:

“Load my animation file only after both GSAP core and ScrollTrigger are available.”

That is one of the bestbiggest long-termadvantages methodsof ✅enqueueing.

---

advantages

3.

Adding

cleaner structure

GSAP throughloading ais themecentralized oryour childanimation themelogic lives in its own file

Thisbetter dependency management

WordPress handles load order fewer “gsap is not reallydefined” separateerrors from local hosting—it

more scalable

better for larger sites better for reusable workflows better for client projects

easier maintenance

update a version in one place update one JS file instead of many inline snippets

closer to professional practice

this is more the way many developers structure scripts in WordPress

disadvantages

WordPress-nativerequires waysome PHP

even if only a little this may feel intimidating at first

slower to doset itup properly.initially

Instead

ofcompared to just pasting script tags somewhere,into a page

you useneed WordPressfile functions to enqueue scripts.

Why enqueuing matters

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

1. Dependencieschild theme
2. Loadingtheme ordereditor
3. FooterSFTP loadingor hosting file manager
4. Versioninga code snippets workflow that supports this logic

when to use it

This is ideal if:

you want a solid long-term setup Conflictyou preventionanimate across multiple pages you want your code to stay organized you are ready to learn a little WordPress development structure

important best practice: use a child theme

If you place code directly in a parent theme and later update the theme, your changes may be overwritten. 😬

So if you are editing functions.php, it is usually safer to do so in a child theme.

conditional loading

A very useful improvement is to load GSAP only on pages that actually need it.

Example:

function mytheme_enqueue_gsap() {
    if (!is_page('landing-page')) {
        return;
    }

    wp_enqueue_script(
        'gsap',
        'https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js',
        array(),
        '3.12.5',
        true
    );

    wp_enqueue_script(
        'my-gsap-animations',
        get_stylesheet_directory_uri() . '/js/landing-page-animations.js',
        array('gsap'),
        '1.0',
        true
    );
}
add_action('wp_enqueue_scripts', 'mytheme_enqueue_gsap');

This means:

if the current page is not landing-page, stop immediately otherwise, load GSAP and your animation file

This is thecleaner professionalthan wayloading toeverything loadsite-wide scripts.when only one page needs it.

Example using

method functions.php

3: adding GSAP through a code snippets plugin or script management plugin

HereThis is a cleankind exampleof middle ground between “quick and easy” and “properly structured.” ⚖️

Instead of editing theme files manually, you use a plugin that lets you insert PHP, JavaScript, or site-wide scripts in a managed interface.

Examples of plugin categories:

Code Snippets plugins Header/Footer script plugins asset/script manager plugins some advanced custom code manager plugins

how this works

There are two main variations:

you insert raw <script> tags globally you add PHP that uses wp_enqueue_script()

The second is generally better if the plugin supports PHP snippets safely.

example: enqueueing GSAP through a snippets plugin

function mysite_enqueue_gsap() {
    wp_enqueue_script(
        'gsap',
        'https://cdn.jsdelivr.net/npm/gsap@3/dist/gsap.min.js',
        array(),
        '3.12.5',
        true
    );

    wp_enqueue_script(
        'gsap-scrolltrigger',
        'https://cdn.jsdelivr.net/npm/gsap@3/dist/ScrollTrigger.min.js',
        array('gsap'),
        '3.12.5',
        true
    );
}
add_action('wp_enqueue_scripts', 'mysite_enqueue_gsap');

Then you might place your custom JS:

in a separate JS file in a page-level code area in another snippet/plugin field depending on the plugin

why this is attractive

For many WordPress users, especially non-developers, this is easier because:

no theme file editing is required your custom code survives theme updates plugin interfaces can be less intimidating than file editing

advantages

safer than editing parent theme files

theme updates are less risky

often easier for non-developers

no SFTP required no direct file management required

can still be fairly organized

especially if the plugin supports named snippets you can label snippets clearly

good transition step

excellent if you are learning WordPress development concepts gradually

disadvantages

depends on another plugin

more plugin dependency plugin settings differ from tool to tool

can still become messy

if you store too many unrelated scripts in too many snippets

sometimes less transparent

another developer may need to search plugins to find your script setup

not always ideal for larger development workflows

especially if you later move toward version-controlled theme/project files

when to use it

This is a strong option if:

you don’t want to edit theme files yet you want something more maintainable than random page-level script tags you are comfortable managing code in a plugin interface you want a relatively safe setup on client sites

a very practical beginner-friendly approach

A nice compromise can be:

enqueue GSAP and plugins globally or conditionally via a snippets plugin keep small page-specific animation code inside Bricks where it is used move larger animation code into separate JS files later

That way, your library loading is centralized, but your small experiments remain easy to work with.

---

method 4: bundling GSAP in a custom theme or child theme workflow

This is the most “developer-style” approach and often the cleanest for serious projects 🛠️

Instead of relying on CDN links everywhere, you may keep your scripts in your project structure and load them through your theme or build process.

what this can mean

This can range from relatively simple to quite advanced:

storing your own custom JS files inside the theme enqueueing local copies of GSAP files using a build tool or bundler organizing animations into modules/files

For your current level, you probably do not need the advanced version yet. But it is good to understand the direction.

local file example

Suppose you store GSAP files inside your child theme:

/js/vendor/gsap.min.js /js/vendor/ScrollTrigger.min.js /js/animations.js

Then enqueue them:

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

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

    wp_enqueue_script(
        'custom-gsap-my-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'mytheme_enqueue_local_gsap');

WhyCDN thisvs local file: what is powerfulthe difference?

NoticeWith thea dependency arrays:CDN:

1. array()files forare GSAPloaded corefrom an external server
2. array('gsap')

for

With ScrollTriggerlocal files:

1. array('gsap',files 'gsap-scrolltrigger')are forserved from your own scriptsite/theme

Neither is automatically “always better.” It depends on priorities.

CDN advantages

quick to set up easy to update URL versions no need to manage local vendor files manually

local file advantages

more project control less dependence on third-party external URLs easier to version together with the project files often preferable in structured development workflows

disadvantages of a custom theme workflow

more setup complexity requires more confidence with file structure may involve build tooling later can feel like overkill for small sites

when to use it

Use this if:

you build custom WordPress sites regularly you want a reusable professional workflow you manage code in a structured way you may later adopt Git/version control and more advanced JS organization

---

method 5: loading GSAP only where Bricks needs it

This tellsis WordPress:not a totally separate technical method, but rather an important strategy for WordPress + BricksBuilder projects.

A common beginner mistake is:

1. load GSAP firsteverywhere
2. thenput loadall ScrollTriggeranimation logic in one giant script
3. thentarget loadmany yourclasses custom animation file

So WordPress handles the order for you.

Advantages

Most professional WordPress methodglobally Reliablelose dependencytrack handlingof Cleanerwhat thanaffects random script tags Scales well on larger projects Works well with child themeswhat

Disadvantages

A

better Requires access to theme files Needs some PHP comfort Slightly harder for complete beginners

Best use cases

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

Important note for Bricks users

If you use BricksBuilder, this methodapproach 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:often:

1. Pageload settingsthe customlibrary codeglobally or conditionally
2. Template-levelkeep customanimation code grouped by template/page/component
3. Site-wideuse customconsistent code

classes Headerand or footer script areas 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:

Add the GSAP CDN script globally Add plugin scripts globally Add your custom animation JS in Bricks custom code or in a code elementnaming

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. one

   VeryJS convenient

   You can manage code from inside the builder interface.

No need to edit theme files

This lowers the technical barrier significantly.

Greatfile for page-specific animations

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

Fast iteration

You can tweak and test quickly while designing the page.

Disadvantages

Can become disorganized

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

Dependency management is manual

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

Less ideal for large codebases

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

Risk of duplication

You may accidentally load GSAP multiple times in different places.

Best use cases

Learning and experimenting inside Bricks Small to medium projects Page-specifichero animations Usersone whoJS preferfile builder-basedfor workflowsscroll over theme development

Practical recommendation

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

Load GSAP and plugins globallysections Addone smallJS page-specificfile animationfor codereusable wherecomponents neededlike sliders/cards Moveor largerone reusablemain animationfile logicwith intoclearly aseparated dedicated script latersections

This givesbecomes youespecially simplicityuseful in Bricks because Bricks encourages visual building, and roomwithout structure your JS can become hard to growmap 📌back to the layout.

---

5. Adding GSAP with a pluginrealistic orcomparison code manager

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

This might be:

A header/footer code injection plugin A custom code manager plugin A performance/plugin asset manager that supports script loading 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:

Site-wide header Site-wide footer Specific pages Specific post types Conditional locations

Advantages

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

Disadvantages

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

Best use cases

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

Important warning

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

GSAP in the plugin GSAP again in Bricks GSAP again in the theme

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

---

Comparingof the methods

Here is the practical differencecomparison betweenin theplain common approaches:language:

1. CDN onlydirectly in page/template

   Best

   for
2. best speed,for: learning, andtesting, quicksmall testsone-off effects

weakest point: maintenance becomes messy

LocalWordPress filesenqueueing +in theme/child theme enqueue

Best

forbest professional,for: maintainablelong-term projectsclean setup weakest point: requires some PHP confidence

Brickscode customsnippets/plugin-based codeloading

Best for convenience and builder-centered workflows

1. best

   Codefor: injectionusers plugin

   Best when youwho want simplicitystructure without editing theme files

weakest point: still plugin-dependent and can become messy if overused

Hybridcustom approachtheme/local asset workflow

Often

the best real-worldfor: solutionadvanced or growing professional projects weakest point: more setup complexity

AIf goodI hybridwere setupadvising mightsomeone look like this:

Load GSAP globally through thewith childlimited themeJS/CSS skills orbut Brickswho global custom code Load plugins globally only if widely used Put page-specific animation logic where it is easiestwants to managelearn Moveproperly, 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 recommendsuggest this progression:

1. Startstart with page-level CDN + Bricks custom codeloading

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

   basics
2. then

   Movemove to globalsnippet/plugin-based loadingenqueueing

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

3. then

   learn Graduate to child theme enqueueing

later, if needed, adopt a more structured local/bundled workflow

That learning path keeps your cognitive load manageable. 🧠

---

important technical details you should understand regardless of method

No matter which loading method you choose, a few concepts always matter.

1. load order

Your custom GSAP code must run after GSAP is available.

AsBad order:

your animation code runs GSAP loads afterward

Result: error such as gsap is not defined

Good order:

GSAP core loads GSAP plugin loads your custom animation code runs

---

2. plugin registration

Some GSAP plugins should be registered before use:

gsap.registerPlugin(ScrollTrigger);

If you forget this, your projectsscroll-based becomeanimations moremay advanced,not movework correctly.

---

3. DOM readiness

Even if GSAP is loaded correctly, the elements you want to aanimate cleanermust WordPress-nativealso setup.exist when your code runs.

For example, this may fail if .box is not yet in the DOM at execution time:

gsap.to(".box", {
  x: 200
});

A safer beginner pattern is:

document.addEventListener("DOMContentLoaded", function () {
  gsap.to(".box", {
    x: 200,
    duration: 1
  });
});

This says:

wait until the HTML document has loaded then run the animation code

This progressionis letsespecially useful in WordPress because page builders, templates, and dynamic content can make script timing less obvious.

---

4. page builders can change markup

With BricksBuilder, what you learnsee withoutvisually is tied to generated HTML. If you later change:

a class name a nested structure a template assignment

your GSAP selector may stop matching.

So this selector:

gsap.to(".hero-title", {
  y: 50
});

only works if an element with class .hero-title still exists on the front end.

That is why consistent class naming is very important.

---

5. avoid loading the same library multiple times

This is a surprisingly common issue.

For example:

GSAP loaded in a header/footer plugin GSAP loaded again in Bricks custom code GSAP loaded a third time in functions.php

This can create debugging confusion. Even if it does not always break visibly, it is bad practice.

Try to keep a clear answer to the question:

“Where exactly is GSAP being loaded on this site?”

If you cannot answer that in one sentence, your setup may already be getting blocked by technical setup too early 🎯messy.

---

Recommendedrecommended setups byfor experiencedifferent levelskill levels

if

you

Absoluteare an absolute beginner

Use:

1. CDN for+ GSAPpage-level script
2. maybe inside a Bricks code block or page custom code for your animation scriptsarea

Why:

1. Fastestfastest setupfeedback loop
2. Easiesteasiest tofor understandlearning syntax
3. Minimalminimal technicalsetup frictioncomplexity

But

keep

Beginnerit limited to intermediateexperiments.

---

if you are a beginner who wants a cleaner real-site setup

Use:

1. Globala Code Snippets-style plugin to enqueue GSAP loading in Bricks
2. Page-levela or template-levelseparate custom JS file if possible

small page-specific code only where needed

Why:

1. Cleanersafer than pastingediting scriptstheme everywherefiles too early
2. Stillmore easymaintainable tothan managescattered inline scripts
3. Goodgood balancestepping ofstone simplicitytoward andproper structuredevelopment practice

---

if

Intermediateyou andare beyond

building more serious projects

Use:

1. Childchild theme enqueueing
2. Proper wp_enqueue_script()

External customseparate JS files conditional loading where sensible clear naming conventions for Bricks elements

Why:

1. Bettercleaner architecture
2. Bettereasier reusemaintenance
3. Betterbetter long-termscalability

maintenance

---

recommended setup specifically for WordPress + BricksBuilder learners

For your situation, I would recommend the following staged approach:

phase 1: learn GSAP with the simplest possible setup

load GSAP via CDN paste small scripts into a controlled test page in Bricks animate simple classes like .box, .title, .button

phase 2: centralize library loading

move GSAP loading into a snippet/plugin-based global setup stop loading the library individually on every test page

phase 3: separate your animation logic

move your custom animations into a JS file keep the file organized by section or component use comments to mark each animation area

phase 4: move to child theme enqueueing when you feel ready

this gives you a more professional workflow especially useful for client work or bigger sites

---

What “correct loading order” really means

This sequence is oneeffective because it respects the idea that learning has a kind of the“cost mostfunction” important concepts in GSAP setup.😊

If yourwe scriptthink runsof beforesetup GSAPdifficulty as $D$ and learning benefit as $B$, then for beginners you want a method where the ratio $\frac{B}{D}$ is available,as youhigh willas getpossible. errorsEarly like:

on,

gsapsimple issetups notoften definedgive 

better

Ifreturns; yourlater, plugincleaner runsarchitecture beforebecomes GSAPmore core, the plugin may fail.

The correct dependency chain is:

GSAP core Any GSAP plugins Plugin registration Your animation code 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.valuable.

---

Aa simple decision frameworkguide

If you are unsure which pathmethod to choose, use this checklist:rule of thumb:

1. Do I just want to test GSAP quickly?

   Choose:
2. CDN

Bricks custom code

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

Choose:

Bricks global custom code Possibly a code manager plugin

Do I want the most robust and scalable setup?

Choose:

Child theme Local files or controlled external loading wp_enqueue_script()

Do I only need animations on one or two pages?

Choose:

Bricks page-level custom code 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:

First stage: easiest setuptoday

1. Add GSAP viause CDN

Add your custom test animation in Bricks Confirm GSAP works

Second stage: cleaner structure

Load GSAP globally only once Keep custom animations organized bythe page/template

ThirdI stage:want professionala safer no-theme-edit workflow

use a snippets/plugin approach

I want a clean long-term WordPress setup

1. Use ause child theme enqueueing

Enqueue GSAP

I andbuild plugins properly

Storestructured custom animationsprojects in

dedicateduse JSa filescustom theme/local asset workflow

This

---

is

common idealmistakes becauseto it matches your learning curve:avoid

1. Understandputting GSAP code before the toollibrary is loaded
2. Useforgetting itto comfortablyload or register plugins like ScrollTrigger
3. Structureanimating itselectors professionallythat do not exist on the front end

loading GSAP multiple times from different places storing too much important logic in scattered inline scripts editing a parent theme directly not checking whether scripts should load globally or only on specific pages

---

Finalmy takeawaypractical recommendation in one sentence

TheFor “best”learning, waystart towith addCDN GSAP+ tosimple WordPress depends on your current page-level and project complexity.

In short:

CDNcode is best; for fastreal learningprojects, andmove testingas soon as possible toward Brickscentralized customloading codevia issnippets bestor for convenience Child child-theme + enqueueing. is✅ best for long-term professional use Plugins are useful when you want convenience without editing theme files A hybrid setup is often the most practical real-world solution