Almost every caching plugin has a pair of checkboxes near the top of its settings: minify CSS and minify JavaScript. Speed reports list “minify” as a fix too, and it sounds like free speed. Sometimes it is. Sometimes you tick the boxes, the score barely moves, and a week later someone notices the booking calendar has stopped working.
Whether you should minify CSS and JavaScript on your site comes down to a simple trade: a usually small gain against a small but real chance of breaking something. On most WordPress sites the gain is smaller than the checkbox suggests, which is worth knowing before you decide how much testing it deserves.
What minification removes
Code is written for people. It has spaces, indents, line breaks and comments so that a developer can read it. The browser does not need any of that. Minification is the process of rewriting a file so it does exactly the same thing in fewer characters.
For CSS, a minifier typically:
- Strips comments, line breaks and most spaces.
- Removes the last semicolon in each rule, which is optional.
- Shortens values where it safely can, for example writing
#fffinstead of#ffffff, or dropping a zero before a decimal point.
For JavaScript, minifiers go further:
- They remove comments and whitespace.
- They rename local variables and function arguments to single letters, since those names are never seen outside the function.
- Some also remove code that can never run and simplify expressions.
The result is one long line that is unpleasant to read and does the same job. That is why files you get from plugins often end in .min.js or .min.css: the developer has already done it.
How much it actually helps
Honestly, less than most people expect, for two reasons.
First, much of the code on a typical WordPress page is already minified. WordPress core, WooCommerce and most well-maintained plugins ship minified files. Your minify setting has little left to do with those. The files that do gain are usually a theme’s own stylesheet, custom CSS added over the years, and older or smaller plugins that ship readable code.
Second, servers compress text files before sending them, using gzip or Brotli. Compression is very good at squeezing out repeated whitespace, so a lot of what minification removes would have been compressed away anyway. The two still stack, and minified files compress a little better, but the difference on the wire is smaller than the difference in file size on disk. How compression works and how to check it is on is covered in gzip versus Brotli compression.
So treat minification as tidying, not as a cure. If a page is slow, the reason is rarely that its CSS has comments in it.
Finding the files that would actually gain
You can check this yourself in a couple of minutes. In Chrome, open DevTools, go to the Network tab, filter by CSS, reload, and click each file. The Response view shows the file as it arrived. If you see neat indentation, comments and one property per line, that file is readable code and would shrink when minified. If you see a solid wall of text, it is already done.
Repeat for JavaScript. On many sites you will find only a handful of readable files, usually the theme, a child theme and one or two older plugins. That short list tells you how much there is to gain before you touch a setting, and it also tells you which files to look at first if something breaks afterwards.
Minify, combine, or both?
Older speed advice paired minification with combining: merge all your CSS into one file and all your JavaScript into another, so the browser makes fewer requests. Under HTTP/1.1 that made sense, because browsers could only fetch a few files at once from each server.
Most sites are now served over HTTP/2 or HTTP/3, which can carry many files over a single connection at the same time. Our post on HTTP/2 and HTTP/3 explains the change. With that, combining has lost most of its benefit and kept its downsides:
- Caching gets worse. When everything is in one file, changing one plugin’s CSS changes the whole bundle, and every returning visitor downloads all of it again.
- Bundles differ per page. If the home page and a blog post load different plugins, each gets a different combined file, so a visitor moving between pages downloads overlapping code twice.
- Breakage is harder to trace. An error in one combined file could come from any of twenty sources.
- Order problems. Combining can change the order scripts run in, which breaks code that depends on another file loading first.
A sensible default today: minify, but leave combining off unless you have tested both ways and combining clearly wins on your server.
How to minify CSS and JavaScript on WordPress
For most site owners, the option lives in the caching or optimisation plugin you already use. WP Rocket, LiteSpeed Cache, W3 Total Cache and Autoptimize all offer minification for CSS and JavaScript, with exclusion boxes for files that misbehave. If you are choosing between plugins anyway, matching a caching plugin to your server matters more than which one minifies best.
Whichever you use, switch things on in this order:
- Note your starting point: run PageSpeed Insights a few times on two or three key pages and open DevTools on the Network tab to see the transferred size of CSS and JS.
- Turn on CSS minification only. Clear all caches. Check the pages in a private window.
- Turn on JavaScript minification. Clear caches again. Check pages, and this time keep the browser console open.
- Leave HTML minification for last, if at all. It saves the least and occasionally breaks inline code.
- Compare the transferred sizes with your notes. If the change is tiny, you may decide the risk is not worth it.
If you have a developer who maintains a custom theme, a better option is for them to minify during their build process, so the theme ships minified files and the plugin has nothing to rewrite. That avoids the plugin doing the work on the fly and removes one moving part.
What can break, and how to spot it
Modern minifiers are reliable, so problems usually come from the edges:
- Scripts that depend on names. Rare, older code that refers to its own variable names as text can break when the minifier renames them.
- Files that are already minified. Running them through again gains nothing and, now and then, causes subtle errors. Most plugins skip files ending in .min, but check the exclusion list.
- Inline scripts and HTML minification. Some HTML minifiers mangle JavaScript or JSON written directly into the page, such as structured data or a booking widget’s settings.
- CSS edge cases. Spacing inside some CSS functions matters, and a careless minifier can remove it. Layout problems that appear only after minifying point here.
The symptoms are the same as for most optimisation trouble: a broken layout, a dead menu, a form that will not submit, or a red error in the console. If you hit one and need a calm way back, the steps in what to do when a caching plugin breaks your site apply directly. The quick test is to turn JavaScript minification off, clear the cache and check whether the problem disappears. If it does, turn it back on and exclude the file named in the console error.
Where minification sits in the bigger picture
Minifying makes files smaller. It does not change whether they hold up the page, which is the more common reason for a slow first paint. If your report lists your stylesheets and scripts as blocking, start with the order for fixing render-blocking files and treat minification as one of the last steps there.
Our website speed and performance guide sets these small gains against the larger ones from images, caching and server time, which is where a slow site usually needs work first.
Frequently asked questions
Should I minify files that already end in .min?
No. A file ending in .min.js or .min.css has already been minified by its developer, so running it through again saves nothing and occasionally introduces errors. Most optimisation plugins skip these files by default. If yours does not, add them to its exclusion list.
Does minification make my site harder to debug?
A little. Minified code is one long line with short variable names, so error messages point to unreadable places. When you need to investigate a problem, switch minification off temporarily, clear the cache and reproduce the error with the original files, then switch it back on.
Is minifying HTML worth doing?
Usually it saves very little, because HTML pages are compressed in transit and have less removable whitespace than people imagine. It also carries the most risk of breaking inline scripts and structured data. Leave it off unless testing shows a clear gain on your pages.
My score did not change after minifying. Did it work?
Check the transferred size of your CSS and JavaScript in the browser’s Network tab before and after. If the files are smaller, it worked; the gain was just too small to show in the score, often because most files were already minified or compression was already doing most of the work.
Minification and deferral are on the list in our website speed service, but so are the bigger items that usually matter more. The audit puts every finding in order of impact, so a small gain like this one is not mistaken for the main fix.
Next in this series: Defer vs Async JavaScript: Which to Use and What Breaks
