Traditional architecture was layered on top of a six-pack: two web servers, two service servers, db and failover.  The DB became the bottleneck and caching was introduced.   Caches are hard to scale-out and can cause even more exasperating concurrency issues.  Caching didn't turn out to be a silver bullet.  We moved away from in-process caching towards some more explicit caching (like Redis).  One problem: the amount of data is going to grow faster than the amount of memory you have in your caching servers.  So, you have cache invalidation.   Caching can actually degrade performance under higher loads as the hit rate erodes and memory runs out.   If you cache, pay attention to your hit rate.   **Content Delivery Network**  
Great for off-loading static content.  Images, JS, css, etc.  Learn and leverage DNS!  Don't use a smart donkey when a heavy ox is what you need.  Don't make your web app smarter, when the heavy ox (the web) can be utilized to take part in your web application.   HTTP output caching--IIS will cache the HTML output and serve the binary data immediately without re-rendering a page.   Get information from the business on what things need to be refreshed quickly and what things don't need to be updated all that quickly.  Help them realize that if _everything_ is fast, then nothing will be fast.     A real cache doesn't even hit the controller.  It's at the web server level.  Model your site as a collection of static resources.  Your navigation is Nav.xml (or html or whatever).  They all just have varying times-to-live and can even be deployed to CDNs.   The web was designed around the concept that storage is cheaper than bandwidth.  So, caching is everywhere (browser, CDNs, output caches, etc).  There's an ISP cache too.
 
- Browser

ISP  
CDN

- Output cache

In-memory caches

- Fresh request
 The "free" caching of the internet is our heavy ox.   Think of this way: a user who finally arrives at your website after having traipsed across the vast desert of the internet checking cache after cache for fresh data, is dying for fresh data.  Is that the right place to then serve up stale cached data??   If you are building a site that very local.  Let's say for dog owners in Dallas.  Then, the heavy ox of the web caching system won't help.  It might hurt actually because you'll send users further away from your site to get static content.  That's when you might need caching more.   Communicate with your ops people that as your site is live over time, fewer and fewer web requests will hit your servers over time.  Otherwise, this can be a concerning sign, "we're not getting any hits!". Explain that, with the caching of the 'net, this is normal.   Of course, the helpful thing here is client-side composition.  Browsers can often work better and faster with multiple requests at once (client-side composition).  This is not true for mobile browsers.  Battery life is more important there and so one bigger request is probably more important.   **Personalization**  
Not all data is global data.  Weather widgets are good examples.  This is local weather for the user.  Personalized information is still scalable and internet-cacheable when we do the deep analysis.