CODEWITHSUNDEEP
javascriptcssperformance
Ahmed Nabil
Ahmed Nabil

Reputation: 19056

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

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:

If any update is required:

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

Upvotes: 2

Views: 235

Answers (2)

Paul D. Waite
Paul D. Waite

Reputation: 98926

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.

Upvotes: 2

Brigand
Brigand

Reputation: 86270

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.

Upvotes: 2

Related Questions