Adds config option to minify HTML output

[homstie-dev]

If the $config['minify_output'] setting is set to TRUE, CodeIgniter's output class will process the output with a basic minify function. Will apply minify rules according to the currently set content type (defaults to "text/html" and currently only supports "text/html" "text/css" and an extremely rudimentary minifier for "text/javascript").

Output is minified before the cache is written, so savings are also on diskspace.

According to my tests it typically reduces the content by 8-15%.

PS, the first two commits are an artifact of me not knowing how to branch properly when I started this. Those are part of my "http cache headers" pull request.

[gaker]

This is a fantastic idea. Have you given thought on newline characters & how we might handle that with pre/code tags?

[homstie-dev]

I'll modify it to leave <pre> and <code> content untouched.

There are a number of open source minifiers around, but there are probably licence incompatibilities. :(

[homstie-dev]

Well, I'm happy. My landing page is now 30% smaller, and most other pages 10-15%.

[philsturgeon]

Can you add a space in there? The most trivial thing in the world but.. , $expire).

[arenowebdev]

👍 This would help me a ton :-)

[dbpolito]

+1

[mpmont]

+1

[eweap]

+1

[tarciozemel]

+1

[timw4mail]

Cool. I've had my own makeshift version of this myself that clobbers <pre> tags. So this is really nice to have in the framework.

[timw4mail]

Any advantage to the newline as opposed to a space?

And I think $output = preg_replace("!\s+!", " ", $output) is a little more readable.

[narfbg]

Replacing only 2+ space occurences should be faster than each single one.
I'd also vote for spaces as opposed to newlines though.

[homstie-dev]

The newline instead of space was based on an old and perhaps unfounded superstition I have that having excessively long line-lengths can be an issue. Since newline and space are otherwise functionally the same I saw no harm in it. But if line-lengths are not actually an issue,

As far as s{2,} vs s+, I imagine the former is more efficient since it is more restrictive. The latter does a replace on every single space, tab, and/or newline, whereas the former only does the replace if it results in a reduction. If there's still a push for changing this I'd like to do a benchmark comparison just to get an idea, since I really have no idea what the effect is for sure.

[timw4mail]

I don't think long lines matter much. In fact, I've found that any whitespace between tags is generally superfluous. Look at the source for https://timshomepage.net/, and see how long it takes to find a browser that chokes on it.

I basically use a variation of this: https://gist.github.com/1338288

[timw4mail]

I'm not sure if it makes much of a difference, but this is how I minify CSS: https://gist.github.com/1685711

More verbose in terms of code,but perhaps equivalent in functionality.

[philsturgeon]

Yet to have any problems, even on some tricky pages http://d.pr/95kB

[philsturgeon]

I understand the benefits of using s{2,} so that sounds good, and I don't think we need to add newlines in. Apache will never care about long lines unless it's in the HTTP Request, and then it's a 8kb limit.

So it looks like we're golden here guys. @derekjones @ericbarnes @gaker got anything to say about this one? I've had it enabled for pyrocms and the whole thing seems fine, shaved 1-2kb off each page!

[philsturgeon]

Space :p

[minerbog]

I was currently using

function sanitize_output($buffer)
{
$search = array(
'/>[^\S ]+/s', //strip whitespaces after tags, except space
'/[^\S ]+</s', //strip whitespaces before tags, except space
'/(\s)+/s' // shorten multiple whitespace sequences
);
$replace = array(
'>',
'<',
'\1'
);
return preg_replace($search, $replace, $buffer);
}

to strip any white space from outside < > tags. Not sure if you could find this useful :)

[homstie-dev]

@minerbog it already does this with a single, more efficient regular expression.

[minerbog]

Apologies, regex has never been my strongest point!!

[homstie-dev]

@minerbog No worries.

[timw4mail]

👍👍

[narfbg]

Can we get this one going again?
It needs to sync with the latest changes, for a start. :)

[homstie-dev]

Somebody else do it. I'm pretty disillusioned with the whole process.

On Thu, Jun 14, 2012 at 12:27 PM, Andrey Andreev <
reply@reply.github.com

wrote:

Can we get this one going again?
It needs to sync with the latest changes, for a start. :)

---

Reply to this email directly or view it on GitHub:
#965 (comment)

[philsturgeon]

@atiredmachine don't give up now, it's nearly there. Sometimes you have to bump these things. If you hadn't noticed there are quite a few pull requests knocking around! :)

[philsturgeon]

Ignore that, I've merged it without conflict. Good work and sorry for the delay. I remember thinking this had been merged, searching for it and finding nothing.

[philsturgeon]

Bug reported related to this change #1499

[svezina]

Hey folks, I'm testing this out and getting an encoding problem for the "à" character. Other french characters seem fine, but this one gives the infamous UTF-8 question mark. Preview : http://www.tribalsolutions.ca/external/minify_encoding.jpg

[narfbg]

@svezina Is that character written in UTF-8 or some other encoding?

[svezina]

@narfbg Yep everything is UTF8 coming from a language file.

I just did a bit more troubleshooting to make sure it wasn't my app that had a problem.

• I installed a fresh copy of the develop branch.
• I copied all of the foreign characters from foreign_chars.php in a language file. (Figured I might as well test for all characters.)
• Loaded it in the default "Welcome to Codeigniter" view.

Here is the result: http://www.tribalsolutions.ca/external/minify2.jpg

ADDED: everything is OK if you don't have spaces before and after characters. It only happens if you have spaces around.

[narfbg]

Well, that makes sense ... Any UTF-8 character that doesn't need to use both of the bytes that represent it is prefixed (or suffixed, don't remeber) by \x0, which is the termination character in single-byte encodings. What minify does is to remove empty characters and this one is probably considered as one.

[svezina]

Thanks for the explanation!

I just made another interesting discovery. It seems to be server-related as well:
XAMPP with php 5.2.9 = BUG
XAMPP with php 5.3 = OK
Shared Hosting with PHP 5.2.17 = OK

I'll just use my 5.3 server for dev work then.

[narfbg]

It's more likely to be related to the PCRE version that you have available on the server than PHP itself.

But anyway ... you can't always have all the exotic features turned on. This feature is way too far from being perfect and I personally would consider it experimental - it was expected that it can cause problems in cases like yours, so for now all I can tell is - if it causes problems, turn it off. :)