Checking your site for legacy jQuery dependencies

Checking your site for legacy jQuery dependencies is an important maintenance step before removing jQuery Migrate, replacing bundled JavaScript, modernizing a theme or changing how WordPress loads frontend assets.

WordPress still includes jQuery, and many themes and plugins still legitimately depend on it.

The problem is not:

jQuery exists
=
site is outdated

The real question is:

Which scripts depend on jQuery?

Do they need modern jQuery?

Do they need jQuery Migrate?

Are they using deprecated APIs?

Can anything be removed safely?

This distinction matters because a WordPress site can work perfectly with jQuery while containing no meaningful legacy problem at all.

It can also appear perfectly functional only because jquery-migrate is silently providing compatibility for old JavaScript that should have been updated years ago.

This guide explains how WordPress currently registers jQuery, what jQuery Migrate does, how to inspect script dependencies, how to identify legacy code in themes and plugins, how to use browser DevTools and WordPress APIs during an audit, how to test removals safely, and when keeping jQuery is the correct decision.

What does “legacy jQuery dependency” mean?

There are several different things people describe as a legacy jQuery dependency.

They should not be treated as identical.

A script simply depends on jQuery

For example:

wp_enqueue_script(
    'my-slider',
    get_theme_file_uri(
        '/assets/js/slider.js'
    ),
    array( 'jquery' ),
    '1.0.0',
    array(
        'in_footer' => true,
    )
);

This is not automatically legacy.

The script may use current jQuery APIs correctly.

A script depends on deprecated jQuery APIs

For example, old code might rely on methods or behaviors removed or deprecated in newer versions of jQuery.

That is a genuine modernization concern.

A script only works because jQuery Migrate is present

This is a stronger legacy signal.

The dependency looks roughly like:

old JavaScript
↓
uses outdated jQuery behavior
↓
modern jQuery alone is insufficient
↓
jQuery Migrate restores compatibility
↓
feature continues working

Removing Migrate can expose the underlying problem immediately.

A theme or plugin loads its own old jQuery copy

This can create another category of problem:

WordPress jQuery
+
theme jQuery
+
CDN jQuery

Multiple copies can create unnecessary page weight, version conflicts and unpredictable plugin behavior.

WordPress still registers jQuery

Current WordPress Core registers several related handles through its default script registry.

The official wp_default_scripts() source currently registers:

jquery
jquery-core
jquery-migrate

The current relationship is conceptually:

jquery
├── jquery-core
└── jquery-migrate

In the current Core registry, the jquery handle depends on both jquery-core and jquery-migrate.

Current WordPress jQuery versions

At the time of writing, current WordPress Core registers:

jQuery:
3.7.1

jQuery Migrate:
3.4.1

These versions are visible directly in the current wp_default_scripts() implementation.

This is why old tutorials describing much earlier jQuery or Migrate versions should not be treated as documentation of current WordPress behavior.

What is jQuery Migrate?

jQuery Migrate is a compatibility layer designed to help older jQuery code continue working with newer jQuery versions.

Conceptually:

legacy jQuery code
↓
modern jQuery
↓
deprecated or removed behavior
↓
jQuery Migrate compatibility
↓
code may continue working

This makes Migrate useful during transitions.

It also means its presence can conceal technical debt.

jQuery Migrate is not the same as jQuery

This distinction is fundamental.

A script might require:

jquery-core

or more commonly:

jquery

without actually relying on deprecated APIs.

Therefore:

depends on jQuery
≠
depends on legacy jQuery behavior

Do not attempt to eliminate every jQuery dependency merely because the library has existed for a long time.

Why WordPress sites accumulate old jQuery dependencies

WordPress installations can remain in production for many years.

During that time they may accumulate:

• old themes;
• child-theme scripts;
• page builders;
• slider plugins;
• gallery libraries;
• checkout customizations;
• form plugins;
• navigation scripts;
• custom agency code;
• code snippets copied from old tutorials.

A mature site can therefore contain JavaScript written across several different generations of frontend development.

A working site can still contain legacy code

This is one of the most important points in the audit.

You might see:

homepage works
navigation works
forms work
checkout works
console looks mostly quiet

and conclude:

no legacy dependency

But the actual architecture could be:

legacy plugin code
↓
deprecated jQuery API
↓
jquery-migrate
↓
compatibility restored
↓
frontend appears normal

The absence of a visible failure is not proof that the compatibility layer is unnecessary.

