This is an interesting discussion of HTTP caching, but is not the first step in scaling a web site. Not the second or third even. The first step in scaling a site like that, with various boxes full of information expiring at varying periods of time, is PROFILING.
PROFILE before optimization. Premature optimization is a bad thing.
Most of the time is spent rendering the page. Most people come to you with an empty cache. Why is Cinema Treasures loading dozens of jQuery javascript files from a handful of different domains? Such a waste of user time. Concatenate as much as you can, and serve it off of a CDN.
See what takes a long time to render. See what pages are most popular. Save the most user-time per engineering hour you can.
None of the things you mention relate to scaling. Scaling is taking the site which is functional for at least one user and ensuring that it can be used by many users concurrently. By definition, client side performance doesn't affect scaling.
Profiling is one of the important parts of Scaling as well.
The Military uses the OODA (Observe-Orient-Decide-Act) loop. I think this is the right approach for performance issues (both latency and scalability.) Profiling, monitoring, load analysis and systems analysis all play a part in the "Observe" step.
The other reason to profile is that it gives you a baseline for comparison so you know if you are making improvements.
Improving page rendering speed can also benefit server a lot.
If done properly server would have to answer one request for Javascript file, and none on repeated requests. Now it has to answer 13 requests no matter what (3 scripts are loaded from third party servers).
Similarly after optimizing CSS images server would have to server much less traffic (and maybe fewer requests). Footer.gif and subnav.gif together take about 200KB now, but the size can be cut in half just by switching to PNG. Remaking the background with repeated images and some cicada pattern for noise should let to cut the size tenfold.
Tweetie.png can be less than 2KB without losing quality — that's 15x less.
Photos are served from different domain (good), bet those small jpegs are still way too big file-size wise. I guess they are produced automatically, but it would be worth to have some additional optimization for them — that alone would allow to cut the size of each about tenfold too.
You are rightto some extend, however serving static content is much faster than serving a dynamic request that needs to generate a response on the fly. Before optimizing the assets, improving the caching strategy and async rendering will yield a better throughput must faster than tweaking the CSS, JS and other assets. That said you are right, this is something that will improve page rendering time, client side and to some extend the overall throughput.
@Isb You have a good point about profiling and asset management but you are talking about performance on the client side (browser) not scaling as in increasing the throughput. There are a lot of improvements which can be made to improve the page rendering speed but that won't help if you see a traffic peak.
Maybe, but it's the client spending that time, not the server. It's largely a separate issue from what it is being discussed here.
Save the most user-time per engineering hour you can.
If your server can handle 100 requests a second and you know you're soon going to be receiving 1000 requests per second, it makes more sense to address that with HTTP caching than twiddle with your javascript includes. A browser can't render a page that the server is too overloaded to send.
ESI, as it's already been pointed out, is one big way. I tend to not like requiring JS to make my pages usable, as not everyone has JS turned on and it's ability to work correctly in non-mainstream browsers, while improving, can be spotty.
Really, if most pages on your site are identical for every user, sans their name + avatar at the top, it's worth figuring out a strategy to serve the page content from disk and swap in the dynamic parts easily without hitting your app layer.
PROFILE before optimization. Premature optimization is a bad thing.
Most of the time is spent rendering the page. Most people come to you with an empty cache. Why is Cinema Treasures loading dozens of jQuery javascript files from a handful of different domains? Such a waste of user time. Concatenate as much as you can, and serve it off of a CDN.
See what takes a long time to render. See what pages are most popular. Save the most user-time per engineering hour you can.