bash$ wc bs_virtual_author.css
4759 9256 160091 bs_virtual_author.css
At least I know where the problem is now.
Saturday, March 12, 2005
Bodington and Safari load times.
At the moment most users of Bodington are advised to use either Internet Explorer or a Gecko based browser (Firefox, Mozilla) for best results. Although this is ok for most people it doesn't reflect well on the software that we can't be bothered to support people with smaller market shares. It's not that Bodington doesn't work full stop with other browsers, it just doesn't work very well. As I mentioned in my last post popups didn't work on Safari, but as well Safari has very long page load times with using Bodington.
Being a Mac user at home I thought I'd spend a little time looking at this. Now the page load time only seemed to get bad once you were logged in (in the 3 frame layout). When I say bad I mean about 13 seconds from making the request to getting the fully rendered frameset back, in comparison Firefox on the same machine takes about 3 seconds (still not good). During this wait the processor always seemed to be working hard so I didn't think it was a networking problem. Now I do my development on a 1Ghz iBook so I'm not running on antique hardware but I was running Bodington on the same machine and Java on Macs isn't fast (Java on i386 is) so I used Firefox to save the entire frameset to the local machine to eliminate the time taken to generate the page. It seem that Firefox doesn't correctly adjust the CSS links when downloading so when I tried to view the page on the local machine I didn't have any CSS rendering.
Although to my supprise the rendering was almost immediate in both Firefox and Safari. Correcting the relative CSS links to all three framesets gave me back the long page load times so it seem that the CSS parsing/rendering engine in Safari isn't anywhere near as good in terms of performance as Firefoxs'. In some ways I can understand, currently the same CSS that is used in all three framesets is over 4000 lines: