Caching in Web Forms

Caching stores the result of expensive work — a database query, a rendered page fragment, a computed report — in memory so subsequent requests can reuse it instead of redoing that work from scratch. Classic Web Forms offers caching at several levels: output caching stores the fully rendered HTML of a page or user control, data caching via the Cache API stores arbitrary objects like a DataTable or a List<T>, and fragment caching applies output caching to just one user control on an otherwise dynamic page. Choosing the right level matters: caching an entire page is powerful but only works if the whole page is the same for every visitor, while data caching is more surgical, letting you reuse a slow query's result while still rendering personalized markup around it.

The @OutputCache directive at the top of an .aspx page (or a user control's .ascx) declares Duration in seconds and a VaryByParam setting, such as VaryByParam="none" for a single cached version or VaryByParam="categoryId" to cache a separate copy per distinct query-string value. Applying @OutputCache to a user control rather than a whole page is called fragment caching or partial-page caching, and it's done with VaryByControl or simply by placing the directive in the .ascx file, letting you cache an expensive sidebar widget (like a "trending products" list) while the rest of the page — including anything personalized to the logged-in user — still renders fresh on every request.

The Cache object, accessed via HttpContext.Current.Cache or simply Cache inside a Page, stores arbitrary .NET objects — a DataTable, a List<Product>, a lookup dictionary — keyed by string, and unlike Application state it supports automatic expiration and dependency-based invalidation. Cache.Insert(key, value, dependency, absoluteExpiration, slidingExpiration) is the most common overload: an absolute expiration removes the item after a fixed wall-clock time regardless of use, while a sliding expiration resets the countdown every time the item is accessed, evicting it only after a period of inactivity. Under memory pressure, the Cache also performs automatic scavenging, evicting lower-priority entries first, which means code reading from the Cache must always be prepared for a cache miss and fall back to reloading the data from the database.

The hardest part of caching is knowing when to throw stale data away. A SqlCacheDependency ties a Cache entry to a specific SQL Server table or query, automatically invalidating the cached item the moment the underlying data changes, which requires enabling either SQL Server query notifications or, in older setups, polling-based dependency on a table. When a full dependency isn't practical, many teams fall back to manual invalidation: explicitly calling Cache.Remove(key) inside the same code path that performs an UPDATE or DELETE, so the next read is forced to reload fresh data. Sliding expiration is convenient for slowly-changing lookup data (like a list of countries) where staleness for a few minutes is harmless, while absolute expiration or explicit invalidation is safer for anything where users would notice or be harmed by out-of-date data, like inventory counts.