css/js minification?

[spiros]

I think it would be a good idea for SMF to have some script that would automatically minify css/js.

[Arantor]

I know at least one fork does, possibly even two forks, but I'm not entirely sure whether either of them shared the code back to the original.

[MrPhil]

If SMF shipped with minified code files (comments stripped out, whitespace and newlines removed, etc.) they would be very difficult for someone to study and modify. You would need to ship both regular source and minified versions, and somehow ensure that they stay in sync. The package installer would want to work on unminified files. You certainly don't want to minify on the fly, at every access. At a minimum, something would have to check for a modification of the source at every access, which would probably cost more than just serving out the full source. If comments are stripped out, files lose their copyright and version statements. Lots of things to consider here.

I suppose someone could develop a cron job and/or makefile to, when the full source (file.type) changes, copy the .css or .js (and maybe .php) to file.type.FULL and minify the file.type. Maybe there could be a tool to copy file.type.FULL back to file.type and then invoke your favorite editor? That way, file.type is always the latest and greatest version, and out of minified form for only a few hours at most.

If PHP was minified in this way, could we get rid of the SMF cache? It seems to be a constant source of trouble.

[Arantor]

Which is why you don't do it that way, you rebuild minified files when necessary, i.e. bundling the minifier with it.

If PHP was minified in this way, could we get rid of the SMF cache? It seems to be a constant source of trouble.

So you minify PHP files. You gain a tiny fraction of a percent, at *best* in performance. Any gain you make would be blown away completely by the fact that the results of database queries no longer get cached.

That's what the cache is really for: minimising the load on the database, not the PHP load.

It would also completely devastate anything the package manager does, but from my perspective that's not really a bad thing as such.

[spiros]

I think it could be compiled (and the resulted compiled file cached) every time there is a change to the unminified css file. I think that's the way Dragoon did it with his Mobile theme.

[Arantor]

As I said, at least one of the forks is already doing this (and has been for some months), so it is doable and practical. It just requires a fair amount of rearchitecting SMF to really do it properly as some folks learned the hard way, since it requires more than just minifying files to do properly (it also needs deferring the JS until later in the page which is not without its own issues)

[spiros]

Mediawiki since version 1.17 does it too + Data URI embedding

Batch loading
→ which reduces the number of requests made
The server response for module loading supports loading multiple modules so that a single response contains multiple ResourceLoader Implements, which in itself contain the minified and concatenated result of multiple javascript/css files.
http://www.mediawiki.org/wiki/ResourceLoader

[Arantor]

There are issues relating to that with IE because certain versions of IE can't handle URLs that are too long.

It would be advantageous but it's a colossal amount of work and the most complete solution that is hardened and tested... is not under a compliant licence and can't be integrated with SMF for that reason.