Bono Posted February 2, 2010 Posted February 2, 2010 I'm wondering has anyone noticed that IPB 3 has one huge js file? My previous IPB 2.3 installation on my page was under 150KB(whole site graphics, banner, js and css), and from version 3 js alone has 158KB. You can check here file: http://community.invisionpower.com/public/min/index.php?g=js size 158KB. And in IPB 2.3 all js scripts were under 30KB, this is really big jump in size. jscripts/ips_ipsclass.js 6.7KB jscripts/ipb_global.js 16.9KB jscripts/ips_menu.js 6.1KB So my question is what can it be done because 156KB is totally unacceptable for site. That is probably a reason why so many people see increase in server and traffic load.
Michael Posted February 2, 2010 Posted February 2, 2010 It's combining several javascript files into one. It's bigger in total size, yes, but it's also loading all files at once using a single HTTP request as opposed to loading several smaller files. Most browsers will cache that file as well, so it's not like you have to load the 158KB file on every page load. You can also load the prototype/scriptaculous files from Google instead of from your site, that will offload some of the size of files that have to be downloaded from your site.
Bono Posted February 2, 2010 Author Posted February 2, 2010 Look how it looks, half od size of site is js and that js is not even gziped. http://www.webpagetest.org/result/100202_4T8P/ I don't know why IPB talks all the time about optimization and that developers are following standards when evidently they don't. From this year Page speed affects google page rank, and if you run page speed plugin on this or any other forum you would see it will complain about size of js file, even thought it is combined in one file. Compared to vBulletin, IPB has 2x bigger file. And throwing new hardware at some problem is never the answer, like when so many people outgrew they shared plans because of lack of optimization from IPB side.
Rikki Posted February 2, 2010 Posted February 2, 2010 The web has progressed a lot since 2.3, so it's not surprising that the size of our javascript has grown too. If people want the interesting new ways to use the software, then that's going to mean there's more javascript too. The vast majority of the javascript is in standalone .js files, which means a user only downloads them once - they're cached from then on. Not only that, but we support additional features such as Minify, which intelligently compresses and optimizes javascript (and CSS) on the fly, and Google CDN so that Prototype and Scriptaculous are loaded from Googles servers instead (these are both options configurable in your ACP; Minify is on by default, Google CDN is off). We shipped pre-compressed javascript files with IPB2, but then had to also shipped uncompressed versions for developers to use. In IPB3 we ship with uncompressed javascript files, because Minify handles the compression at run time on its own. Although IPB2 had several smaller JS files, it would have required a new HTTP request for each one, which takes time. Although IPB3 has bigger files, it can grab the main JS in one request. This is efficient. Search engines do not load javascript files when they index your content. The size of a JS file (which is not even extraordinarily large anyway) will mean nothing to Google. Finally, a large javascript file is not going to affect your server load in any meaningful way. It's a static file, it needs no processing :) [edit] I've just run the test on a couple of well-known sites, just for comparison. digg.com: 130KB of javascript, 10 second initial response time, 9 second repeat-view time. cnn.com: 564KB of javascript, 34 second initial response time, 5 second repeat-view time. Compared to these mainstream sites, I think we're doing pretty well actually.
Management Matt Posted February 2, 2010 Management Posted February 2, 2010 The combined size of the javascript file is really not an important metric. If you wish to compare vBulletin, then lets look at what is important: On the first page load, their board index made 67 HTTP requests. On the second page load, their board index made 63 HTTP requests. Only 4 items were actually cached by the browser. Complete rendering time of all markup, CSS, JS and images is 15.46s on the first view, 13.6s on the second view. IP.Board: On the first page load, our board index made 41 HTTP requests. On the second page load, our board index made 17 HTTP requests. Our external style sheets and JS are set to cache properly in the browser. Complete rendering time of all markup, CSS, JS and images is 3.7s on the first view, 1.5s on the second view. This means that despite the size of the combined JS, IP.Board is significantly quicker on subsequent visits whereas vBulletin clearly isn't. (Also keep in mind that we have a custom header which will make a few separate HTTP requests and take some processing time that won't affect a stock installation)
Bono Posted February 2, 2010 Author Posted February 2, 2010 You have hosting services in USA and most of time people on other continents can't pull files in full speed, that is why there is compression. If you do not care that js file is 184KB big, why do you have files in png/jpg why not leave them in bmp or tif. I look at that overhead and it really bothers me because on my adsl 8mbit from Europe it takes 300-500ms to load js file and this is exactly amount of time it takes longer to load IPB 3 compared to 2.3 version on same server. If you haven't read that url I have provided here is optimization recommendation:GZIP encode all appropriate text assets (text responses > 1400 bytes): FAILED (158.9 KB, compressed = 39.8 KB - savings of 119.2 KB) - http://community.inv.../index.php?g=js FAILED (65.8 KB, compressed = 17.6 KB - savings of 48.2 KB) - http://community.inv...ublic/js/ipb.js,public/js/ips.quickpm.js,public/js/ips.hooks.js,public/js/ips.board.js,cache/lang_cache/1/ipb.lang.js FAILED (46.9 KB, compressed = 10.7 KB - savings of 36.1 KB) - http://community.inv...ndar_select.css,public/style_css/css_1/ipb_editor.css,public/style_css/css_1/ipb_styles.css FAILED (17.7 KB, compressed = 4.6 KB - savings of 13.1 KB) - http://www.invisionp...ssets/js/ips.js FAILED (1.5 KB, compressed = 1.0 KB - savings of 0.5 KB) - http://community.inv...1/ipb_print.cssGZIP score : 29 306.4 KB total in compressible text, target size = 89.3 KB - potential savings = 217.2 KB And google bots they do not count actual speed loading of site but they analyze based on their recommendation and finally it is included in final Page Rank. @Rikki I think developers in CNN are aware of size of their size so that is why they probably tried speed up loading service js of cookieless domain. And their site is example of non optimized site this is just terrible: http://www.webpagetest.org/result/100202_4TC9/1/performance_optimization/ Why load 250kb, when you can load 850kb of uncompressed text. GZIP encode all appropriate text assets (text responses > 1400 bytes): FAILED (148.1 KB, compressed = 40.8 KB - savings of 107.3 KB) - http://i.cdn.turner.com/cnn/.element/js/3.0/protoaculous.1.8.2.min.js FAILED (89.5 KB, compressed = 20.1 KB - savings of 69.4 KB) - http://symbolcomplete.marketwatch.com/SymbolComplete/js/yui-sc-all.js FAILED (67.0 KB, compressed = 12.2 KB - savings of 54.8 KB) - http://i.cdn.turner.com/cnn/.element/js/3.0/connect/connect-lite.js FAILED (62.5 KB, compressed = 15.3 KB - savings of 47.2 KB) - http://i.cdn.turner.com/cnn/.element/js/3.0/local.js FAILED (49.8 KB, compressed = 12.4 KB - savings of 37.4 KB) - http://i.cdn.turner.com/cnn/.element/js/3.0/main.js FAILED (42.5 KB, compressed = 7.0 KB - savings of 35.5 KB) - http://i.cdn.turner.com/cnn/.element/css/3.0/personalization.css FAILED (33.8 KB, compressed = 6.9 KB - savings of 26.8 KB) - http://i.cdn.turner.com/cnn/.element/css/3.0/common.css FAILED (36.3 KB, compressed = 10.3 KB - savings of 26.1 KB) - http://i.cdn.turner.com/cnn/.element/js/3.0/video/cvp.js FAILED (39.2 KB, compressed = 14.5 KB - savings of 24.7 KB) - http://i.cdn.turner.com/cnn/.element/js/3.0/s_code.js FAILED (27.3 KB, compressed = 7.5 KB - savings of 19.8 KB) - http://i.cdn.turner.com/cnn/.element/js/3.0/video/cvp_suppl.js FAILED (23.9 KB, compressed = 4.4 KB - savings of 19.5 KB) - http://i.cdn.turner.com/cnn/.element/css/3.0/main.css FAILED (22.4 KB, compressed = 5.1 KB - savings of 17.3 KB) - http://i.cdn.turner.com/cnn/.element/js/3.0/StorageManager.js FAILED (19.2 KB, compressed = 5.3 KB - savings of 13.9 KB) - http://i.cdn.turner.com/cnn/.element/js/3.0/csiManager.js FAILED (17.0 KB, compressed = 3.8 KB - savings of 13.2 KB) - http://i.cdn.turner.com/cnn/.element/css/3.0/connect/overlay.css FAILED (15.9 KB, compressed = 4.8 KB - savings of 11.1 KB) - http://i.cdn.turner.com/cnn/cnn_adspaces/cnn_adspaces.js FAILED (9.0 KB, compressed = 2.6 KB - savings of 6.4 KB) - http://view.atdmt.com/LDR/iview/199773923/direct;wi.300;hi.250/01/cbpvgtN,bfwqqfvkmrwzt?click=http://ads.cnn.com/event.ng/Type%3dclick%26FlightID%3d281872%26AdID%3d385088%26TargetID%3d72645%26Segments%3d730,2247,2743,2823,3285,9496,9779,9781,9853,10381,13086,13087,13088,13090,13091,13303,16113,16337,17173,17251,18517,18904,18982,20139,23491,23793,25535,25538,25544,25547,25550,26904,29699,29776,30401,31073,31265,31781,31782,32004,32594,32736,32825,32859,33776,33802,33852,33872,33873,33879,34092,34174,34253,34282,34457,34614,34895,34896%26Values%3d1588%26Redirect%3d FAILED (10.2 KB, compressed = 4.1 KB - savings of 6.1 KB) - http://i.cdn.turner.com/cnn/.element/js/3.0/swfobject-2.2.js FAILED (8.8 KB, compressed = 2.8 KB - savings of 6.0 KB) - http://i.cdn.turner.com/cnn/.element/js/3.0/weather.footer.js FAILED (7.3 KB, compressed = 2.6 KB - savings of 4.7 KB) - http://ads.cnn.com/html.ng/site=cnn&cnn_pagetype=main&cnn_position=230x250_adlinks&cnn_rollup=homepage&page.allowcompete=yes¶ms.styles=fs&tile=8179943215621&domId=709129 FAILED (6.2 KB, compressed = 2.4 KB - savings of 3.9 KB) - http://ads.cnn.com/html.ng/site=cnn&cnn_pagetype=main&cnn_position=300x100_bot2&cnn_rollup=homepage&page.allowcompete=no¶ms.styles=fs&tile=8179943215622&domId=790397 FAILED (4.8 KB, compressed = 1.8 KB - savings of 3.0 KB) - http://i.cdn.turner.com/xslo/cvp/ads/freewheel/js/fwjslib_1.1.js?version=1.1 FAILED (4.6 KB, compressed = 1.7 KB - savings of 2.9 KB) - http://i.cdn.turner.com/cnn/.element/js/2.0/ad_head0.js FAILED (4.2 KB, compressed = 1.9 KB - savings of 2.3 KB) - http://ads.cnn.com/html.ng/site=cnn&cnn_pagetype=main&cnn_position=300x250_rgt&cnn_rollup=homepage&page.allowcompete=yes¶ms.styles=fs&tile=8179943215621&domId=985003 FAILED (2.9 KB, compressed = 1.3 KB - savings of 1.6 KB) - http://es.optimost.com/es/203/c/3/u/cnn_live.js FAILED (3.4 KB, compressed = 1.8 KB - savings of 1.6 KB) - http://www.cnn.com/.element/css/3.0/png_fix.htc FAILED (2.9 KB, compressed = 1.6 KB - savings of 1.3 KB) - http://www.cnn.com/.element/css/3.0/png_fix.htc FAILED (2.1 KB, compressed = 0.9 KB - savings of 1.3 KB) - http://i.cdn.turner.com/cnn/.element/js/3.0/hpsectiontracking.js FAILED (2.0 KB, compressed = 1.0 KB - savings of 1.0 KB) - http://i.cnn.net/cnn/.element/js/2.0/csi_include.js FAILED (2.4 KB, compressed = 1.5 KB - savings of 1.0 KB) - http://ads.cnn.com/html.ng/site=cnn&cnn_pagetype=main&cnn_position=120x90_bot1&cnn_rollup=homepage&page.allowcompete=yes¶ms.styles=fs&tile=8179943215621&domId=653357 FAILED (2.4 KB, compressed = 1.4 KB - savings of 1.0 KB) - http://ads.cnn.com/html.ng/site=cnn&cnn_pagetype=main&cnn_position=300x100_bot1&cnn_rollup=homepage&page.allowcompete=no¶ms.styles=fs&tile=8179943215622&domId=274828 FAILED (2.4 KB, compressed = 1.4 KB - savings of 1.0 KB) - http://ads.cnn.com/html.ng/site=cnn&cnn_pagetype=main&cnn_position=300x100_bot3&cnn_rollup=homepage&page.allowcompete=no¶ms.styles=fs&tile=8179943215622&domId=709102 FAILED (2.3 KB, compressed = 1.4 KB - savings of 0.9 KB) - http://ads.cnn.com/html.ng/site=cnn&cnn_pagetype=main&cnn_position=1x1_bot&cnn_rollup=homepage&page.allowcompete=yes¶ms.styles=fs&tile=8179943215621&domId=728136 FAILED (2.0 KB, compressed = 1.8 KB - savings of 0.3 KB) - http://pix04.revsci.net/A09801/b3/0/3/0902121/449596127.js?D=DM_LOC%3Dhttp%253A%252F%252Fwww.cnn.com%252F%253Fundefined%253Dundefined%26DM_CAT%3Dcnn%2520%253E%2520homepage%26DM_EOM%3D1&C=A09801 GZIP score : 31 826.9 KB total in compressible text, target size = 256.7 KB - potential savings = 570.2 KB
Management Matt Posted February 2, 2010 Management Posted February 2, 2010 What would your suggestion be? We can't physically remove JS code without removing features. The figures I posted show that despite the size of the javascript file, it's cache on the first visit and doesn't affect the overall speed of the forum.
Management Matt Posted February 2, 2010 Management Posted February 2, 2010 I've run the compression test and you were right, our minify wasn't compressing. We were using an older custom version and I've just fixed it. Even so, this data is only loaded once and then is cached in your browser, it's even then it's not a very important statistic.
Bono Posted February 2, 2010 Author Posted February 2, 2010 What would your suggestion be? We can't physically remove JS code without removing features. The figures I posted show that despite the size of the javascript file, it's cache on the first visit and doesn't affect the overall speed of the forum. Distribute js compressed like you did with previous version, I would expect that with previous version you would supply raw js, and with this rls compressed one. Before there was needed to edit js for some code modifications, but now with hooks which most of the time do not need any edits I really do not see point of uncompressed js. And maybe in 3.1 try to include some of performance recommendations by google, usually I don't like google and i would never use their CDN for anything but this time they are right. EDIT: I'm just saying if it loads fast on server near you that doesn't mean it will load fast on other continent. Locally my test forum loads in 0.5s, and on server in US 1 second.
Management Matt Posted February 2, 2010 Management Posted February 2, 2010 We do via minify. :) Here's some more information: http://code.google.com/p/minify/
Guest Posted February 2, 2010 Posted February 2, 2010 When it comes to the actual static files (i.e. the CSS files) - it's up to you as a server administrator to enable compression, so you can install mod_deflate and those things will be compressed automatically. That being said, out of interest, why does IP.Board not gzip compress the combined javascript if that PHP extension is available? It might be cached properly, but you might as well make the first hit as tiny as possible. :) Edit: just seen the last two posts, ignore this!
Bono Posted February 2, 2010 Author Posted February 2, 2010 We do via minify. :) Here's some more information: [url="http://code.google.com/p/minify/"]http://code.google.com/p/minify/[/url] I know you use minify and i know what it is just I had on my site enabled minify, gzip and js and CSS files were still huge. But later on in this conversation I have seen that in skin profile properties this two options weren't enabled: - Cache CSS to text files? - Compress Cached CSS? Now they are enabled and soft refresh time was shaved from avg. 1.2s to 1.4s to 0.7-1s which is acceptable.
Autoracing Posted October 20, 2010 Posted October 20, 2010 I know you use minify and i know what it is just I had on my site enabled minify, gzip and js and CSS files were still huge. But later on in this conversation I have seen that in skin profile properties this two options weren't enabled: - Cache CSS to text files? - Compress Cached CSS? Now they are enabled and soft refresh time was shaved from avg. 1.2s to 1.4s to 0.7-1s which is acceptable. Enable this two options is something you (and IPB personel) really recommend? I ask because I have a really busy board... thanks!
bfarber Posted October 21, 2010 Posted October 21, 2010 Enable this two options is something you (and IPB personel) really recommend? I ask because I have a really busy board... thanks! Enabling the two quoted options improved front-end performance, yes.
jacky35 Posted October 21, 2010 Posted October 21, 2010 See my post on optimizing existing wordpress : It should be possible to put all the templates of ipb (css, images etc. ..) on the Google CDN and we will win a lot in speed
Julien M Posted December 20, 2010 Posted December 20, 2010 For me, my ipboard 3 is very slow : 13 secondes for the load the pages. I don't know why !!! :devil: It's very slow. :devil: Have you any solutions for a fast navigation ?
teraßyte Posted December 20, 2010 Posted December 20, 2010 Submit a ticket or post in the support forum to get help please. The feedback forum isn't really the best place to diagnose those things, it might be a third party mod as well causing it :P
Recommended Posts
Archived
This topic is now archived and is closed to further replies.