- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 16 May 2012 13:26:21 -0700
- To: Jacob Mather <jmather@itsmajax.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Henri Sivonen <hsivonen@iki.fi>, Matthew Wilcox <mail@matthewwilcox.com>, PJ McCormick <pj@mynameispj.com>
On Wed, May 16, 2012 at 12:33 PM, Jacob Mather <jmather@itsmajax.com> wrote: > On Wed, May 16, 2012 at 3:26 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >> On Wed, May 16, 2012 at 12:12 PM, Jacob Mather <jmather@itsmajax.com> wrote: >>> Maybe this is the better question: >>> >>> Why does the pre-loader matter so much? >> >> Because it lets pages load faster. >> > > Sure, but s that enough to make for a massive pile of junk-work to do > whenever a site is redesigned? > > Could this not be better addressed through better/faster css > processing? There would still be more of a delay, but I'm just trying > to say that the trade-offs could be more than worth it. There are limits to what you can do, unfortunately. No matter how fast your CSS parsing is, your CSS file should be external, which means you have to make a request for the CSS file, wait for it to finish, *then* parse the CSS and figure out what images to request. That indirection is necessary for good, maintainable design, but it's murder for page load speed. This is an unresolvable conflict right now, given the design of HTTP. SPDY can help us fix this - the server can proactively start pushing resources at the client that it knows will be needed for the page, instead of waiting for the client to realize that it's needed and make a request. SPDY is developing nicely (and I think is becoming HTTP 2.0?), so this'll happen in the future, but for now we still have a tradeoff. ~TJ
Received on Wednesday, 16 May 2012 20:27:14 UTC