2010/8/11 Tei <oscar.vives(a)gmail.com>om>:
1)
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"?
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?
4)
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)