History of Speed optimisation
Version 7 | Current version | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
introductionso 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 webpageanalyzerMain Wiki Page of bw gets analyzed At the time of writing this page, the statistics were:
Download Times
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:
mind HTTP reqiests: combine and packin short "the less requests the better".
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 IE6There 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.
image optimisationMy 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 layoutCurrent 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 compressionBW 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. | IntroductionBitweaver 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:
In 2010 (May 31), this becomes
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
eliminate extra HTTP requests
Image optimisationOther compression
ComparisonsWeb Page Analyzer (04/2006)To compare bitweaver with other content management systems, pass their main pages through websiteoptimization.com's analyzer:
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.
|