Comparing versions
Version 7Current version

introduction

so the bw has the same issues as any big modular CMS - its' pages are heavy. Let's use not-perfect-but-nevertheless-usefull online speed report at webpageanalyzer
Main Wiki Page of bw gets analyzed
At the time of writing this page, the statistics were:
Total HTTP Requests:31
Total Size: 103767 bytes

Object typeSize (bytes)
HTML:7347
HTML Images:24920
CSS Images:13273
Total Images:38193
Javascript:58227

Download Times
Connection Rate Download Time
56K20.68 seconds
ISDN 128K6.33 seconds

Jakob Nielsen is positive that we should achieve sub-8 seconds load time for the users to like navigating our site. Another reason for speed optimisation is reducing the load for sites with heavy traffic.
This is obviously a rather impossible task to scale down the 120k page (20k of css is omited by the analysis) to 30k, necessary for sub-8 load time, but we might want to get closer to that usability ideal. (side note: at that moment BW was using AJAX for some packages — 45k!!)
So what should we take into concideration, when theming and tweaking the bw?
The basics are simple:
  1. eliminate extra size (obvious)
  2. eliminate extra HTTP requests (less obvious. reading: Modem connections (56Kbps or less) are corrected by a packet loss factor of 0.7. All download times include delays due to round-trip latency with an average of 0.2 seconds per object. With 31 total objects for this page, that computes to a total lag time due to latency of 6.2 seconds. we are loosing more then 6 seconds just for http requests, so there's no chance for sub8 responce :( )

mind HTTP reqiests: combine and pack

in short "the less requests the better".
  1. Some of the images CAN be eliminated without any damage to the style. There's a nice CSS trick for rollover images (If using grafic rollover at all): the rollover images are stacked in single background file vertically, and on :hover the vertical position of background is changed in CSS. The same can be done with very small images, like icons and signs of external link etc. The trick is that it does't give any boost in load time if the file is smaller then 1160 bytes - it's still single TCP-IP packet. So we can combine two small graphic files if their total is still less in size then 1k. This way we cut off 1 packet and 1 http request. (At this point, reading about how much effort is needed to save 0.2 seconds, all readers are confident I'm crazy and need psychiatric attention %/ )
  2. Also, think twice before you start "slicing" into small pieces your images and backgrounds in some Adobe ImageReady. This technique is an offspring of table-based layouts — when bw has div-based layout at the moment. IMHO with div-based layout you might get better results now having 3 big background images istead of 30 small ones.
  3. Combine javascript and CSS files: put all external css into one file - less files means less http requests. Eliminate redundant markup before uploading to the server, but leave read-frendly version locally for editing. In general, BW uses very complex css for styling. As a web-designer, I like this approach. But despite my optimisation efforts the css in my instalation is still over 15k. If you have any suggestions, please add to this text.
  4. Then search your bw installation for majorly used javascript files: put them together, then eliminate redundant markup and pack. Currently /xing has already implemented Dean's packer in HEAD, but it omits the first step, which costs about 10-20% size. Also, in distro the used js is parted into different files, because of BW modular structure: some .js files only required by specific packages. But in real installation it's different: you know what packages you are going to use, so you CAN combine all used .js in 1 file. Js in my installation (1.3) is less then 8k. It's only 3k and 3 http requests smaller then original BW .js set, but I'm sorta proud of it :)

Side note: CSS and javascript are cached, so they are loaded once in a while, but they do load the first time, which is the most important for the visitor: if he choses to stay and wait for the site to load or he closes the broser tab and forgets about your site existance. Once again, Jakob Nielsen says most visitors will close page if they will not get responce in 8 seconds. This is disputable, though, as this findings are sort of outdated. Also, the amount of dial-up users in North America and EU is decreasing, so speed optimisation might be not so important for many sites.

Beware of the IE6

