Download Time: Packet Count versus Page Size

After you've optimized your images for size and grouped them (or better yet, replaced them with text and CSS), there is one more thing you can do: Fit them into packet- sized chunks . Keep in mind that this is an extreme technique to be used only if you want to achieve the absolute maximum speed for your pages.

As a packet-based network, the Internet is designed for redundancy and reliability. Resources are divided into packets and routed to their destination, where they are reassembled. If a backhoe severs a fiber- optic line somewhere in New Jersey, the packets happily reroute themselves around the problem.

Packet sizes are negotiated between browser and server at connection time. The maximum transmission unit (MTU), or the size of a packet, is typically between 576 and 1,500 bytes depending on connection speed. On low-speed connections (less than 56Kbps) in older machines, packet sizes can be 576 bytes and higher. For low-speed connections, multithreading is a minor factor for performance tuning. In this case, total page size and the number and size of external objects (including graphics) determines download speed.

On faster connections (more than 128Kbps), it is the total number of TCP/IP packets (typically 1,500 bytes) that your content takes to send that directly affects download time. With low-speed connections, the pipe usually is filled and browser threads are few. For higher-speed connections, the pipe usually is not fully utilized, and you can keep more browser threads active. The limit then becomes not the pipe, but how many packets you can send with how many threads. However, even on unrestricted lines, "the benefits of multithreading are eventually outweighed as the number of imagesand thus the likelihood of complications increases ." ^[14]

^[14] Jing Zhi, "Web Page Design and Download Time," CMG Journal of Computer Resource Management , no. 102 (2001): 4055. Available from the Internet at http://www.keynote.com/solutions/assets/applets/Web_Page_Design_and_Download_Time.pdf. Zhi, of Keynote Systems, found that for fast connections (> 128Kbps) after TCP slow start, download time is nearly linearly related to the number of packets sent, which is determined by the size of each file and packet size. Four or more equal-sized images downloaded faster than one large image due to browser multithreading. For slower connections, download time was dependent on total content size and the number of objects.

With a TCP/IP overhead of 40 bytes, this gives an effective payload of 1,460 bytes for each packet for faster connections. When a server first answers a client request, the HTTP response header adds another 250 to 300 bytes. So the first packet sent for each object is around 1,160 to 1,210 bytes, while subsequent packets are 1,460 bytes in size. Zhi found that for higher-speed connections, it is the number of packets sentnot content sizethat is a better determinant of download speed.

Try to reduce each graphic (or external file) to fit into one or more packet multiples . On higher-speed connections, files larger than around 1,160 bytes will "spill over" into the next packet, requiring twice the time to send, even though they may be only a few percent larger. So keep packet size in mind while you are designing graphics and external objects like .js and .css files. This dependence on packet count versus page size will become more important as bandwidth inevitably increases.

The best strategy is to minimize HTTP overhead (which can be substantial) by minimizing the overall size of your page and the number and size of embedded external objects.