Remove jQuery and other legacy libraries

What the library costs

These sizes are measured from the files in the packages published on npm, which we downloaded on 30 October 2026. "Unpacked" is the minified file as the browser sees it after decompression. The compressed sizes were made with gzip at its highest level and Brotli at quality 11, so a real server that compresses less aggressively sends a little more.

The download is the smaller part of the cost. The browser also parses, compiles and runs the file. Where it is loaded matters too: a copy in the head without defer blocks the page. See defer, async and modules.

Keep this in proportion. In the 2025 Web Almanac the median mobile home page loaded 632 KB of JavaScript, so jQuery on its own is a few percent of a typical page. The reason to look at it is what comes with it: the plugins that depend on it, the code you have written on top of it, and the old habits it represents. On a page that is struggling with Total Blocking Time, the whole stack counts.

Find out whether you use it

• Ask the page. In the browser console, window.jQuery?.fn.jquery prints the version if jQuery is present. Lighthouse also has a diagnostic called Detected JavaScript libraries, which lists the front-end libraries found on the page. It does not count towards the score.
• Look in the Network panel. Filter for jquery. Note whether jquery-migrate is loaded as well.
• Use the Coverage tool. It shows how much of the file ran during your recording. See unused code.
• On WordPress, remember the dependency system. WordPress core registers a script handle named jquery that depends on two files: jQuery itself (version 3.7.1 in current core) and jQuery Migrate 3.6.0, a compatibility layer for older code. Any theme or plugin script that lists jquery as a dependency makes WordPress load both on that page. Your total on such a page is about 107 KB unpacked and 37 KB with gzip, using the numbers above. To find the plugin responsible, switch plugins off one at a time on a test copy of the site and watch whether the jQuery files disappear from the Network panel.

Native replacements

For simple uses, the browser already has an equivalent. This table is a starting point, not a complete list.

For example, a small menu script with jQuery:

$('.menu-button').on('click', function () {
  $('.menu').toggleClass('open');
  $.get('/api/menu-state', function (data) { console.log(data); });
});

and the same without it:

document.querySelector('.menu-button').addEventListener('click', () => {
  document.querySelector('.menu').classList.toggle('open');
  fetch('/api/menu-state').then((r) => r.json()).then(console.log);
});

Browser support is not a concern for these. Element.closest() works since Chrome 41, Firefox 35 and Safari 6. classList has worked in Chrome since version 22, Firefox since 3.6 and Safari since 7. fetch() works since Chrome 42, Edge 14, Firefox 39 and Safari 10.1, and Element.animate() since Chrome 36, Firefox 48 and Safari 13.1.

A safe plan

1. List the uses. Search your code and the page for $( and jQuery. Make a list of what it does, and which plugin each use comes from.
2. Remove what nobody needs. Plugins and widgets that no longer matter are the cheapest savings.
3. Try the slim build. The jQuery README says it releases a slim version that excludes the ajax, callbacks, deferred, effects and queue modules. If your code uses none of them, the file shrinks by about a fifth to a little over a quarter of its unpacked size, as the table shows.
4. Replace your own code first, then the plugins. Rewrite small scripts with native code, one at a time, on a test copy, and test each one. For third-party plugins, look for a version or an alternative that does not need jQuery. If you cannot replace a plugin, keep jQuery and load it only on the pages where the plugin runs.
5. Load what is left late. Add defer, and do not load it where it is not needed.
6. Measure. Compare Total Blocking Time and the main-thread work before and after. See where main-thread time goes.

On WordPress, take extra care. The bundled jQuery Migrate exists to keep older code working, so removing it can break plugins that still rely on old behavior, and swapping the bundled jQuery for another version can do the same. Test every page type, including the checkout and the forms, before you change either.

Other legacy code to look for

• Polyfills and old syntax transforms. The Lighthouse Legacy JavaScript insight flags them. See bundle size and code splitting.
• Several libraries doing the same job. Two slider scripts, two lightbox scripts or two animation libraries on one page.
• Libraries loaded for one feature. A whole toolkit for one small effect.
• Full icon fonts. One font for hundreds of icons when the page uses a handful. Inline SVG avoids it. See web fonts.
• Scripts that nobody remembers adding. The Detected JavaScript libraries list and the Network panel will show them.

What not to do

• Rewrite everything for a 25 KB saving. The saving is real but modest. Start with the biggest items in the report.
• Remove jQuery while something still needs it. The page will break in a way that may not show on the first page you test.
• Replace the bundled version on WordPress without testing. See above.

Check your own page

Run the free audit and look at the list of JavaScript files and Reduce unused JavaScript. If jQuery and several plugins are among the largest files, work through the plan above. If the audit shows only a small amount of script, spend your time on something else.

Sources

• The jQuery 4.0.0 README, in the package published on npm: the slim build and the modules it excludes. The file sizes in this guide are measured from the 4.0.0 and 3.7.1 packages and jQuery Migrate 3.6.0.
• WordPress core script loader: how the jquery handle is registered.
• Detected JavaScript libraries on Chrome for Developers.
• Element.closest(), Element.animate() and fetch() on MDN, with their compatibility tables.
• Page Weight chapter, Web Almanac 2025: the median amount of JavaScript.