BlowingWind Posted June 30, 2009 Share Posted June 30, 2009 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. Link to comment Share on other sites More sharing options...
Management Matt Posted June 30, 2009 Management Share Posted June 30, 2009 Hello, If you switch minify on, then it will combine the javascript for you. Link to comment Share on other sites More sharing options...
Mark Posted June 30, 2009 Share Posted June 30, 2009 Putting the javascript all in to one file would actually reduce performance as unnecessary javascript would have to be loaded on each page. Link to comment Share on other sites More sharing options...
altenerg Posted October 30, 2011 Share Posted October 30, 2011 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 Link to comment Share on other sites More sharing options...
Management Matt Posted October 30, 2011 Management Share Posted October 30, 2011 That URL is cached. At least that is from my own experience. Link to comment Share on other sites More sharing options...
Enkidu Posted October 30, 2011 Share Posted October 30, 2011 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. Link to comment Share on other sites More sharing options...
bfarber Posted October 31, 2011 Share Posted October 31, 2011 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 andpublic/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. Link to comment Share on other sites More sharing options...
altenerg Posted November 1, 2011 Share Posted November 1, 2011 Having said all that, I have some ideas to improve minify/caching in future versions. Music to my ears :) Link to comment Share on other sites More sharing options...
altenerg Posted March 8, 2012 Share Posted March 8, 2012 bump. js and css is still clumsy in 3.2 Link to comment Share on other sites More sharing options...
bfarber Posted March 8, 2012 Share Posted March 8, 2012 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. Link to comment Share on other sites More sharing options...
altenerg Posted March 8, 2012 Share Posted March 8, 2012 Or researched even more aggressively. But ok either way. Link to comment Share on other sites More sharing options...
Management Charles Posted March 8, 2012 Management Share Posted March 8, 2012 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. Link to comment Share on other sites More sharing options...
Rikki Posted March 9, 2012 Share Posted March 9, 2012 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. Link to comment Share on other sites More sharing options...
altenerg Posted March 9, 2012 Share Posted March 9, 2012 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. Link to comment Share on other sites More sharing options...
Brett333 Posted April 30, 2014 Share Posted April 30, 2014 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 Link to comment Share on other sites More sharing options...
Management Matt Posted May 1, 2014 Management Share Posted May 1, 2014 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. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.