PART II
Chapter 6: Networking Considerations 263
choose if you want to see compressed content or not and performs the fetch using the
XMLHttpRequest object.
Figure 6-19 shows that what you see on screen will be exactly the same content wise,
compressed or not. The beauty of this technology is that it is transparent.
HTTP compression is quite valuable, but there are considerations. First, understand that
to compress content there will be spending some cycles on the Web server. Typically Web
servers—even loaded ones—have many processing cycles to spare as they are usually
network bound far earlier than they are CPU bound. Fortunately, even if the server was to
get into this unlikely situation, most commercial implementations of HTTP compression
will have a CPU roll-off mechanism where they will stop compressing content as heavily or
even at all when the server load hits a critical load. So stop worrying about wasting CPU
cycles and put them to good compressing use.
However, even if the server has plenty of computing power to spare, there is another
important impact to consider: the difference between “time to first byte” (TTFB) and “time to
last byte” (TTLB) with and without compression. If content is being compressed, there may
be a slight delay before the first bytes makes it to the client—in other words, the TTFB will be
greater, but since there is much less content the TTLB should be much faster. For long latency
folks such as dial-up users, the difference will be very noticeable, with compressed pages
serving much faster. For low-latency high speed users, the TTFB will be longer, but since this
will generally be in the sub one second range it will not be felt in most cases.
Given the potential for delay for a high-speed user, you might wonder why someone
would chance it with HTTP compression. The answer is quite simple: bandwidth costsFIGURE 6-19 HTTP compression is transparent to end users