In web development it's often adventageous to minify embeded scripting files. Minification refers to the process of removing all unnecessary characters while leaving the core functionality unchanged. The end result is a smaller file that is identical to the original for all intents and purposes. Smaller files require less bandwidth and are faster for the client to download.
data·yze uses PHP to push files from our development enviornment to production. We opt to automate the minification process during this push step. This gives us all of the benefits of minimization without the drawbacks. Although not intended, the minification profess can make code more difficult for humans to read. Our users get the minimized, faster to download version of the code. Our developers working in the testing enviornment work with the larger, more human readable version of the code. Since our users vastly outnumber our developers, the increased bandwidth footprint from the non-minimized files our developers use is neglagable.
At data·yze, minimizing CSS reduces the size of our CSS files by 20-23% on average. Here is the code we use:Minimizing CSS
So what's going on here?
Line 3 is the real meat of the expression. The function preg_replace is looking for any string that matches the regular expression, \/\*((?!\*\/).)*\*\/, and removes it from the $css string. \/\* and \*\/ match the /* and */, start and end comment delimiters in CSS respectively. Both /, and * are special characters and need to be escaped. The middle part, ((?!\*\/).)*, preforms a negative look ahead. The expression matches any string (.) so long as the expression (\*\/), the CSS end comment delimiter is not in it.
The rest of the code is pretty straight forward. Line 4 collapses white space. Line 5 removes white space where it's not needed, and line 6 removes the final semicolon since it's not needed. If we want to be pedantic, lines 4 - 6 could be merged into a single statement using a 3 element array for all the regular expressions and another for the replacements. I, personally, prefer to have one non-trivial regular expression per line. Keeping lines seperate makes the code more readabile, which makes it easier to debug and modify. The code only executes when our developers are ready to push changes to production. Since the code isn't client facing, the potential improvement in proformance isn't worth the hit to readability.
Let's see it in action with the following example: