This site ran on a theme that loaded jQuery for two things: a mobile menu toggle and a scroll handler. Not posts, not forms, not e-commerce — two event handlers. The dependency cost more than the features it powered.
The fix was not “rip out jQuery.” It was a script diet with a whitelist: the deployment keeps a marker comment on every script the site intentionally serves, and anything without a marker gets stripped at render. jQuery had no marker. It stopped shipping. The mobile menu and scroll handler got rewritten as vanilla JS in a dedicated snippet, the markers went on, and the theme’s JS fell out of the waterfall entirely.
The honest numbers
From the measurement log in the repo (local Lighthouse, pre/post on the same routes):
- Total Blocking Time: 44ms → 0ms
- LCP: −120ms
- Local Lighthouse score: 81 → 82
- Theme JS in the waterfall: zero
The LCP drop is the more interesting one. LCP on these pages is image-bound, not script-bound — the −120ms came not from removing jQuery’s execution but from removing the parse/compile time it cost before first paint. Every millisecond of the main thread is a millisecond LCP waits behind.
One honesty note on the numbers: these are local Lighthouse runs, not Chrome UX Report field data. PageSpeed Insights against the live site stayed quota-blocked on the public API the whole session — the local numbers are real but they are lab numbers, and the field picture is still unverified.
What “nothing broke” actually means
“Nothing broke” is a claim that needs evidence, not vibes. The verification after the diet:
- Mobile menu opens and closes on a real mobile viewport
- Scroll handler still fires (header shrink on scroll)
- Console-clean across all 193 routes — zero errors, zero warnings from the removed script
- Accessibility audit re-run — the menu still meets the a11y checks it passed before
- Forms still submit (the newsletter interim cards and contact flows don’t depend on jQuery — they never did, which is why this was safe to cut)
The things that could have broken and did not: sticky-header behavior, smooth-scroll anchors, the mobile-nav focus trap. The things that could not have broken: anything on the server, which never touched jQuery in the first place.
Why this was safe to do on production
The same reason the rest of this week’s changes were safe: backup, dry-run, verify. The script diet ran as a snippet — deactivating it restores the theme’s original scripts instantly. The whitelist markers mean the change is surgical: jQuery dropped, everything else untouched. No theme files edited, no child theme, no fork.
The lesson is not “jQuery bad.” It is “audit what your theme loads for the two features you actually use, and ask if the dependency earns its bytes.” Here, it did not.
Keep reading
Agree, disagree, or caught something off? The comment form is below — I read all of them.
