In the Internet, much useful information is retrieved from a long way away - that is part of its attraction (it is expensive to get using an alternative material approach).
However, this means that TCP connections between clients and servers traverse long haul networks. TCP is cleverly designed to avoid congestion (network overload). It has a built in conservatism: in the face of packet loss, it assumes that there are other (existing or new) users sharing the network. It therefore backs-off, reducing its sending rate radically (in fact to the minimum effective sending rate conceivable, which is one packet per round-trip-time). It then increases this sending rate until around 1/2 the previous rate which had no loss. It then very slowly increases its sending rate, until it finds what is called a "stable operating point", where a single increase may cause a small problem, but not enough to warrant backing right down again.. This approach is called Congestion Avoidance and Slow-Start, and is known as the "linear-increase, exponential-decrease" approach to traffic control. It was devised by Van Jacobson in the late 1980s in response to real network problems.
Now, in the absence of any other knowledge, a new TCP connection must start as it means to go on: slowly. This means that when retrieving a page with a large number of separate calls, a number of "slow-starts" operate, even when there are no other network users, and there is no apparent reason to operate these. This causes very jerky response to the client program. Unfortunately, this protocol usage is built right through the stack of protocols between the client, the libWWW, and the use of TCP, right through to the semantics of server access.
One way forward would be to not close the connection between the client and server between one HTTP request and the next: since the server end closes the connection (due to the stateless model described in chapter 3), this would entail some extra protocol (at least a marker in the stream from the server to the client to inform it of "End of Response". The server should then operate a timeout to prevent clients that die tying up connection resources in the TCP/IP protocol data space.
In fact, a recent modification to TCP [RFC 1644] specifies an extension that means that TCP can use less packets for short exchanges of messages (as RCP and LibWWW and HTTP tend to], and can cache information concerning the network performance between one connection and a subsequent one to the same destination. This may well solve a lot of these problems when widely deployed.