• Welcome to Simple Machines Community Forum. Please login or sign up.
January 21, 2022, 03:54:02 PM


SMF 2.0.19 has been released! Please update. Read more.

Minify code? (I searched this board)

Started by KensonPlays, July 08, 2013, 10:25:14 AM

Previous topic - Next topic


I searched this board for "minify" but no results came up. I am trying to increase my Google PageSpeed and Yslow numbers, even though it already loads in 1.8 or so seconds. I would love it to be a little faster for a better result and the test said to minify. I could probably run it through an HTML minifier or JS minifier and do that, but something official as an optional item, would be nice. Please don't start a post war here.


Would be nice to have an option to autocompress. You would have the normal uncompressed versions when a change is made it would recompress the uncompressed version to a compressed version to be used on your site.
Community Suite for SMF - Take your forum to the next level built for SMF, Gallery,Store,Classifieds,Downloads,more!

SMFHacks.com -  Paid Modifications for SMF

EzPortal - Portal System for SMF
SMF Gallery Pro
SMF Store SMF Classifieds Ad Seller Pro


If you use cloudflare ...one of the options is to min css/js/html (I'd only suggest js/css since they are static for smf and served from the cloudflare cdn).  If you don't use it, give it a try.


I just recently installed cloudflare, but the google pagespeed still suggests it for some reason.


Quote from: Kcmartz on July 08, 2013, 10:25:14 AM
I searched this board for "minify" but no results came up.
Odd... I searched "community" for "minify" and got 21 hits over a number of topics. JS and CSS are good to minify, and PHP could at least have comments stripped out (although now being cached, it might not help so much). The challenge is coming up with a naming convention where you can run a mixture of minified and unminified files for testing, and have files automatically minified (cron job/make?) for production. Maybe .php for unminified PHP (having priority) and .php5 for minified?


I was able to eliminate the warning given by google's pagespeed insight test for minifying html by adding this line to QueryString.php just before "return $buffer;"

$buffer = join("\n", array_map("trim", explode("\n", $buffer)));

Granted, it doesn't strip comments, or minify embedded css/js beyond stripping leading whitespace at the beginning of each new line, but it boosts the page rank so must at least minify it to within acceptable limits. Quick, easy, and doesn't involve interfering with source files or complicate mod installs/updates.

I also have css combined and minified on the fly, resulting in only one css file per page load. Each combination of css files are cached, and the caches are updated if/when the original css files are modified. That's a little more complicated, some need to be excluded depending on what mods are installed, so it's not for suggesting here.


The interesting factor is that it may or may not actually reduce the page as physically sent. Depending on the page itself, it may actually compress less well that way and end up being bigger. This is less common in CSS because of the lack of repeated indentation (one byte for one tab doesn't compress) but the many repeated tabs will compress rather well.
No good deed goes unpunished
All helpful urges should be circumvented


I see your point, but I guess with most SMF users also having mods installed, I know from personal experience many don't use tabs but a god forsaken string of spaces (which I accept could compress ok too), with an unknown amount of whitespace on each line, it may be worthwhile for some. If it raises the google pagespeed insight, I'd say it probably is, given they like many top end search engines use it in their algorithms now. I know they claim not to for adsense placement, but you've got to ask yourself if they don't why do they put the pagespeed results in the adsense performance metrics?

I have my server set up to compress if the requesting browser can accept it, in real terms it probably only reduced the size marginally, but my view was and is that it was worth it to have a 97/100 rating as compared with SMF's 71/100. For mobiles mine is 92/100 while SMF's is just 58.

Saying that though, most of the rating increase came from combining and minifying css & js, along with loading js async where possible.


Of course they do. Download speed is one of the metrics used in ranking, has been for some time (amongst the other 'over 200 signals' that they use)

And yes, that's all worth doing except the headaches of doing it in a generic fashion is actually hard work - so much JS is inlined into the page, including events, and setting up all the stuff for deferring that is surprisingly difficult. Realistically it just isn't going to happen in 2.1.
No good deed goes unpunished
All helpful urges should be circumvented


I haven't bothered with any of the inline stuff, stripping the white space is as near as that's come to being minified, but that's all done with that one line too.

I've used this https://code.google.com/p/minify/ [nofollow] for minifying the css, scanning the buffer for the link tags and replacing them with one combined link to /min/?f= therefore minify handles caching of the combined files and replacing them if/when originals are modified. It does involve specifying an exclusion array though. One of the mods broke when it's css was included for some reason and it was easier to exclude it than find out why and fix it.

And as far as the js files themselves go, well, that's a minefield as is frequently demonstrated by total_cache for wordpress. If they don't contain document.write, I think adding the async attribute to the script tags is better than the complexities of combining etc. At least then they don't render block and affect the ratings, it's an extra 6 characters to add to the relevant smf source files where it's appropriate and it doesn't affect the functionality, but that's not a big task really.

It's got to be better than taking a 58/100 hit on page speed ratings.


Except we can't use the async attribute because we're not using an HTML5 doctype - and just for fun a lot of the inline script relies on the other stuff already having been loaded first. It is a massive undertaking to properly fix. I've been through that process before and I wasn't even the one doing it then.
No good deed goes unpunished
All helpful urges should be circumvented