Compress and combine files for performance

[BlowingWind]

1. Can suggest that Invision "compress" the png files before you ship.
I noticed that on average I am able to losslessly squeeze another 8% out of each png file shipped.
I am using a cheap and slow hosting site, trying to squeeze whatever juice out.

2. Can also combine the JS files into one giant file. Another way to improve
Painful for me to manually do it.

[Matt]

Hello,

If you switch minify on, then it will combine the javascript for you.

[Mark]

Putting the javascript all in to one file would actually reduce performance as unnecessary javascript would have to be loaded on each page.

[altenerg]

Putting the javascript all in to one file would actually reduce performance as unnecessary javascript would have to be loaded on each page.

Not true. Combining into one single .js file would mean the webbrowser would cache the script. Which is probably what the user is requesting. Thus, scripts would have to load ONCE on first visit to forum and never again, or until cache expires. Of course you can get technical about cache-control headers but bottom line is setting up one combined file to cache would be the best solution performance wise.

Currently the "Minify" setting for IP Board is bad in that it creates a non cacheable query string:

public/min/index.php?ipbv=32006&charset=UTF-8&f=public/js/ipb.js,cache/lang_cache/1/ipb.lang.js,public/js/ips.hovercard.js,public/js/ips.quickpm.js,public/js/ips.board.js

and

public/min/index.php?ipbv=32006&f=public/style_css/css_8/ipb_help.css,public/style_css/css_8/ipb_styles.css,public/style_css/css_8/calendar_select.css,public/style_css/css_8/ipb_common.css,public/style_css/css_8/ipb_skingen.css[/code]

Meaning, those have to be loaded on EVERY page view. Combining and renaming to a static filename url would have been the best solution

[Matt]

That URL is cached. At least that is from my own experience.

[Enkidu]

Hello,

If you switch minify on, then it will combine the javascript for you.

Matt, what I don't understand is why do we have to do it on the fly? why not minify JavaScript beforehand (maybe have the downloaded copy of IPB with minified version of all JS, and put the un-minified in the tool directory?)

Also we could modify the caching logic of CSS files to produce a minified version of each file so we don't need to minify it each time it is requested. This way we can re-route the amount of CPU power of minification to other tasks such as reducing the size of html.

[bfarber]

Not true. Combining into one single .js file would mean the webbrowser would cache the script. Which is probably what the user is requesting. Thus, scripts would have to load ONCE on first visit to forum and never again, or until cache expires. Of course you can get technical about cache-control headers but bottom line is setting up one combined file to cache would be the best solution performance wise.

Currently the "Minify" setting for IP Board is bad in that it creates a non cacheable query string:

public/min/index.php?ipbv=32006&charset=UTF-8&f=public/js/ipb.js,cache/lang_cache/1/ipb.lang.js,public/js/ips.hovercard.js,public/js/ips.quickpm.js,public/js/ips.board.js

and

public/min/index.php?ipbv=32006&f=public/style_css/css_8/ipb_help.css,public/style_css/css_8/ipb_styles.css,public/style_css/css_8/calendar_select.css,public/style_css/css_8/ipb_common.css,public/style_css/css_8/ipb_skingen.css

Meaning, those have to be loaded on EVERY page view. Combining and renaming to a static filename url would have been the best solution

If your browser has to download 15 files, they can still be cached. Combining all JS into one file does not solve a problem with caching, it solves a problem with multiple HTTP requests. There is a huge tradeoff at some point.

Matt, what I don't understand is why do we have to do it on the fly? why not minify JavaScript beforehand (maybe have the downloaded copy of IPB with minified version of all JS, and put the un-minified in the tool directory?)

Also we could modify the caching logic of CSS files to produce a minified version of each file so we don't need to minify it each time it is requested. This way we can re-route the amount of CPU power of minification to other tasks such as reducing the size of html.

Those files are dynamically combined based on what the page needs. Some pages need ipb.js and ips.status.js. Some need those two plus ipb.boards.js. Some also need ips.rating.js. Some need ipb.js, ips.status.js and ips.rating.js but not ipb.board.js. Minify handles combining the files you need for the page.

And minify files can be cached, despite claims to the contrary. Query strings do NOT mean a file cannot be cached - that is the job of cache headers to tell the browser.


Having said all that, I have some ideas to improve minify/caching in future versions.

[altenerg]

Having said all that, I have some ideas to improve minify/caching in future versions.

Music to my ears :)

[altenerg]

bump. js and css is still clumsy in 3.2

[bfarber]

bump. js and css is still clumsy in 3.2

I'm not sure what you mean by "clumsy". Effectively you are simply asking that we don't use a query string to handle this, which doesn't resolve much.

The ideas I had are low priority and have potential to create new bugs, so they have to be researched cautiously.

[altenerg]

Or researched even more aggressively. But ok either way.

[Charles]

altenerg: Perhaps you can clarify your "clumsy" observation? You seem quite displeased with things and if you can clarify what you are referring to it would be helpful.

[Rikki]

We can't simply dump all our JS in one file as it is right now. The way our JS works, when a module is included, it is instantiated automatically so that it is available to the rest of the script. If we put everything in one file, we'd be instantiating every JS module we have (15-20 modules).

Doing what you're suggesting would require some refactoring of our JS, with the potential of introducing new bugs.

[altenerg]

You don't have to put "everything" into ONE file. Anyway I don't have the time to walk through this. I figure you guys will eventually get there... someday. For now I'll be working on setting up our own custom solution that avoids bugs with certain pages.

Probably I'm just way to obsessed with performance and I'm certain I don't represent the avg IPB client anyway.

Thanks for your consideration and for this great forum solution.

[Brett333]

Sorry to bump an old thread back up, but I just noticed this as one of my top processes that use CPU..

% CPU Process

72.4 /usr/bin/php /home/*********/public_html/forum/public/min/index.php

This was found in WHM -> Server Status -> Daily Process Log -> Top Processes

[Matt]

In 4, we no longer use an external minify PHP file. All the CSS and JS is bundled appropriately and minified during the build processes so they can be simply included on the page without the need for external minification.