2

As we know, minifying CSS and JavaScript makes pages load faster.

In the development phase, if you need a “formatted” version, in Eclipse IDE use CTRL+Shift+F). It produces output like this:

*.cssClass {
    background-color: #FFFFFF;
    color: #C4C0B9;
    border-width: 1px;
    border-style: solid;
    border-radius: 0px;
    padding: 1px;
}

In the deployment phase, an external tool like yuicompressor will produce a minified version, like:

*.cssClass{background-color:#FFFFFF;color:#C4C0B9;border-width:1px;border-style:solid;border-radius:0px;padding:1px;}

The problem is that the development cycle then runs like this:

  • Development (initial code)
  • Format it
  • Test
  • Minify
  • Test again
  • Deployment

If any update is required:

  • Development
  • format last minified code
  • Test
  • Minify
  • Test again

Is there any trick to automatically round trip between formatted/minified code?

  • When in development: show a formatted code
  • When in deployment: save a minified code
Paul D. Waite
  • 96,640
  • 56
  • 199
  • 270
Ahmed Nabil
  • 17,392
  • 11
  • 61
  • 88
  • 2
    What’s with everyone using backticks in their questions recently? On Stack Overflow, backticks are for inline code — see http://stackoverflow.com/editing-help (and specifically http://stackoverflow.com/editing-help#comment-formatting). – Paul D. Waite Aug 21 '13 at 13:02
  • 2
    Bad idea. You should always develop on the original sources, not on something decompiled from minified versions. Build process is one way: source -> compiled/minified/compressed/concat'd version (and of course should be automated). Keep everything in version control, so you know which source version corresponds to which release. – Thilo Aug 21 '13 at 13:02
  • 2
    use a build tool to automate the process and always code to development version – Tomer Aug 21 '13 at 13:03
  • You should test a few times the minified CSS (problems with @import, @charset, `@media`, syntax of IE filters, CSS3 and multibackgrounds, animations, hsla() or complex declarations like that) and that's it. As you don't need to un-minify (it's a one-way process), no backward test – FelipeAls Aug 21 '13 at 13:07

2 Answers2

2

You shouldn't be minifying in development. Minification should be part of deployment, not development.

I’d thus advise having a step between development and live deployment. An “integration” testing phase, if you will, where code is minified and otherwise processed for live, and tested there to make sure it still works before actually being deployed to a live server.

I wouldn’t recommend testing a minified version of your CSS and JavaScript every time you edit the code during development. Minification should be a relatively reliable process, able to take any valid CSS/JS and make it smaller without changing its behaviour.

If your minifier isn’t providing that service, you should either switch to another minifier, or work on improving the minifier you’re using (by writing test cases that break it, and maybe even helping to fix it).

And, as mentioned in the comments, ideally some sort of build script would deploy to your integration and live environments, so you wouldn’t be minifying manually.

More advanced minifiers

If you have a minifer that offers really good compression, but at the cost of choking on certain code constructs, then document the code constructs that the minifier doesn't allow, and nag your team to avoid them.

But you shouldn't really be writing code for the minifier - it's meant to be a tool that helps you. Check what the byte savings are compared to a more permissive minifier (after gzipping), and decide whether they're really worth the increased mental overhead - for you, and for anyone else working on the project now and in the future.

Fewer bytes over the wire is not the only measurement that's relevant to your project.

Paul D. Waite
  • 96,640
  • 56
  • 199
  • 270
  • 1
    to get very good compression, there are things that can potentially break. For example, Closure Compiler will remove dead code, rename functions and variables, etc. unless you write your code specificity to not be malformed. Yet, it's very powerful compared to a white-space remover. – Brigand Aug 21 '13 at 13:20
  • “to get very good compression, there are things that can potentially break.” At that point, I’d look very closely at how much extra reduction I got, and what the extra development headaches were. And I still wouldn’t minify every few minutes during development — I’d write up some über-minifer-friendly coding standards instead. The minifer shouldn’t be unpredictable enough to require regular checking. – Paul D. Waite Aug 21 '13 at 13:22
  • 1
    Also just an out-of-date anecdote, but I tried Google Closure Compiler on some real-world JavaScript almost four years ago, and after gzipping (which has much more effect on bytes-over-the-wire than minification), GCC actually produced a marginally bigger file than YUI Compressor. Of course, it’ll vary depending on input, and GCC may well have improved since then. – Paul D. Waite Aug 21 '13 at 13:34
  • Oh, and: "unless you write your code specificity to not be malformed" - I think it's a good idea to write non-malformed code as a matter of course! – Paul D. Waite Aug 21 '13 at 15:17
2

Various servers can handle minifying code on request. They will cache the result to maintain near identical performance to the initial code (the first request might take a few seconds). For example

  • nodejs's connect module with node-minify (uses YUI internally, and can be easily cached)
  • PHP script that echos a compressed stylesheet (use server caching)

I recommend having a staging environment where code is minified when it's received. For example, using a post-receive hook in git, or a shell script on the server that updates code. Once you've tested it there, your primary server can receive the production files as a simple scp (secure copy) in a shell script.

Minification can cause problems unless its a simple whitespace removal (e.g. #fffff should compress to #fff), so it's always best to test it before deploying. That doesn't mean you need to worry about it on your workstation.

Community
  • 1
  • 1
Brigand
  • 84,529
  • 20
  • 165
  • 173