W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2002

Re: Navigation bars with dynamic content

From: David Woolley <david@djwhome.demon.co.uk>
Date: Wed, 30 Jan 2002 22:26:11 +0000 (GMT)
Message-Id: <200201302226.g0UMQBR19404@djwhome.demon.co.uk>
To: w3c-wai-ig@w3.org
> It may be accessible, but it is certainly not very usable, round trips
> are very expensive, lots of visible links are intimidating, a 10 second

If the actual roundtrip penalty is anything like this, even for slow
modem users, there is something wrong with the site.  Cleanly designed
text pages should display the first line of useful output in about
2 seconds++, even if not cached.  If the page is not cached, the user 
presumably needs to start reading, or at least skimming, from that
first line, and if they know the layout, it is probably already cached.

If you don't get useful output in that time, you've either got an 
overloaded server or are sending loads of scripts and verbose sidebars, or
are using tables and have failed to make them display incrementally.

If most of the time is the actual menu, that is time that was not spent
in sending the main page, making that page more responsive.

> the 200% increase in bandwidth IMO.  You may be happy with that level of

For ten second to end of output, at 33.6k, I suggest you are talking about
40K of page.  If that causes a doubling in bandwidth, it must be almost
entirely scripts, etc. that could have been out of lined into a cachable
file.

If menus are sensibly divided, there should be a net saving in bandwidth
through menus not fetched.

> I've chosen to ignore all this as it is inappropriate garbage, please let
> me know if I should actually take notice, and perform the actions
> specified?

I'm stuck with wording very close to this in the office - note it doesn't
even allow an organisation as addressee.  I no longer post from the office!
Use in this context simply creates a precedent for the assumption that it
was not really meant.

++ 500 ms SYN to SYN ACK; 500ms + serialisation delay for 3,000 bytes (say
600ms) for request to end of response headers and HTML pre-amble.  Total
1.1 seconds.  Add some contigency to get to 2 seconds.  This assumes the
browser isn't making effective use of HTTP keep alive.
Received on Wednesday, 30 January 2002 18:02:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 19 July 2011 18:14:00 GMT