There are browsers, and there's IE. You might want to use nice modern techinques to style your site, but IE renders them wrongly or differently, so you might wind up in the situation when you have a nice styling + enormous tail of CSS hacks, javascripts etc., forcing your style to look as intended in Explorer.
  • transparent png files are nice, but they don't work with IE6, and require warious fixes to be displayed correctly. Thus, by creating nice disign pattern with the png, we add unnecessary js fixes: minimum +2 files equals in extra size and extra http requests
  • we should also mention Box model, CSS2 and CSS3 selectors non-collapsing or unexpected margins etc. You either fix them with CSS hacks (adding extra bites to your CSS sheet) or Javascript like Dean's IE7 . I recommend conditional comments, CSS hacks or avoiding usage of such elements when possible. consult my favourite css resource for knowledge and help.
read more at theme compilance with MSIE

image optimisation

My offer is to postpone using .png until IE6 is history. And if we are not using alpha transparency, why use it: it usually optimises for size worse then .gif. If you really want to use it, use it together with PNGCRUSH or other similar packer.
As for regular .gif or .jpg, I'll not waste my time explaining. If you don't know it, quit webmastering.

semantic layout

Current Jill theme already has it: first in code comes bitmain, only then columns. Hurray for xing! If you are creating custom theme, don't forget about this. It's not exactly conventional speed optimisation, but it's important.

other compression

BW have function to activate gzip. Use it. Also, use { strip} tags in smarty templates.
One more thing: if browser loads DOM (more specifically recieves all necessary dimentions of all the objects), it shows the page before images are loaded. Always set their height, width (and alt), the page will be rendered faster. The same impact on browser seems to be caused by
tag. The code before rule is rendered before the rest is loaded.

 

Introduction

Bitweaver has the same issues as any big modular CMS - its pages are heavy, because it is very powerful and has many features. Back in April 2006, when this page was created, the statistics of the main wiki page of bitweaver,
analyzed by the online speed report service of websiteoptimization.com, were:
Total HTTP Requests:31
Total Size:103767 bytes
HTML:7347 bytes
HTML Images:24920 bytes
CSS Images:13273 bytes
Total Images:38193 bytes
Javascript:58227 bytes
connection rate 56K20.68 seconds download time
connection rate ISDN 128K6.33 seconds


In 2010 (May 31), this becomes
Object type Size (bytes)Download @ 56K (seconds)Download @ T1 (seconds)
HTML: 32249 6.63 0.37
HTML Images: 22854 7.35 2.92
CSS Images: 38629 8.50 1.00
Total Images: 61483 15.85 3.92
Javascript: 71186 15.19 1.38
CSS: 1096 0.42 0.21


with some further qualitative analysis : there are green points such as use of Gzip, only one HTML and one CSS file, but too many images (18), and too much Javascript (71k). Of course, nobody today still uses 56k links, but still at T1 speed the calculated speed is about 6 seconds (Yes, I too get more than 9 by simply adding, go figure). So a remommendation would be to use Gzip also for javascript packages. Also adding width and height attributes to all images should make rendering faster.


What could be done?

eliminate extra size

  • Jakob Nielsen is positive that we should achieve sub-8 seconds load time for the users to enjoy navigating our site. Another reason for speed optimisation is reducing the load for sites with heavy traffic. In the above report, it is obviously a rather impossible task to scale down 120 kilobyte (20 kilobyte of CSS are omitted by the analysis) to 30, necessary for sub-8 load time, but we might want to get closer to that usability ideal.

