I recommend before you start reading this blog please go through our blog on Web Caching

Output Caching

With output caching, the final rendered HTML of the page is cached. When the same page is requested again, the control systems are not created, the page life cycle doesn’t start, and none of the code executes. Instead the cached HTML is served. Clearly output caching gets the theoretical maximum performance increase, because all the overhead of the code is side stepped.

Client side Caching

One of the cache options is to store the page exclusively on the client side. In this case the browser stores a copy and will automatically use this page if the client browses back to the page or retypes the page’s URL. However if the user clicks the refresh button, the cached copy will be abandoned and the page will be re-requested from the server, which will run the appropriate page code once again.

Client side caching is less common than server-side caching because the page is still re-created for every separate user and would not reduce code execution or database access nearly as dramatically as server-side caching (which shares a single copy among all users). However client side caching can be a useful technique if the cached page uses some sort of personalized data. Even though each user is in a separate session, the page will be created only once and reused for all clients, ensuring that most will receive the wrong greeting. Instead it can either use fragment caching to cache the generic portion of the page or use client side caching to store a user specific version on each client’s computer.

Multiple version Caching

One of the main considerations in caching is deciding when a page can be reused and when information must be accurate up to the last second. Developers, with their love of instant gratification (and lack of patience) generally tend to overemphasize the importance of real time information. We can usually use caching to efficiently reuse slightly stale data without a problem and with a considerable performance improvement.

Sometimes information needs to be dynamic. eg., if the page uses information from the current user’s session to tailor the user interface. In this case, full page caching just isn’t appropriate because the same page cannot be reused for requests from different users. Likewise is the case when the page is receiving information from another page through the URL query string. Again the page becomes too dynamic to cache.

In these cases of consideration, the cache server creates different versions of the same page based on different criteria (like URL query string). Now when we request a page with additional information, the cache engine examines the information. If the parameter matches a previous request and a cached copy of that page exists, it will be reused, else a new copy of the page will created and cached separately.

Output caching works well if the pages depend only on server-side data and data in URL query string. However this does not work if the page output depends on user specific information such as session data or cookies as there is no way to vary caching based on these criteria. Output caching also won’t work with dynamic pages that change their content in response to control events. In such scenarios data caching can perform more effectively to cache specific information.