Having a client that can be downloaded directly into the browser creates many additional optimization opportunities of the HTTP protocol. For example, based on the response time perceived by a client, the server may compress not only the content of the header containing the URL binding information, but the entire resource. The resource is decompressed by the receiving client applet. Similarly, since the server substitutes all references to embedded resources (following the <SRC> HTML tag), it can transmit to the client not only the requested resource, but also all resources embedded in it in a single response (the embedded resources are typically located on the same server). The client must be able to exclude from transmission the resources that are already cached in its local cache.
Such a ``batch transmission'' leads to considerable savings since most commercial Web pages contain 20 to 40 embedded images. Following standard HTTP, the browser parses the containing HTML resource and sends separate GET request for each of the embedded resources. Most browsers reduce the total retrieval time by sending 4 to 5 requests in parallel and reusing the TCP connections [34]. However, even with such optimizations, downloading a typical Web page leads to at least 4 to 5 GET request rounds. The batch transmission method reduces the entire process into a single round with a large response.
Batch transmission is implemented in our Web++ prototype and we are in the process of evaluating its impact on the response time perceived by browser users as well as the number of IP packets transmitted. Our preliminary results indicate that for clients connected to Internet over a fast T3 line, batch loading can reduce the response time by additional 40% to 52% (depending on the number and size of the embedded resources and the distance between the client and server). We also found the saving is much smaller for clients connected over a 56 kbps modem and a phone line (between 13% and 16%), because such clients are mostly limited by the phone line bandwidth, and not by the communication latency.