Start by identifying whether jQuery loads at all

Open a representative frontend page in browser DevTools.

Under the Network panel, filter for:

jquery

On a typical WordPress page using the Core-registered dependency, you may see resources resembling:

/wp-includes/js/jquery/jquery.min.js

/wp-includes/js/jquery/jquery-migrate.min.js

If neither file loads, the page may not currently require WordPress’s standard jQuery dependency.

If both load, continue investigating why.

Do not inspect only the homepage

JavaScript dependencies can be conditional.

A homepage may not use jQuery while:

• a contact page does;
• checkout does;
• My Account does;
• a gallery page does;
• a legacy widget does;
• an individual post does.

Audit representative templates.

A useful set might include:

Homepage
Blog post
Archive
Contact page
Landing page
Login/account page
Cart
Checkout
Product page
Any custom interactive page

Understand the WordPress dependency system first

WordPress scripts are normally registered and enqueued through the dependency-aware asset system.

For the broader architecture, see wp_enqueue_scripts Explained.

A script can declare jQuery as a dependency:

wp_enqueue_script(
    'legacy-gallery',
    get_theme_file_uri(
        '/assets/js/gallery.js'
    ),
    array( 'jquery' ),
    '2.4.0',
    array(
        'in_footer' => true,
    )
);

WordPress then knows:

jquery
must load before
legacy-gallery

Dependency declarations are valuable evidence

Search your theme and custom plugins for:

array( 'jquery' )

and variations such as:

'jquery',
"jquery"

inside:

wp_enqueue_script()
wp_register_script()

These declarations tell you which scripts explicitly ask WordPress for jQuery.

Search for jquery-core and jquery-migrate too

Also search for handles such as:

jquery-core
jquery-migrate

A component explicitly requesting jquery-migrate deserves closer attention because it is intentionally depending on the compatibility layer.

Do not search only PHP

Legacy usage can appear in:

• PHP enqueue declarations;
• JavaScript source files;
• bundled vendor files;
• inline scripts;
• page-builder output;
• custom HTML blocks;
• theme options;
• database-stored scripts.

A source-code search is useful, but it is not the whole audit.

Search JavaScript for obvious jQuery usage

Typical patterns include:

