Making browsers faster: Resource Packages
1–10 of 18 posts
Re: Making browsers faster: Resource Packages
#2"While this effort [SPDY] from Google aims to make everything faster, it is largely orthogonal to what we’re trying to do with Resource Package."
Seems to solve the same problem, though, but without the headache of rewriting everything.
Re: Making browsers faster: Resource Packages
#3"While this effort [SPDY] from Google aims to make everything faster, it is largely orthogonal to what we’re trying to do with Resource Package." Seems to solve the same problem, though, but without the headache of rewriting everything.
I think he means orthogonal here in the sense of complementary. SPDY + resource packages may be faster than either individually.
Re: Making browsers faster: Resource Packages
#4Seems 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 each element; this solves every "Additional Note" they mention. Some obvious extensions involve things like sending up all the E-Tags the client knows about in the first request. I think it's a lot simpler than their approach and retains more of HTTP. Yeah, it's slightly less bandwidth efficient (though to make the difference large you need pathological examples), but I think it's worth it.
Re: Making browsers faster: Resource Packages
#5This is a very good, very pragmatic idea.
Re: Making browsers faster: Resource Packages
#6This 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.)
Re: Making browsers faster: Resource Packages
#7An earlier Google proposal for faster page-loading -- still active in Toolbar for IE AFAIK -- was "Shared Dictionary Compression over HTTP" (SDCH):
http://sdch.googlegroups.com/web/Shared_Dictionary_Compressi...
http://groups.google.com/group/SDCH
In some ways a custom-dictionary-per-page-group would be a lot like a resource-package-per-page-group.
Re: Making browsers faster: Resource Packages
#8The could include a secure hash of the package contents -- so that it could be loaded from a less-reliable or less-trusted channel than the referencing page. (For example, small page from uncacheable HTTPS, bulk package from edge-cacheable HTTP or P2P.)
Re: Making browsers faster: Resource Packages
#9"While this effort [SPDY] from Google aims to make everything faster, it is largely orthogonal to what we’re trying to do with Resource Package." Seems to solve the same problem, though, but without the headache of rewriting everything.
I think he means orthogonal here in the sense of complementary. SPDY + resource packages may be faster than either individually.
can you explain ? both try to minimize the number of tcp connection and thus avoid the slow start at every http requests.
spdy got the advantages of being a dropped in solution, aka you push the layer in the browser, and in the server. But no change in the website itself.
"resource packages" requires changes in the browser and at web site level.
Re: Making browsers faster: Resource Packages
#10Seems 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 properly. It was one of the things the guys working on spdy and us talked about, but they are taking a slightly different approach.
We'll see what happens, but this is the direction we want to move as well.