Strip Unused CSS Per Template and Minify WordPress CSS, JS, and HTML

Open a product page. View source. Half the stylesheet still describes the blog layout, the homepage hero, and a contact form that is not on this URL. Then the same page ships unminified CSS and JS because “we will tidy that later.” Later never comes. LCP and INP pay for it every visit.

Unused CSS and fat assets are not exotic problems. They are the default WordPress stack: page builders, theme kits, and plugins that enqueue everything globally. Minification alone helps. Removing CSS that never applies on a given template helps more.

Lightify is the DaftPlug performance plugin. This post is about remove unused CSS (stripped per template) plus minify CSS, JavaScript, and HTML. Defer or delay JavaScript sits nearby as supporting context, not the focus. Full-page cache and third-party self-hosting are other articles. If Core Web Vitals are still noisy after you clean assets, keep How to fix LCP, CLS, and INP on WordPress in 2026 open as the metrics checklist.

What Lightify actually ships for CSS stripping and minify

Feature list for this article only:

• Remove unused CSS: stripped per template (not one blunt global delete)
• Minify CSS, JavaScript, and HTML
• Nearby (mention, not focus): defer or delay JavaScript
• Conservative defaults; aggressive options stay toggleable when you want them

The contract is simple. Ship less CSS on each template. Ship smaller CSS, JS, and HTML. Start safe. Tighten when measurements say so.

Why global CSS enqueues punish every template

WordPress themes and builders often load one giant stylesheet everywhere. Homepage sections, WooCommerce blocks, form styles, slider CSS: all of it rides along on a thin landing page that needs almost none of it. The browser still downloads, parses, and may block render on rules that never match a selector on that URL.

Minification shrinks what you already send. Unused CSS removal changes what you send per template. That is why “minify everything” sites still fail lab and field tests: the unused rules were just smaller unused rules.

Real traffic makes the cost obvious:

1. Mobile visitors on mid-range phones spend CPU on CSSOM work they never use.
2. Page builders enqueue kit CSS on posts that never use the kit widgets.
3. HTML comments, whitespace, and verbose JS compound the transfer size after CSS is already heavy.
4. Aggressive “remove all unused CSS” tools that are not template-aware break cart drawers and sticky headers. Per-template stripping is the safer shape of the same idea.

Lightify’s defaults stay conservative so you do not discover a broken checkout from a weekend toggle. Aggressive opts exist when you are ready to test them.

How to set unused CSS and minify in wp-admin

Assume Lightify is installed. You do not need a child theme or a custom build pipeline for this pass.

1. Open Lightify asset / CSS optimization settings

In wp-admin, open Lightify. Find the controls for unused CSS and for minifying CSS, JavaScript, and HTML. You should see remove-unused-CSS (per template) and minify toggles, with room for defer/delay JS nearby if you tackle that next.

Note the conservative defaults. Leave aggressive options off until the safe path is verified on staging or a quiet hour on production.

2. Enable remove unused CSS (per template)

Turn on unused CSS removal so each template keeps the rules it needs and drops the rest. Hit the important shapes of your site after enabling:

• Homepage
• Single post / product
• Archive / shop
• Cart, checkout, account (if ecommerce)
• Any page-builder landing page you care about

Look for missing icons, broken mobile menus, vanished sticky bars, and unstyled form states. Those are the usual casualties when a rule was “unused” in a first paint snapshot but needed after interaction. Per-template stripping reduces that risk versus one global purge, but you still verify.

If a template breaks, dial back aggressiveness or exclude that view before you blame the whole feature. Conservative first is the point.

3. Enable minify for CSS, JavaScript, and HTML

Turn on minification for CSS, JS, and HTML once unused CSS is stable (or in parallel on staging). Minify is usually low drama: whitespace and comments go away, behaviour stays. Still spot-check:

1. Critical above-the-fold layout
2. Slider or accordion JS
3. Checkout and login forms
4. Admin-bar views if you test while logged in (logged-in vs logged-out assets often differ)

If a script relies on quirky formatting (rare, but plugins surprise you), minify JS last and isolate the offender rather than disabling all minify forever.

4. Treat defer / delay JavaScript as the next lever, not this post’s job

Defer or delay JS is adjacent and powerful for INP and main-thread quieting. Mention it here so you do not forget the lever. Do not flip every delay toggle in the same hour you first strip CSS. Change one class of optimisation, measure, then stack.

5. Measure before and after (lab + a real phone)

Run a lab test on a key URL before changes. Repeat after unused CSS + minify. Compare transfer size, CSS bytes, and LCP. Then check a real mid-range Android on cellular, not only a cable-connected laptop.

Pair the asset pass with the Core Web Vitals guide linked above when CLS or INP still move after CSS shrinks. Assets are one slice. Images, fonts, and long tasks are others.

6. Keep a rollback path

Know how to disable unused CSS or minify quickly if a campaign landing page breaks at 9am. Performance wins that strand checkout are not wins. Lightify’s toggleable aggressive opts exist so you can retreat without uninstalling the plugin.

What good looks like

A solid CSS and minify setup feels quiet:

• Product and post templates ship less CSS than the homepage kit dump.
• CSS, JS, and HTML responses are minified without visual regressions on key templates.
• Cart, checkout, and account still look correct after unused CSS.
• Conservative defaults stay on; aggressive opts only after a measured pass.
• Defer/delay JS, if used later, is a second change set with its own test plan.
• Lab and field numbers move in the same direction on mobile, not only on desktop Lighthouse.

If HTML and JS shrank but LCP barely moved, your bottleneck was probably a hero image, font, or TTFB, not selector bloat. Keep the minify win. Chase the real LCP culprit next.

Pitfalls (the ones that bite)

Stripping unused CSS and delaying all JS in one sitting. You will not know which change broke the menu.

Skipping ecommerce templates. Drawers and dynamic carts need CSS that static HTML snapshots miss.

Calling minify “done” while still enqueueing 400KB of unused CSS. Minify is not a substitute for removal.

Testing only logged-in. Admin bar and editor styles hide frontend reality.

Aggressive opts on production Friday evening. Use staging or a quiet window.

Ignoring the Vitals follow-up. Unused CSS fixes bytes. CLS and INP may still need the broader 2026 checklist.

Practical checklist before you call it done

1. Snapshot lab metrics on homepage, single, and checkout (if any).
2. Enable remove unused CSS per template under Lightify.
3. Spot-check menus, icons, drawers, and forms on mobile.
4. Enable minify for CSS, JavaScript, and HTML.
5. Re-test the same URLs; compare CSS bytes and LCP.
6. Leave defer/delay JS for a separate, measured pass.
7. Keep aggressive toggles off until the conservative path is clean.
8. Document how to disable unused CSS quickly if a landing page breaks.
9. Revisit Core Web Vitals with the linked guide if LCP/CLS/INP still miss targets.

Takeaway

WordPress feels slow when every template downloads CSS for every other template, then ships that CSS unminified for good measure. Fix the set of rules per template. Then shrink what remains.

Lightify removes unused CSS per template and minifies CSS, JS, and HTML, with conservative defaults and aggressive options you control. Defer or delay JavaScript when you are ready for the next pass.

One Pro membership unlocks Lightify plus Progressify, Generatify, Rankify, and Snapshotify. New Pro plugins join existing memberships. Plans differ by site count only. See pricing when you want smaller CSS on purpose, not by accident.

Strip per template. Minify what is left. Measure on a phone. That is the whole play.