2010/8/11 Tei oscar.vives@gmail.com:
This is not a website "http://en.wikipedia.org", is a redirection to this: http://en.wikipedia.org/wiki/Main_Page Can't "http://en.wikipedia.org/wiki/Main_Page" be served from "http://en.wikipedia.org%22?
Wait.. this will break relative links on the frontpage, but.. these are absolute! <a href="/wiki/Wikipedia" title="Wikipedia">Wikipedia</a>
That would get complicated with Squid cache AFAIK. One redirect (which is also a 301 Moved Permanently, which means clients may cache the redirect destination) isn't that bad, right?
A bunch of js files!, and load one after another, secuential. This is worse than a C program written to a file from disk reading byte by byte. !! Combining will probably save a lot. Or using a strategy to force the browser to concurrent download + lineal execute, these files.
I'll quote my own post from this thread:
The resourceloader branch contains work in progress on aggressively combining and minifying JavaScript and CSS. The mapping of one resource = one file will be preserved, but the mapping of one resource = one REQUEST will die: it'll be possible, and encouraged, to obtain multiple resources in one request.
We're aware of this problem, or we wouldn't be spending paid developers' time on this resource loader project.
You guys want to make this faster with cache optimization. But maybe is not bandwith the problem, but latency. Latency accumulate even with HEAD request that result in 302. All the 302 in the world will not make the page feel smooth, if already acummulate into 3+ seconds territory. ...Or I am wrong?
I'm assuming you mean 304 (Not Modified)? 302 (Found) means the same as 301 except it's not cacheable.
We're not intending to do many requests resulting in 304s, we're intending on reducing the number of requests made and on keeping the long client-side cache expiry times (Cache-Control: maxage=largenumber) that we already use.
Roan Kattouw (Catrope)