[list: this was originally a personal answer to Gavin, but as it has general interest information I'm CC to dillo-dev. It's about a browser comparison article. ] Gavin,

[...] Thanks, I saw a few of these. I will check out the wording etc. Mine might not be so in depth, more of a general features thing. But there will be figures ie load times etc. which I am sure yours will win.

:)

Know of any monster sites, that would be a good benchmark for the browsers. I have ADSL, so banwidth shouldn't be an issue.

There're some interesting tests to be done. Which one you choose depends on the time you have, and on what you want to test for. For instance, IMHO, the common "web experience" has four important factors: * Network wait time * Rendering wait time * Time to start seeing content - streamed rendering * Site usability These are key factors; for instance the same site may be unusable depending on whether you're on a dialup or broad band. The same is true for rendering time (influenced by CPU power and available memory); you may end going to some site only when you're sitting at a powerful workstation. The time to start seeing content is also important. If it takes too long, it may exceed the user's patience (there're studies about this). For instance, if a browser needs the whole table to start rendering, some table-based sites will be exceedingly annoying to visit (unless your band-width can mitigate this). The site usability is another key factor. For instance if it's designed for a certain browser, it may be impossible to use with another. Now, getting back to the test suggestions you asked, these points can be isolated. * Network wait time: Get to a site with multiple images, ideally with some coming from other sites. I'm sure you will find a better example for an english speaking audience, but this link illustrates the idea: http://www.lun.com/_portada/contenido.asp * Rendering wait time Very simple, load a semi complex page (like slashdot with comments --a 500KB one), or a large one (as the mysql manual -- I have one which is more than two Megabytes long). Press back, the forward. (you can have some coffee :) * Time to start seeing content - streamed rendering Get to a table-based semi complex page (300Kb-600Kb) and measure the time between asking for the URL and when you can start reading. * Site usability Well, this depends on whether the page respects standards, how broken the site implementation is, the browser's support for the technologies involved, user preferences (javascript may be disabled, same for cookies, a JVM may not be present, same for flash, etc). -- Now that's for having some numbers to show inside a table for people with above the average knowledge about browsers :-) (very interesting, but not massive). Simple usability experience can be explained to less technical people: For instance, take dillo, and dig for something using google. You'll find that the time you use to make different queries and to check for alternative links until you find what you look for is better than with almost anything you've used before. The same is true for browsing local documentation (all of those html files under the /usr/doc or /usr/share/doc directories). This happens because the combined rendering speed and low download time (a filesystem) let you move very quickly, back and forward, make text searches inside the pages, go to another link, saving you lots of time. Going with dillo to any web site is different, if it respects standards (ans so renders OK) its great, but if not, you'll have to resort to a bigger browser. The other important points to consider is to test with different band widths and CPU power. You'll barely notice how fast dillo is on a 2.2 Ghz machine, and if you only test on broad band you'll never know that it's possible to have a good browsing experience with a simple dialup. That's it. Cheers Jorge.-