jQuery has been part of WordPress since 2.1 in 2007. For most of those seventeen years, removing it was not a realistic option — too much of core, too many plugins, too many themes depended on it. That has slowly changed. WordPress 5.6 dropped the jQuery Migrate dependency from front-end output in late 2020. WordPress 6.5, which shipped in March, has further reduced core’s dependence on jQuery in the editor. The front end of a freshly-installed WordPress site no longer needs jQuery at all.
Most production sites still ship it. Most themes still depend on it. The result is that thousands of WordPress sites in 2024 are loading 90 kilobytes of compatibility shim for behavior that could be 6 kilobytes of vanilla JavaScript. This post is about whether to remove it, and how.
What removing jQuery actually saves
jQuery 3.7 is 87 kilobytes minified, 30 kilobytes gzipped. On most WordPress themes it is loaded eagerly in the head, blocking the initial render. The cost on Lighthouse mobile scores is typically 8 to 15 points on a marketing site.
For an INP-focused audit, jQuery’s cost is more interesting than its file size. jQuery’s event system wraps every native event with a normalization layer. The wrapping adds 0.5 to 2 milliseconds per event on a mid-range device. Multiply by every click, hover, and scroll handler on the page, and the cumulative cost is noticeable.
For LCP, the cost is mostly the blocking load. A theme that loads jQuery in the head, before the hero image, adds 100 to 300 milliseconds to the LCP on a slow connection.
The migration is harder than it looks
Most WordPress sites do not depend on jQuery directly. They depend on plugins and themes that depend on jQuery. A clean audit of the dependency tree is the first step.
The typical findings:
- The theme’s main JavaScript file uses jQuery for DOM queries, event binding, and AJAX requests. Replace with vanilla JavaScript: querySelectorAll, addEventListener, fetch.
- Contact Form 7 enqueues jQuery for its form validation. Either replace with a different form plugin, or accept that the contact page loads jQuery.
- WPBakery, Elementor, and other page builders have hard jQuery dependencies for their front-end runtime. Removing jQuery means removing the page builder.
- WooCommerce front-end uses jQuery for cart, checkout, and product variations. Removing jQuery from a WooCommerce site is not feasible in 2024.
- Older theme frameworks — Genesis, Underscores variants, _s — typically have a small jQuery usage in the main script. Easy to replace.
The audit script
We run a static audit before any de-jQuery project. The script scans the theme directory and the active plugins for:
- References to wp_enqueue_script(‘jquery’) as a dependency
- References to jQuery() or $() calls in JavaScript files
- References to jQuery() in inline scripts in PHP
- Cases where a plugin’s main JS file is enqueued with jquery as a dependency
The output is a punch list. For a typical WordPress site with 15 active plugins, the list runs to about 8-20 jQuery touchpoints. For each one, the question is: is this code mine, or is it in a third-party plugin? The mine ones get rewritten. The third-party ones get a decision — keep the plugin and accept jQuery, replace the plugin, or ask the plugin author for a jQuery-free version.
What the vanilla replacements look like
The patterns are straightforward.
jQuery: $(‘.menu’).addClass(‘open’). Vanilla: document.querySelector(‘.menu’).classList.add(‘open’).
jQuery: $(‘.btn’).on(‘click’, handler). Vanilla: document.querySelector(‘.btn’).addEventListener(‘click’, handler).
jQuery: $.ajax({url: ‘/api’, success: …}). Vanilla: fetch(‘/api’).then(r => r.json()).then(…).
jQuery: $(document).ready(handler). Vanilla: if document.readyState is not ‘loading’ run handler immediately, else add a DOMContentLoaded listener. Or just put the script at the bottom of body.
jQuery: $(‘.el’).animate({opacity: 0}). Vanilla: el.animate([{opacity:1},{opacity:0}], {duration:300}).
The animations are the only case where the vanilla replacement is not strictly cleaner. The Web Animations API exists in every modern browser but the syntax is more verbose than jQuery’s. For most cases, CSS transitions are the cleaner replacement.
The shim option
For projects where removing jQuery is genuinely infeasible but reducing its cost matters, the middle path is jQuery Slim (no AJAX, no effects) at 25 kilobytes gzipped instead of 30, or a deferred load of jQuery that does not block the initial render.
The deferred load is more interesting. jQuery does not need to be in the head. Most themes put it there because the WordPress default does. Move it to the bottom of body, mark it defer, and the blocking cost vanishes. The plugins that need jQuery still get it. The page renders first.
This is the lowest-effort, highest-impact change for most sites we audit. Three lines of functions.php. 80 to 200 milliseconds off LCP. It is one of the standard fixes in our performance audit checklist.
The full removal
For projects where the full removal is feasible — small content sites with a custom theme and a tight plugin list — the migration is worth doing. The performance gain is real. The code gets cleaner. The dependency surface shrinks.
The catch is that ‘small content site with a custom theme and a tight plugin list’ is a smaller fraction of the WordPress universe than the platform’s marketing suggests. Most production WordPress sites have grown a plugin ecosystem that is hard to untangle. For those, the deferred-load compromise is the realistic answer.
The 2025 horizon
WordPress core’s jQuery dependency continues to shrink. The block editor is jQuery-free. The new front-end scripting changes in 6.5 push more of core toward vanilla JS. By the end of 2024 we expect jQuery on the WordPress front end to be a plugin-and-theme concern only, not a core concern.
The plugin ecosystem will follow more slowly. Contact Form 7, WPBakery, and the older e-commerce plugins are not going to drop jQuery this year or next. For sites that want to be jQuery-free, those plugins are the actual blocker. The technical work is straightforward. The decision about which plugins to keep is the real project.