Brett_Tabke - 10:28 am on Jun 14, 2000 (gmt 0)

re: css and page building for browsers (from another forum).

Basing page building on suspect browser stats is risky. With the advent of bigoted sites doing browser sniffing, the mass majority of the 3rd party browser people have switched their agent name to match ie or nn. Either through a ad cacher like junkbusters or nearsite, or a host of other options. Add in the fact that most statistics programs don't properly identify all browsers, and most of them are off 20%.

It is like stat market reporting that 85% of the net uses ie, and 14% use nn. If they can be that wrong about a simple browser statistic, their entire system is junk data and not to be trusted.

I always get a kick out of the occasional comment along the lines: "I write Zhtml for the Zhtml browser, and my stats show that 95% of my hits come from the Zhtml browser. The other 5% only visit one page. I'm on the right track with Zhtml because my stats prove it!".

When I do browser/page testing, I do the on/off thing. Turn it on for a day then off for a day. Then do the same thing next week in reverse.

Some of my own recent tests (min 500k unique): cpu=click per user (which is the important stat when page testing for browsers).
Turn on a moderate external css: cpu drops by almost 10%. Like flipping a light switch (hmm, why?). Tests done with the w3c core style sheets custom delivered for each agent.
Banner ads: turn them on (non js) cpu drops by 5-8%.
Banner ads: on with js (rich media) cpu drops by 13-15%.
Minimum non intrusive js, cpu drops by 5%.
Heavy unfettered large complicated js, cpu drops by almost 20% (especialy if you base navigation on the js).
Specific IE dhtml navigation: cpu down by more than 25% (I couldn't stand it, I turned it off after seeing 15k hits in the stats - that figure is probably substantially higher).
Java applets. We tried two for 50k uniques on an ecom site. Only 62% of the uniques actually dl'd either of the applets. Stats after that are inconclusive. We saw a bump in the cpu for users that did get the applet, but cpu for those that didn't were down. So it was kind of a push. Never investigated further.

We did the same tests in january and last october and there have been some shifts. The biggest change we have seen is that banner ads don't have quite the negative impact on cpu that they once did. However; banners per unique have fallen with more and more people using banner busters.

The css impact is also falling. Last fall we saw cpu drop by almost 15% when we'd turn it on. Don't know whether that is indicative of people turning off css at the browser level, better browser support, or just what the deal is there - can't decide. There doesn't appear to have been any major shifts in browser usage in the last 9 months except for the continuing ie creep.