eliminate extra HTTP requests

  • Reading: Modem connections (56Kbps or less) are corrected by a packet loss factor of 0.7. All download times include delays due to round-trip latency with an average of 0.2 seconds per object. With 31 total objects for this page, that computes to a total lag time due to latency of 6.2 seconds. In the above example, we are loosing more then 6 seconds just for HTTP requests, so there's no chance for sub8 response :(
  • "The less requests the better", so before optimizing file size, think how to reduce quantity of files per page.
  • Think twice before you start "slicing" into small pieces your images and backgrounds in some Adobe ImageReady. This technique is an offspring of table-based layouts — when bw has div-based layout at the moment. IMHO with div-based layout you might get better results having 3 big background images instead of 30 small ones.
  • Also, some of the images can be eliminated without any damage to the style. There's a nice CSS trick for rollover images (if using graphic rollover at all): the rollover images are stacked in single background file vertically, and on :hover the vertical position of background is changed in CSS. The same can be done with very small images, like icons and signs of external link etc. The trick is that it doesn't give any boost in load time if the file is smaller then 1160 bytes - it's still single TCP-IP packet. So we can combine two small graphic files if their total is still less in size then 1k. This way we cut off 1 packet and 1 HTTP request. (At this point, reading about how much effort is needed to save 0.2 seconds, all readers are confident I'm crazy and need psychiatric attention %/ )
  • Combine javascript and CSS files: put all external CSS into one file - less files means less HTTP requests.
  • Eliminate redundant markup before uploading to the server, but leave read-frendly version locally for editing.
  • Eliminate redundant markup and pack your custom CSS and Javascript files.

Image optimisation


Other compression

  • Bitweaver's gzip function
  • Smarty's { strip}
  • Always set the height, width and alt-attribute of images, so the browser shows the page before the images are loaded. Same for tables.

Comparisons

Web Page Analyzer (04/2006)

To compare bitweaver with other content management systems, pass their main pages through websiteoptimization.com's analyzer:
Link to page analyzedTotal HTTP Requests Total Size load time on 56k modemremarks
bitweaver3159368 bytes11.83 seconds20k CSS file is not calculated
Drupal5185049 bytes17.95 seconds0 (ZERO!) Javascript
mediawiki2984136 bytes18.37 seconds30kb CSS in 8 files - seems unnecessary for such a basic layout
Xoops30131660 bytes26.24 secondssome broken links
http://tikiwiki.org/tiki-index.php?page=TikiWiki21189316 bytes38.13 secondsquite a lot of everything
Joomla60200149 bytes40.29 secondsover 100k HTTP images!
Xaraya49191770 bytes40.82 seconds60k CSS in 14 files!
e10773238522 bytes47.94 seconds170k images! (which also means the actual frame is rather slick)


WebWait (11/2007)

webwait.com: Use WebWait to benchmark your website or test the speed of your web connection. Timing is accurate because WebWait pulls down the entire website into your browser, so it takes into account Ajax/Javascript processing and image loading which other tools ignore.
Link to page analyzed Average load time after 5 runs (in seconds, call interval: 60 seconds)
Xaraya0.94
Drupal1.05
mediawiki1.26
e1072.03
Joomla2.68
bitweaver.org/blogs2.80
bitweaver.org/wiki3.26
bitweaver.org/articles3.61
http://tikiwiki.org/tiki-index.php?page=TikiWiki3.95
Xoops7.72

Page History
Date/CommentUserIPVersion
31 May 2010 (12:05 UTC)
While most othe content here is incredibly old, I updated WSO's result as a start.
Tochinet193.191.209.24430
Current • Source
francescabuchanan194.44.228.3429
View • Compare • Difference • Source
laetzer85.178.62.11728
View • Compare • Difference • Source
xing194.152.164.4527
View • Compare • Difference • Source
laetzer85.178.30.7426
View • Compare • Difference • Source
laetzer85.178.30.7424
View • Compare • Difference • Source
dspt213.184.224.323
View • Compare • Difference • Source
xing194.152.164.4522
View • Compare • Difference • Source
dspt213.184.224.321
View • Compare • Difference • Source
xing194.152.164.4520
View • Compare • Difference • Source
xing194.152.164.4519
View • Compare • Difference • Source
xing194.152.164.4518
View • Compare • Difference • Source
xing194.152.164.4517
View • Compare • Difference • Source
xing194.152.164.4516
View • Compare • Difference • Source
xing194.152.164.4515
View • Compare • Difference • Source
dspt217.21.50.16714
View • Compare • Difference • Source
dspt213.184.224.37
View • Compare • Difference • Source
dspt213.184.224.34
View • Compare • Difference • Source