On Thu, Sep 24, 2009 at 12:49 PM, Tim Starling <tstarl...@wikimedia.org> wrote: > It's not really as simple as that. The major browsers use concurrency > as a substitute for pipelining. Instead of queueing up multiple > requests in a single TCP connection and then waiting, they queue up > multiple requests in multiple connections and then wait. The effect is > very similar in terms of RTTs.
Except that even on a page with 30 or 40 includes, the number of concurrent requests will typically be something like 4 or 8, so RTT becomes a huge issue if you have lots of includes. Not to mention that most browsers before very recently won't do concurrency at all for scripts -- script loads block parsing, so no new requests start when a script is still loading or executing. If you're talking about cutting four includes down to one, then maybe the benefit would be insignificant or even negative, but if you're talking about cutting 30 includes down to ten, AFAIK the benefit just from RTT should swamp all other considerations. This is why Yahoo!'s #1 rule for good front-end performance is "Minimize HTTP Requests": http://developer.yahoo.com/performance/rules.html > you can see that the concurrent case would be faster when > the RTT is very long, the number of objects is large, the number of > connections is equally large This last point is the major failure here. If browsers really requested everything in parallel, then we wouldn't need any of these hacks -- not combining, not spriting. But they don't, they request very few things in parallel. > There is a potential reduction in RTT count due to concatenation, > that's why I included that item on the list. But it's client-dependent > and might not exist at all in the most common case. AFAIK this is not true in practice. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
