Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making browsers faster: Resource Packages

limi.net

Post reply on HN
Print view View original

11–18 of 18 posts

Re: Making browsers faster: Resource Packages

#11

Post by djcapelis »

sutro wrote: post #5

This is a very good, very pragmatic idea.

It is, but I'm of the opinion that HTTP needs more than pragmatism to solve its woes at the moment.

The latency issue with the protocol is just immense and this takes a whack at a main issue, but doesn't quite get to where it should. One of the main drawbacks is you still have to wait for the first reply before you can request any associated content, which is bigger deal than it seems. The second drawback is it requires the website owner to do this by hand and invariably they'll bundle things in the wrong way, not account for differing network bandwidth types or simply not do it.

That said, for some very good reasons, this is good direction, so we'll see what happens.

Re: Making browsers faster: Resource Packages

#12

Post by patio11 »

joeyh wrote: post #6

This seems like a fairly gratuitous workaround for IIS not properly supporting HTTP pipelining. But, bonus irony points for using .zip to implement it. (.rar would be even more ironlicious.)

It is more like a work-around for RFC2616, the HTTP 1.1 spec, which says that compliant clients SHOULD NOT make more than 2 simultaneous connections to one server. This interacts rather poorly with modern sites, which may well need to load 50+ files on a single page view.

Much of the YSlow recommendations center on various ways of getting around this limitation -- for example, using multiple redundant domains (images1.example.org, images2.example.org... permitting you to do 2*N downloads in parallel instead of 2), putting all your CSS/JS in one file, image spriting, etc etc.

Re: Making browsers faster: Resource Packages

#13

Post by Gumboot »

joeyh wrote: post #6

This seems like a fairly gratuitous workaround for IIS not properly supporting HTTP pipelining. But, bonus irony points for using .zip to implement it. (.rar would be even more ironlicious.)

As far as I can tell IIS supports pipelining just fine since version 6 (2003). See http://en.wikipedia.org/wiki/HTTP_pipelining

Re: Making browsers faster: Resource Packages

#14

Post by Veera »

Good Idea.

But what if the user just visit only one page of the website and leaves the page immediately (such as traffic generated from search engines) ? In this scenario, the resource package required for the entire site will be downloaded just for showing one page!

Re: Making browsers faster: Resource Packages

#15

Post by loup-vaillant »

Veera wrote: post #14

Good Idea. But what if the user just visit only one page of the website and leaves the page immediately (such as traffic generated from search engines) ? In this scenario, the resource package required for the entire site will be downloaded just for showing one page!

Often, the majority of the resources (css, background images…) is required for rendering any page. So I don't think it will be a problem most of the time, and fits their 80-20 goal.

Re: Making browsers faster: Resource Packages

#16

Post by jerf »

djcapelis wrote: post #10
jerf wrote: post #4

Seems like a better idea would be to just have the server aggressively shove resources down the wire much like standard HTTP pipelining, except where the server doesn't wait for the client to request them. Have the client send a flag up saying it's willing to accept this in the initial request. You get much the same effect, only without adding ZIP files to the mix. You also get the ability to have proper headers on e…

The naive implementation of this ruins all the elegance of caching which is very important in modern websites. You end up choosing between getting all the common elements shoved down the wire at you every time or invariably having to go back for the few images unique to the page that you missed. We're in the middle of a research projects right now where the server automatically constructs cache groups and does this p…

In my model, the webserver knows what the "extra few images" are and could send them to you as part of the first burst. First-order caching (no proxying, just server and client) can be handled by having the client also smart enough to send up all the caching info at once.

How to handle proxy caches cleanly isn't immediately obvious to me, but there's far more tools with this approach than the zip file approach. Certainly with work I think it could be solved. Again, to a first order, the proxy would have to accept this style too and do something intelligent with it; an old-style proxy would fall back on the current system.

It is not clear to me: Are you the one proposing this zip file thing, or someone in another group that is working on this? If the latter, I wouldn't mind seeing a link, perhaps even submitted to HN.

Re: Making browsers faster: Resource Packages

#17

Post by sutro »

djcapelis wrote: post #11
sutro wrote: post #5

This is a very good, very pragmatic idea.

It is, but I'm of the opinion that HTTP needs more than pragmatism to solve its woes at the moment. The latency issue with the protocol is just immense and this takes a whack at a main issue, but doesn't quite get to where it should. One of the main drawbacks is you still have to wait for the first reply before you can request any associated content, which is bigger deal than it seems. The second drawback is it requi…

The author has knowingly traded off technical style points for practical ones, a tradeoff I applaud. So often the opposite choice is made, resulting in beautiful little laboratory experiments that have little relevance in the real world.

Re: Making browsers faster: Resource Packages

#18

Post by djcapelis »

jerf wrote: post #16
djcapelis wrote: post #10

Earlier quoted context omitted.

The naive implementation of this ruins all the elegance of caching which is very important in modern websites. You end up choosing between getting all the common elements shoved down the wire at you every time or invariably having to go back for the few images unique to the page that you missed. We're in the middle of a research projects right now where the server automatically constructs cache groups and does this p…

In my model, the webserver knows what the "extra few images" are and could send them to you as part of the first burst. First-order caching (no proxying, just server and client) can be handled by having the client also smart enough to send up all the caching info at once. How to handle proxy caches cleanly isn't immediately obvious to me, but there's far more tools with this approach than the zip file approach. Certa…

I'm in a completely separate group in a completely separate place who happens to have seen this link before. We haven't done anything worth linking to yet, just have a little bit of knowledge about this area since we've been looking at it as well.

What you're saying is close to what we've been looking at trying to turn into code. I think the proxy thing is a non-issue. In fact a proxy in many ways could implement a portion of the server-side smartness and accelerate conforming clients on websites that don't implement this.

These are some larger issues though, I think:

1) Making the server smart enough to actually do this.

2) Sending the resources in the right order (It turns out the order things go down the line can be significant and this is something that can vary depending on which web rendering engine your user has.)

3) This requires changes to HTTP, unlike the linked proposal, so one needs a way to do it right and a compact representation of the cache information.

Post reply on HN