Jump to content

Slow loading IPB 2.3.x vs. 3


Bono

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • Management

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)

Link to comment
Share on other sites

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.css

GZIP 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.

%7Boption%7D


@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&params.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&params.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&params.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&params.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&params.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&params.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&params.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

Link to comment
Share on other sites

  • Management

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.

Link to comment
Share on other sites

  • Management

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.

Link to comment
Share on other sites


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.
Link to comment
Share on other sites

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!

Link to comment
Share on other sites


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.
Link to comment
Share on other sites

  • 8 months later...

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!
Link to comment
Share on other sites

  • 1 month later...

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...