jQuery(
$(

jQuery(document).ready(
$(document).ready(

jQuery.ajax(
$.ajax(

jQuery.fn.
$.fn.

Finding these patterns proves jQuery is being used.

It does not prove the code is outdated.

Look for old document-ready patterns

For example:

jQuery(document).ready(function($) {
    // Code.
});

is old-fashioned but not automatically broken.

A shorter equivalent might be:

jQuery(function($) {
    // Code.
});

Changing syntax merely because it looks old is not modernization by itself.

The important question is whether the code uses APIs that modern jQuery no longer supports directly.

jQuery Migrate warnings are especially useful

One of the most useful signs of legacy code is a warning generated by jQuery Migrate.

Browser console output can identify deprecated patterns that are still being used.

A typical warning can look conceptually like:

JQMIGRATE:
jQuery.fn.someMethod() is deprecated

The exact warning depends on the API involved.

Open the browser console on every important interaction

Do not simply load the page and stare at the Console for five seconds.

Interact with it.

Test:

• navigation menus;
• dropdowns;
• accordions;
• modals;
• tabs;
• carousels;
• forms;
• filters;
• quantity controls;
• checkout;
• account pages;
• AJAX actions.

Legacy code may execute only when a particular feature is activated.

Record the script associated with each warning

A warning without ownership information is only half a diagnosis.

Try to identify whether the code belongs to:

WordPress Core
theme
child theme
plugin
custom plugin
inline code
third-party library

This transforms:

deprecated jQuery exists somewhere

into:

plugin X
assets/js/frontend.js
line Y
uses deprecated API

That is actionable.

Use source maps where available

Minified files can make debugging painful.

If a plugin or theme provides source maps, DevTools may map:

frontend.min.js

back to:

src/components/menu.js

This can make ownership and remediation much easier to understand.

Pretty-print minified JavaScript when necessary

If no source map exists, browser DevTools can still pretty-print minified JavaScript.

This does not restore original variable names or architecture, but it can make the relevant deprecated call easier to locate.

Inspect the WordPress registered script graph

WordPress exposes its script registry through:

wp_scripts()

The registry contains information about:

• registered handles;
• dependencies;
• queued scripts;
• sources;
• versions;
• load state.

The dependency graph is often more useful than simply inspecting generated HTML.

Use wp_script_is() for targeted checks

WordPress provides:

wp_script_is()

The official wp_script_is() documentation allows you to check statuses including:

enqueued
registered
queue
to_do
done

For example:

if (
    wp_script_is(
        'jquery',
        'enqueued'
    )
) {
    // jQuery is queued.
}

You can check jQuery Migrate too

For debugging:

if (
    wp_script_is(
        'jquery-migrate',
        'registered'
    )
) {
    // Migrate is registered.
}

Be careful interpreting the result.

Registered does not mean:

browser definitely downloaded it

It only means WordPress knows about the handle.

Queued and registered are different states

This distinction is important during asset audits.

registered
→ available in dependency registry

enqueued
→ requested for this page

done
→ already processed/output

Do not conclude that a page loads every script merely because it exists in the registry.

Inspect dependencies programmatically

On a development or staging installation, you can inspect a script’s registered dependencies.

For example:

add_action(
    'wp_print_footer_scripts',
    function () {

        $scripts = wp_scripts();

        if (
            isset(
                $scripts->registered[
                    'my-script'
                ]
            )
        ) {
            error_log(
                print_r(
                    $scripts
                        ->registered[
                            'my-script'
                        ]
                        ->deps,
                    true
                )
            );
        }
    }
);

This can reveal:

Array
(
    [0] => jquery
)

Do not leave diagnostic logging like this enabled indefinitely in production.

Build a list of scripts that directly depend on jQuery

For a more complete audit, iterate through the registered scripts on staging.

add_action(
    'wp_print_footer_scripts',
    function () {

        $scripts = wp_scripts();

        foreach (
            $scripts->registered
            as $handle => $script
        ) {
            if (
                in_array(
                    'jquery',
                    $script->deps,
                    true
                )
            ) {
                error_log(
                    'jQuery dependency: '
                    . $handle
                );
            }
        }
    }
);

This identifies scripts whose declared dependency list directly contains:

jquery

Direct dependencies are not the whole graph

Imagine:

app
↓
slider-library
↓
jquery

The app script may not directly declare jQuery.

It still indirectly requires it because one of its dependencies does.

When investigating a large site, think in dependency chains rather than isolated handles.

WordPress already resolves these chains

This is one of the main reasons to use wp_register_script() and wp_enqueue_script() correctly.

The official wp_register_script() documentation confirms that declared dependencies are loaded before the dependent script.

The browser may therefore receive:

jquery
↓
plugin-library
↓
plugin-app

even though only the intermediate library explicitly references jQuery.

Check the Network initiator and request order

Browser DevTools can help identify when jQuery is loaded and what other scripts appear around it.

Useful information includes:

• request URL;
• initiator;
• transfer size;
• cache status;
• execution order;
• whether duplicate copies exist.

Search page source for duplicate jQuery copies

A common legacy pattern is:

/wp-includes/js/jquery/jquery.min.js

https://cdn.example.com/jquery-1.12.4.min.js

/theme/assets/jquery.min.js

That is a much stronger concern than WordPress loading its normal registered jQuery dependency.

Why duplicate jQuery copies are risky

Multiple versions can create:

• different plugin instances;
• different available APIs;
• event-handler confusion;
• plugin initialization against the wrong instance;
• larger payloads;
• harder debugging.

For the general asset architecture, see CDN vs. Self-Hosted Assets in WordPress.

Search for manual jQuery script tags

Look through themes and custom plugins for patterns such as:

<script
    src="https://code.jquery.com/..."
></script>

or PHP output containing:

jquery.min.js

Shared libraries should generally participate in WordPress’s dependency system rather than being manually injected without coordination.

Do not replace WordPress jQuery casually

Old optimization tutorials sometimes deregister Core jQuery and replace it with a public CDN copy.

For example, you may encounter:

wp_deregister_script( 'jquery' );

wp_register_script(
    'jquery',
    'https://cdn.example.com/jquery.js'
);

This is a high-impact change because other WordPress components may depend on the registered handle and expect WordPress’s supported version and dependency structure.

Do not do this merely to save an imagined network request.

Inspect jQuery UI dependencies too

WordPress also registers jQuery UI components.

Current Core contains handles including:

jquery-ui-core
jquery-ui-accordion
jquery-ui-autocomplete
jquery-ui-datepicker
jquery-ui-dialog
jquery-ui-draggable
jquery-ui-droppable
jquery-ui-menu
jquery-ui-sortable
jquery-ui-tabs

and others.

Many of these ultimately depend on jQuery.

If a site uses an old admin or frontend widget built around jQuery UI, removing jQuery can have much wider consequences than expected.

Legacy jQuery and legacy jQuery UI are related but different audits

A component may use perfectly valid modern jQuery but depend on an old jQuery UI integration.

Or the opposite.

Record the exact dependency instead of labelling everything:

old jQuery stuff

Search themes for deprecated patterns

Custom and older themes deserve particular attention.

Search:

/wp-content/themes/active-theme/

and the child theme for JavaScript related to:

• navigation;
• sticky headers;
• sliders;
• lightboxes;
• tabs;
• accordions;
• scroll effects;
• AJAX forms.

A redesign is an especially good time to remove confirmed obsolete frontend dependencies, as discussed in broader plugin and site cleanup workflows.

Search custom plugins before third-party plugins

If your organization owns custom code, that code is usually the easiest place to remediate deprecated usage properly.

You can:

1. identify the old API;
2. replace it;
3. test the behavior;
4. remove the compatibility requirement.

For third-party plugins, the better solution may be updating or replacing the plugin rather than editing its files directly.

Do not edit vendor plugin JavaScript directly

Modifying:

/wp-content/plugins/plugin-name/assets/js/frontend.js

may appear to fix a warning.

The next plugin update can overwrite the modification.

Instead:

• update the plugin;
• report the issue upstream;
• replace the extension if abandoned;
• apply a maintainable integration-level workaround only when necessary.

Plugin age alone does not prove a jQuery problem

A plugin may be ten years old as a product but actively maintained with current frontend code.

Another plugin released recently can include an abandoned JavaScript library copied from somewhere much older.

Inspect behavior and code rather than guessing from the copyright year.

Audit inactive plugins too when planning cleanup

An inactive plugin does not normally enqueue frontend scripts.

But if you are deciding whether it can be removed permanently, check whether:

• its functionality was replaced;
• its shortcodes remain in content;
• its blocks remain in posts;
• another custom component assumes it will return.

For a broader cleanup methodology, see the site’s plugin-audit and consolidation workflow rather than deleting components purely because they contain jQuery.

What happened during the WordPress jQuery transition?

The WordPress project went through a staged jQuery modernization process around WordPress 5.5 through 5.7.

Part of that transition involved temporarily exposing compatibility issues so themes and plugins could update old JavaScript.

This historical context explains why so many WordPress tutorials discuss:

jQuery Migrate
WordPress 5.5
WordPress 5.6
WordPress 5.7

but those articles should not be mistaken for a description of today’s exact Core registry.

Current Core again includes jQuery Migrate in the jquery handle

The important present-day fact is what WordPress registers now.

Current wp_default_scripts() defines:

jquery
→ jquery-core
→ jquery-migrate

with the jquery handle depending on both components.

Therefore you should audit the current installation rather than following historical assumptions such as:

WordPress no longer loads Migrate by default

without checking the current Core implementation.

Do not use an old compatibility plugin as permanent architecture

Tools designed to help diagnose jQuery transition problems can be useful temporarily.

They should not become a substitute for updating the component that causes the compatibility warning.

The correct long-term architecture is:

find deprecated dependency
↓
identify owner
↓
update or replace code
↓
test
↓
reduce compatibility dependency

not:

old code breaks
↓
install more compatibility forever
↓
forget why it exists

Test removal only on staging first

Suppose you believe the frontend no longer needs jQuery Migrate.

Do not immediately remove it from production and congratulate yourself on saving a small JavaScript request.

Use staging.

For the general workflow, see WordPress Staging Site Best Practices.

A temporary Migrate-removal test

On a staging installation, developers sometimes modify the dependencies of the registered jquery handle to test whether the site still works without Migrate.

A common diagnostic pattern is:

add_action(
    'wp_default_scripts',
    function ( $scripts ) {

        if ( is_admin() ) {
            return;
        }

        if (
            isset(
                $scripts
                    ->registered[
                        'jquery'
                    ]
            )
        ) {
            $jquery =
                $scripts
                    ->registered[
                        'jquery'
                    ];

            $jquery->deps =
                array_diff(
                    $jquery->deps,
                    array(
                        'jquery-migrate',
                    )
                );
        }
    }
);

This should be treated as an intentional compatibility test, not a magical production optimization snippet.

Why test only the frontend first?

WordPress administration screens can have their own JavaScript dependencies.

An aggressive global change can affect:

• the editor;
• media dialogs;
• plugin settings;
• widgets;
• administrative workflows.

Changing frontend dependencies and changing wp-admin dependencies are separate decisions.

After removing Migrate, test every important workflow

At minimum, test:

• main navigation;
• mobile menu;
• search;
• forms;
• modals;
• accordions;
• tabs;
• carousels;
• filters;
• AJAX pagination;
• cookie or consent interfaces;
• login;
• registration;
• WooCommerce cart;
• checkout;
• My Account;
• payment integrations;
• custom application features.

Watch the console during the test

The most obvious failure is:

feature stops working

But also watch for JavaScript exceptions such as:

TypeError
ReferenceError
... is not a function

A component may partially initialize while leaving subtle functionality broken.

Test logged-in and logged-out states

The frontend can differ depending on whether the visitor is authenticated.

Examples include:

• admin bar scripts;
• editing controls;
• account widgets;
• personalized features;
• cache behavior.

Use both:

normal authenticated browser
+
private logged-out browser

Test mobile independently

Many legacy jQuery dependencies exist specifically for:

• mobile navigation;
• touch sliders;
• off-canvas menus;
• responsive tabs;
• mobile checkout behavior.

Desktop testing alone is not enough.

Check the page builder editor too

If the site uses a visual page builder, test:

• frontend rendering;
• builder editing;
• preview;
• responsive controls;
• custom widgets.

A builder may load completely different JavaScript when editing.

Check WooCommerce separately

Commerce sites deserve deeper testing because JavaScript failures can affect transactions.

Verify:

product variations
quantity changes
add to cart
mini cart
cart updates
coupon
checkout fields
payment methods
order submission
My Account

A 20 KB optimization is not impressive if customers can no longer select a payment method.

jQuery may be conditionally loaded by one plugin

Suppose the homepage is completely modern but:

contact page
↓
old form plugin
↓
jquery dependency

In that case, removing jQuery globally is the wrong optimization.

The better question is whether:

• the form plugin can be updated;
• the form plugin can be replaced;
• jQuery can remain conditional to that page.

Conditional loading is often more valuable than global removal

Instead of pursuing:

zero jQuery everywhere

you may achieve a better architecture with:

Pages requiring jQuery
→ load it

Pages not requiring jQuery
→ do not enqueue dependents

WordPress’s dependency-aware asset system makes this possible when themes and plugins register their scripts correctly.

Do not dequeue jQuery if dependents remain

This is a classic optimization mistake.

Suppose:

plugin-slider
depends on
jquery

and you run:

wp_dequeue_script( 'jquery' );

You have not modernized:

plugin-slider

You have only removed something it declared that it needs.

The result may be broken execution or WordPress resolving the dependency again through another queued script.

Check dependents before dequeuing shared libraries

This principle applies far beyond jQuery.

As noted in wp_enqueue_scripts Explained, shared assets should not be dequeued without checking their dependency graph.

Do not use performance scores as the only reason to remove jQuery

A performance scanner may tell you:

Reduce unused JavaScript

and identify jQuery.

That is useful evidence.

It does not prove jQuery can be removed safely.

You still need to know:

Who requested it?
What depends on it?
Which pages need it?
What breaks without it?

Measure actual frontend impact

Use browser DevTools or a performance profiler to determine:

• transferred bytes;
• compressed size;
• parse and execution cost;
• cache behavior;
• pages on which the dependency appears.

For the wider performance context, see Reducing WordPress Front-End Page Weight.

Removing Migrate usually saves less than replacing a giant plugin

Do not lose perspective.

A site might contain:

jquery-migrate
+
3 MB hero image
+
700 KB slider bundle
+
400 KB unused page-builder CSS
+
multiple third-party trackers

Removing Migrate while ignoring the much larger resources is technically tidy but may have little practical performance effect.

Legacy dependencies are primarily a maintainability issue

The most important reason to identify old jQuery code is often not file size.

It is that legacy code can become:

• harder to update;
• more likely to break with future library changes;
• more difficult to debug;
• dependent on compatibility layers;
• tied to abandoned plugins.

Think of the audit as technical debt reduction first and byte counting second.

Replace small jQuery utilities with native JavaScript where practical

For custom code, modern browser APIs can replace many simple jQuery tasks.

For example:

jQuery('.menu-toggle')
    .on('click', function() {
        jQuery('.menu')
            .toggleClass('open');
    });

can be implemented using native JavaScript:

const toggle =
    document.querySelector(
        '.menu-toggle'
    );

const menu =
    document.querySelector(
        '.menu'
    );

if (toggle && menu) {
    toggle.addEventListener(
        'click',
        () => {
            menu.classList.toggle(
                'open'
            );
        }
    );
}

That does not mean every jQuery component should be rewritten immediately.

Rewrite based on value, not ideology

If a mature component:

• works correctly;
• uses supported APIs;
• has no Migrate warnings;
• is maintained;
• has negligible performance impact;

rewriting it purely to remove the word jQuery from the dependency list may create more risk than value.

Prioritize actual legacy problems

A sensible order is:

1. Broken deprecated code
2. Abandoned plugins
3. jQuery Migrate warnings
4. Duplicate jQuery copies
5. Unnecessary global loading
6. Simple custom code worth modernizing
7. Healthy maintained jQuery code

The last category may require no action at all.

Watch for jQuery noConflict behavior

WordPress uses jQuery in no-conflict mode.

This means bare:

$

is not automatically guaranteed as a global jQuery alias in every context.

A common WordPress-safe wrapper is:

jQuery(function($) {

    $('.menu').addClass(
        'ready'
    );

});

If code assumes $ globally without the correct scope, the problem may be improper WordPress integration rather than an outdated jQuery API.

Do not “fix” noConflict by loading another jQuery copy

This unfortunate pattern sometimes appears:

$ is undefined
↓
developer loads CDN jQuery
↓
$ now exists
↓
site has two jQuery copies

The correct solution is normally to scope the existing WordPress jQuery dependency properly.

Search for old vendor libraries bundled with themes

Legacy themes often contain directories such as:

/js/vendor/
/assets/vendor/
/libs/
/vendor/js/

Inspect libraries for:

• old sliders;
• old lightboxes;
• old jQuery plugins;
• old validation libraries;
• old masonry-style packages;
• deprecated touch plugins.

A modern theme can still carry a library copied forward from several redesigns ago because nobody remembered why it existed.

Check whether the feature itself is still used

Before updating an old dependency, ask:

Does the website still need this feature?

If an abandoned jQuery slider is loaded for a slider that no longer exists, the correct fix may simply be:

remove old enqueue
+
remove old code

rather than modernizing an unused library.

Map each dependency to a visible feature

Create an audit table such as:

HANDLE
legacy-carousel

OWNER
old theme

DEPENDENCY
jquery

FEATURE
homepage testimonials

MIGRATE WARNING
yes

STILL USED
yes

ACTION
replace carousel

This gives the dependency a business and interface context.

Unknown JavaScript should not be deleted blindly

A script whose purpose is unclear may support:

• conversion tracking;
• checkout validation;
• accessibility behavior;
• forms;
• analytics;
• consent management;
• navigation.

Identify ownership and behavior first.

Review plugin updates before custom remediation

If an active plugin generates Migrate warnings, first check whether a newer release has already corrected them.

Keeping WordPress plugins current is part of reducing compatibility debt.

See The Risks of Not Updating WordPress Plugins.

Do not update directly on production just to fix warnings

A plugin update can alter:

• markup;
• JavaScript;
• database structures;
• checkout behavior;
• forms;
• editor features.

Use a staging-first workflow for meaningful compatibility changes. See Building a Staging-First WordPress Update Workflow.

Review theme updates too

A legacy dependency may come from the active theme rather than a plugin.

Check:

• parent theme version;
• child-theme overrides;
• custom scripts;
• old template copies;
• manually bundled vendor libraries.

A child theme can preserve outdated JavaScript indefinitely

Updating the parent theme does not automatically update:

child-theme/assets/js/custom.js

that your agency created eight years ago.

Custom code needs its own maintenance lifecycle.

Check optimization plugins during the audit

Performance tools may:

• combine scripts;
• delay scripts;
• defer execution;
• rewrite URLs;
• change order;
• remove Migrate;
• exclude selected assets.

These transformations can make dependency problems appear or disappear depending on configuration.

Disable optimization temporarily when debugging order problems

If the console reports:

jQuery is not defined

after enabling script delay or reordering, first determine whether the original dependency declaration is correct.

The issue may be:

dependency graph correct
+
optimizer changed execution order

rather than:

theme forgot jQuery dependency

defer and async can expose dependency mistakes

WordPress supports script-loading strategies for appropriate resources.

If:

app.js
depends on
jquery

the application should declare that dependency rather than relying on incidental HTML order.

See wp_enqueue_scripts Explained for modern dependency-aware loading.

Do not use hook priority as a fake dependency system

A fragile implementation might do:

priority 10
→ jQuery

priority 20
→ plugin

priority 30
→ app

Instead, scripts should declare:

jquery
↓
plugin
↓
app

through dependency arrays where possible.

Legacy inline scripts are easy to miss

Search rendered HTML for:

<script>
    jQuery(...)
</script>

Inline JavaScript may originate from:

• theme settings;
• page-builder widgets;
• custom fields;
• plugins;
• tracking tools;
• template PHP.

Removing external jQuery while leaving inline dependents will still break the page.

Inspect database-stored custom code when relevant

Some builders and code-management plugins store JavaScript in the database rather than normal files.

A filesystem search can therefore return:

zero jQuery references

while the generated page contains several.

Rendered-output inspection remains necessary.

Use coverage tools carefully

Browser JavaScript Coverage can help identify how much of a file executes during a specific page session.

But:

unused during one test
≠
unused everywhere

A checkout function may appear unused until a user changes payment method.

A menu function may appear unused until the viewport becomes narrow.

Use real user flows instead of synthetic page loads alone

A good legacy-dependency audit is workflow-based.

For example:

Visit homepage
↓
open navigation
↓
open modal
↓
submit form
↓
browse product
↓
change variation
↓
add to cart
↓
checkout
↓
account login

This exercises code that a simple page-load benchmark never reaches.

When is it safe to remove jQuery Migrate?

You need evidence.

A reasonable confidence level includes:

• no meaningful Migrate warnings;
• no known plugin requirement;
• critical interactions tested;
• custom scripts reviewed;
• theme behavior verified;
• WooCommerce tested where applicable;
• frontend console remains clean;
• staging functions correctly without it.

When should you keep jQuery Migrate?

Keep it when a required component still needs it and replacing or updating that component cannot yet be completed safely.

That is not ideal technical debt, but it can be the correct operational decision.

The key is to document:

what depends on it
why it remains
what should eventually replace it

Compatibility is more important than cosmetic optimization

A site with one additional compatibility script that works reliably is better than a theoretically cleaner site with:

• broken menus;
• broken checkout;
• broken forms;
• broken admin tools.

Optimize after understanding dependencies.

When is it safe to remove jQuery itself?

This is a much larger decision than removing Migrate.

You need to confirm that no relevant script depends directly or indirectly on:

jquery

on the surfaces where you intend to remove it.

If even one required script still depends on jQuery, the library remains part of that dependency graph.

You do not need to remove jQuery from all of WordPress

A common goal is simply:

do not load jQuery
on pages that do not need it

That is much more realistic than trying to eliminate it from every:

• frontend page;
• admin screen;
• editor workflow;
• plugin integration.

Modernization can be gradual

A practical migration might look like:

Phase 1
Find duplicate jQuery

Phase 2
Fix Migrate warnings

Phase 3
Replace abandoned jQuery plugins

Phase 4
Rewrite small custom scripts

Phase 5
Make loading conditional

Phase 6
Test pages without jQuery

Phase 7
Remove where genuinely unused

This is safer than a site-wide dequeue experiment performed five minutes before launch.

Check again after major WordPress updates

Core dependencies and bundled library versions can change over time.

Do not assume today’s:

jQuery version
Migrate version
jQuery UI version
dependency structure

will remain permanently identical.

Always inspect the current WordPress release when making version-sensitive changes.

Check again after plugin and theme updates

An update can:

• remove an old jQuery dependency;
• introduce a new one;
• replace a bundled library;
• change enqueue handles;
• change execution order.

JavaScript dependency auditing is not necessarily a once-in-a-site-lifetime exercise.

Document the final asset architecture

After cleanup, record important shared dependencies.

For example:

jQuery
→ required by WooCommerce component X

jQuery Migrate
→ no longer required on frontend

legacy slider
→ removed

custom navigation
→ native JavaScript

GSAP
→ selected landing pages only

This makes future maintenance dramatically easier.

A practical legacy jQuery audit workflow

1. Create or refresh a staging copy.
2. List representative frontend templates.
3. Open DevTools Network panel.
4. Check whether jQuery loads.
5. Check whether jQuery Migrate loads.
6. Look for duplicate jQuery copies.
7. Inspect the Console for Migrate warnings.
8. Interact with every major interface component.
9. Search theme PHP for jQuery dependency declarations.
10. Search custom plugins for jQuery dependency declarations.
11. Search JavaScript files for jQuery usage.
12. Search for direct jquery-migrate dependencies.
13. Check inline JavaScript.
14. Check builder or database-stored custom scripts.
15. Map each dependency to its owner.
16. Map each dependency to the feature it supports.
17. Update maintained themes and plugins where appropriate.
18. Replace abandoned components where practical.
19. Fix owned custom code using deprecated APIs.
20. Test the frontend without Migrate where justified.
21. Test mobile.
22. Test logged-out state.
23. Test authenticated state.
24. Test WooCommerce separately where applicable.
25. Test forms and AJAX behavior.
26. Review browser console again.
27. Measure actual asset savings.
28. Remove confirmed unused dependencies.
29. Document dependencies that remain.

Legacy jQuery dependency checklist

• Confirm the current WordPress jQuery version.
• Confirm the current WordPress jQuery Migrate version.
• Understand that the jquery handle currently depends on jquery-core and jquery-migrate.
• Do not assume historical WordPress 5.5 behavior describes current Core.
• Inspect the Network panel for jQuery resources.
• Inspect more than the homepage.
• Check posts, archives and landing pages.
• Check forms.
• Check account pages.
• Check WooCommerce pages where relevant.
• Check mobile interactions.
• Look for multiple jQuery versions.
• Search for manually embedded jQuery files.
• Search theme enqueue declarations.
• Search plugin enqueue declarations.
• Search for jquery-migrate.
• Search JavaScript for jQuery and $ usage.
• Remember that ordinary jQuery usage is not automatically legacy.
• Look specifically for deprecated APIs and Migrate warnings.
• Identify the owner of every warning.
• Use source maps where available.
• Review custom code separately from vendor code.
• Do not edit third-party plugin files directly.
• Update maintained plugins before creating workarounds.
• Replace abandoned dependencies where practical.
• Check jQuery UI dependencies too.
• Use wp_script_is() for targeted debugging.
• Inspect wp_scripts() on staging when deeper dependency information is needed.
• Understand registered versus enqueued state.
• Check indirect dependency chains.
• Do not dequeue jQuery while dependents remain.
• Do not replace WordPress’s registered jQuery casually.
• Do not load another jQuery copy merely to restore $.
• Respect WordPress’s no-conflict usage.
• Check script optimization and delay plugins.
• Check defer and async interactions.
• Declare dependencies instead of relying on incidental script order.
• Test Migrate removal on staging first.
• Test every major interaction after removal.
• Watch for subtle console errors.
• Keep Migrate temporarily if a business-critical component still requires it.
• Document why compatibility layers remain.
• Prioritize maintainability over tiny performance claims.
• Measure actual page-weight impact.
• Modernize custom JavaScript gradually.
• Do not rewrite healthy code merely to eliminate jQuery as a badge of modernity.
• Reaudit after significant plugin, theme or WordPress changes.

Related guides

• wp_enqueue_scripts Explained
• Reducing WordPress Front-End Page Weight
• CDN vs. Self-Hosted Assets in WordPress
• The Risks of Not Updating WordPress Plugins
• Building a Staging-First WordPress Update Workflow
• WordPress Staging Site Best Practices

Final recommendation

Do not begin a legacy jQuery audit by removing jQuery.

Begin by understanding the dependency graph.

Current WordPress Core still registers:

jquery
↓
jquery-core
+
jquery-migrate

and many legitimate WordPress components still depend on jQuery.

The useful goal is therefore not:

jQuery exists
→ delete it

but:

identify
↓
trace
↓
test
↓
modernize
↓
remove only what is genuinely unnecessary

Start with the strongest warning signs:

• jQuery Migrate console warnings;
• duplicate jQuery versions;
• plugins explicitly dependent on obsolete behavior;
• abandoned frontend libraries;
• custom code using deprecated APIs;
• jQuery being loaded globally for one isolated feature.

Then resolve each dependency according to its owner.

Update maintained third-party components.

Replace abandoned ones.

Modernize custom code you control.

Keep jQuery where a healthy, maintained dependency still requires it.

Finally, test removals on staging across real workflows rather than trusting a homepage performance scan.

A clean JavaScript architecture is not defined by having zero jQuery.

It is defined by knowing exactly why every dependency exists, loading it only where it is required and no longer relying unknowingly on compatibility code from another era.