You do not need a performance consultant to find theme bloat — the browser already measured it. Chrome DevTools’ Coverage tab reports, per file, how many bytes shipped versus how many the page actually executed or applied. On the WordPress audits we run, this one tool usually ends the “is it the theme or the hosting?” argument in five minutes.
How to run it
- Open DevTools → Cmd/Ctrl+Shift+P → type “Show Coverage”.
- Click reload to start instrumented capture.
- Interact with the page briefly (scroll, open the menu), then stop.
- Sort by “Unused Bytes” — the theme’s files float to the top.
How to read the numbers
- CSS files above 60% unused — module styles for features your pages never render. Confirm against the module list in the cleanup guide, then disable modules.
- JS files above 80% unused — theme scripts running for widgets you never load, or libraries bundled “just in case”. These are candidates for conditional loading.
- One giant file flagged mostly unused — the multipurpose-theme signature: everything ships globally instead of per-template.
The traps
Test the right page set. Coverage is per page. Your homepage may use 30% of a stylesheet while product pages use 70%. Run it on your three most-visited templates and look at the union, not one page.
Disable caching for the audit. Aggressive caching can serve optimized bundles that mask the raw theme output — or serve stale minified files that no longer match source. Test against a cache-bypassed load first.
Interaction skews JS numbers. Clicking through a slider loads slider JS legitimately. Decide what “used” means for your site before declaring a file bloat.
What to do with the findings
- Module toggles first (free, reversible).
- Conditional loading for scripts only certain pages need — often a theme setting or a small filter.
- If the theme ships one monolithic stylesheet with no split options, that is an architecture signal — weigh it in the full diagnostic before deciding to stay.
A worked example
A professional-services site ran Coverage on its homepage: the theme’s main JS file shipped 190 KB, 74% unused — code for a page builder, two sliders, and a portfolio filter the site never used. Conditional-loading those three components (theme panel options) cut the file to 68 KB and improved LCP by 0.4s. The theme stayed; only its assumptions changed.
If Coverage output feels dense, the free audit translates it into a plain-language waste report. For context on where this fits among all speed levers, see the 2026 theme benchmarks.
Per-file bytes shipped versus bytes actually used (executed JS, applied CSS). Files with high unused ratios are bloat candidates on the current page. CSS above 60% unused and JS above 80% unused on your main templates are worth acting on. Check across your top pages, not just one. Caching plugins serve minified, combined bundles that mask raw theme output. Audit with cache bypassed to see what the theme actually ships. Not in theme files — updates overwrite them. Use module toggles, conditional loading options, or optimization plugins with per-page CSS handling.What does the Coverage tab in Chrome DevTools show?
What unused percentage should worry me?
Why did my Coverage results look better than expected?
Can I delete the unused CSS directly?
