Back to index
Network
Performance Effects of HTTP/1.1, CSS1, and PNG
Henrik Frystyk Nielsen, Jim Gettys, Anselm Baird-Smith, Eric
Prud'hommeaux, Hakon Wium Lie, Chris Lilley, W3C and elsewhere
One-line summary:
Application-level HTTP request pipelining (using "keep-alive" or
persistent HTTP), transport level compression, use of style sheets
instead of "GIF text buttons", affords only a modest increase
in performance (and, in this reviewer's opinion, is a band-aid over
HTTP's egregious
violation of the end-to-end argument).
Overview/Main Points
- HTTP/1.1 pipelining: software-pipeline the requests to same
server using keepalive.
- CSS: use text and style sheets instead of "GIF text buttons".
- PNG: Portable Network Graphics, a somewhat better format than
GIF.
- Net effect of pipelining is a savings of at most 30-40% compared
to HTTP/1.0; usually savings is much less. Most pronounced
savings on high bandwidth-delay product networks.
- Transport compression ("Content-encoding: deflate", i.e. running
gzip on HTML) buys another 15% or so.
- Extensive hacks to client (Perl script) and somewhat fewer hacks
to server (Apache) took about 4 person-months.
- State machine on client for keepalive is a mess; server can shut
down connection at any time, client must know what do with
requests that were issued but never acknowledged; etc. Not
really appropriate for small clients (where it is most needed!)
- Style sheets: not surprisingly, in many cases a style-sheet
description is better than a "GIF text button" (but not in all
cases; CSS1 is pretty verbose) and clearly better from a metadata
perspective.
- Some bullet-type icons could be converted into CSS1 or PNG
predefined glyphs (Wink does something like this in their
authoring tool). Byte savings is small, but savings in HTTP
overhead is huge. ("The best HTTP connection is the one that
does not exist") Most of these estimates are extrapolations;
CSS1 and PNG are not widely deployed and lack some of the
capabilities presupposed by the examples given.
Relevance
No surprises here, but as the "last mile" gets better and better (and
less expensive per MB/sec relative to long-haul capacity), HTTP effects
will get worse and worse. Keepalive and P-HTTP are a mess that expose
HTTP/1.0's egregious violation of the end-to-end argument and its abuse
of TCP.
Flaws
Why the hell isn't anyone doing a good proxy-keepalive? This would
solve all of the problems described here, and more besides. This is an
area where perhaps we should try to do something with W3C (gack).
Back to index