Ahead of quoting rebuild work on older client sites, we have started running a short audit of exactly which jQuery plugins a site actually depends on versus which were added for a single feature years ago and never removed once that feature quietly disappeared from the design, a pattern that turns out to be far more common than any of us expected before we started actually measuring it.
On one recent audit, a client's site was loading six separate jQuery plugins totaling over 200kb, but only two were tied to anything currently visible on the live site. The rest were dead weight, kept alive only because nobody had felt confident enough to remove them without breaking something, which is a completely understandable instinct on any site with no clear record of which plugin does what and no test coverage to reassure a developer that removing one is safe.
How the audit process actually works
We check each loaded plugin against the site's current DOM and JavaScript for any active usage, using both automated tooling that flags unused code and manual verification by actually exercising every visible feature on the site to confirm nothing quietly depends on a plugin the automated check might have missed. This combination catches both the easy cases — a plugin with zero references anywhere in the current codebase — and the harder cases where a plugin is technically referenced somewhere but the corresponding feature has been visually hidden or disabled without the underlying dependency ever being cleaned up.
This audit has become a standard early step before any rebuild quote, since it changes the actual scope of the work — sometimes significantly — and gives the client a clear, evidence-based list of what needs a real replacement versus what can simply be dropped. Clients have generally responded well to seeing this concrete evidence rather than taking our word for it that certain functionality is safe to leave behind, and more than one client has been surprised to learn how much of their site's page weight was coming from features they did not realize still technically existed on the page.
What we actually recommend once a plugin is confirmed load-bearing
Finding a plugin still genuinely in active use does not automatically mean keeping it as-is — we also check whether the same functionality now has a reasonable vanilla JavaScript or framework-native replacement that would remove a jQuery dependency entirely from an otherwise jQuery-free rebuild. A carousel plugin, for instance, is functionality most modern frameworks or even a small amount of native CSS and JavaScript can now reproduce without pulling in jQuery at all, so "still in use" is the start of the audit's real question rather than the end of it.
How we present the findings to a client who is not technical
Clients are not always in a position to evaluate a list of plugin names on their own merits, so we translate the audit into a short before-and-after comparison instead: current page weight and load time against a projected page weight and load time once dead plugins are removed and live ones are either kept or replaced. Framing it around a number the client already cares about — how fast their own site feels to their own visitors — has made these conversations noticeably easier than presenting a technical inventory and asking a non-technical stakeholder to judge its significance unassisted.
A pattern we now watch for beyond just jQuery plugins
The same "added once, never removed once the feature vanished" pattern shows up in analytics snippets, unused web fonts, and abandoned A/B testing scripts just as often as it does in jQuery plugins, so the audit checklist we built for this specific purpose has quietly grown into a broader pre-rebuild dependency audit covering anything loaded on the page regardless of what kind of asset it happens to be.