Looks like it was built with ASP.NET MVC 4, which has minification and bundling built in. Should be easy for them to take advantage of it... maybe they just ran out of time or don't care.
The bundling features in ASP.NET MVC 4 were at best release candidate and at worst beta until mid summer. I can see why using them may have made some developer's leery. Adding these features now as indicated by several other commentators should not be difficult.
We recently moved to GitHub Enterprise and it really is not as expensive as it looks. It is $250/year per developer... not really that much considering what you get. Plus it is a virtual server provided for us, so we just have to upload software upgrade packages to get the latest updates. We didn't have to spend the money on someone to set up all of the MySql, Redis, Solr, etc. services to get it running. So honestly I consider GitHub Enterprise to be quite a cost savings. Just a counterpoint...
EDIT: We are not a startup, but still something to consider.
I know you say that in jest, but I would say that it is still good to know the underlying technology. It is much easier to debug issues in the future once you understand them.
Concur - I think that, once you have a certain amount of experience built up working in frameworks like Rails, you can only go so far before you hit a wall. At that point, it's necessary to start learning the protocols and the lower level stuff to advance your understanding and your craft.
This is actually referenced in the article. You can use the Last-Modified date and the server will either return a 304 (Not Modified) or the modified image if it is newer.
I read that, but if you say "this image won't change for exactly one year" and the client doesn't even request that resource from the server any more, how do you start that dialogue again?
pork has offered that you add a junk parameter to the end of a GET request and that should disrupt the cache, I'll need to read in to this. I'm interested in optimizing web speed as much as possible and this sort of thing and caching has always been something I've understood poorly.
Yep, that's the problem with long expiration dates -- the client may never check again (that's what we wanted, right?). The workaround is to request a new url which restarts the process.
Separately, the easiest way to get started with all these optimizations is to run the page speed check online:
I've actually been playing around with this stuff all day, pretty much since my last comment above. I've enabled smarter caching on my website, replaced multiple image requests with a single spritesheet, optimized my images, and cleaned up my CSS file to remove unused code. Google's PageSpeed has been an invaluable tool, as well as webpagetest.org which breaks down the data in an intelligent way.
Turns out Google Analytics is actually doubling my page load time, but the data is too valuable to give up.
This is why we use QA servers for most of our systems. We try our best to test all functionality on a patched QA server before deploying patches to our production servers. We have had good success doing this (with Windows at least.)
