Introduction
Caching is one of the most effective techniques for improving the performance of ASP.NET Core applications. A well-designed caching strategy can dramatically reduce server load, lower response times, and improve scalability without requiring additional infrastructure.
However, many developers still confuse Response Caching with the newer Output Caching introduced in .NET 7 and enhanced in .NET 8. Although both aim to reduce unnecessary work, they solve different problems and behave very differently in production.
A common misconception is that Output Caching simply replaces Response Caching. In reality, they operate at different layers of the HTTP pipeline, have different control mechanisms, and are intended for different deployment scenarios.
In this article, you'll learn:
How Response Caching actually works
Why Output Caching was introduced
Internal request lifecycle differences
Performance implications
Production implementation patterns
Common pitfalls
Which approach should be used in modern ASP.NET Core applications
Rather than repeating the official documentation, we'll focus on the architectural differences and the practical trade-offs developers encounter in real-world applications.
Understanding the ASP.NET Core Request Pipeline
Before comparing the two caching approaches, it's important to understand where each one participates in the request pipeline.
A simplified request flow looks like this:
Client
│
▼
Middleware
│
Authentication
│
Authorization
│
Routing
│
Controller / Minimal API
│
Business Logic
│
Database
│
Response
Without caching, every request executes the full pipeline.
Even if two consecutive requests ask for identical data, the application still performs:
Routing
Dependency Injection
Model Binding
Authorization
Business Logic
Database queries
Serialization
This repeated work consumes CPU, memory, and database resources.
Caching exists to eliminate as much unnecessary work as possible.
Why ASP.NET Core Has Two Caching Mechanisms
Many developers assume Microsoft introduced Output Caching because Response Caching was obsolete.
That's not entirely true.
Each serves a different purpose.
| Feature | Response Caching | Output Caching |
|---|
| Primary goal | Help HTTP clients cache responses | Reduce server processing |
| Stores response on server | No | Yes |
| Depends on browser/proxy behavior | Yes | No |
| Server performance improvement | Minimal | Significant |
| Works without Cache-Control headers | No | Yes |
| Full server-side control | No | Yes |
This distinction is the single biggest source of confusion.
What Is Response Caching?
Response Caching is an implementation of the HTTP caching specification (RFC 9111).
Instead of deciding whether to cache a response itself, ASP.NET Core simply adds the appropriate HTTP headers.
Examples include:
Cache-Control
ETag
Expires
Vary
Age
The actual caching decision is left to:
Browsers
Reverse proxies
CDNs
Intermediate HTTP caches
ASP.NET Core does not store the response in memory.
It merely instructs downstream caches how they should behave.
How Response Caching Works
Consider this endpoint:
[ApiController]
[Route("api/products")]
public class ProductsController : ControllerBase
{
[HttpGet]
[ResponseCache(Duration = 60)]
public IActionResult GetProducts()
{
Console.WriteLine("Database queried");
return Ok(ProductRepository.GetAll());
}
}
The response contains headers similar to:
Cache-Control: public,max-age=60
If the client respects these headers:
First request reaches the server.
Response is cached by the browser or proxy.
Subsequent requests may never reach ASP.NET Core.
This improves perceived performance.
However, the application itself has no guarantee that caching will actually occur.
Important Limitation
Suppose the application is accessed through:
Browser
│
Internet
│
ASP.NET Core API
If the browser ignores caching headers:
Every request still reaches the API.
The controller executes every time.
The database executes every time.
Nothing has been saved on the server.
This is why Response Caching is often misunderstood.
Configuring Response Caching
Enable middleware:
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddResponseCaching();
var app = builder.Build();
app.UseResponseCaching();
app.MapControllers();
app.Run();
Controller example:
[ResponseCache(
Duration = 120,
Location = ResponseCacheLocation.Any,
NoStore = false)]
public IActionResult Weather()
{
return Ok(GetForecast());
}
This generates HTTP cache headers.
It does not cache the response inside ASP.NET Core.
What Is Output Caching?
Output Caching is a server-side caching system introduced in .NET 7 specifically to solve the limitations of Response Caching.
Instead of asking browsers to cache responses, ASP.NET Core stores the generated response itself.
The next request can often bypass:
Model binding
Controller execution
Dependency injection
Database access
Serialization
The cached response is returned directly from the middleware.
This dramatically reduces CPU utilization under high traffic.
How Output Caching Works
The request flow becomes:
Request
│
Output Cache Middleware
│
┌───────────────┐
│ Cache Exists? │
└──────┬────────┘
│
Yes │ No
│
Return ▼
Cached Response
│
Controller
│
Database
│
Generate Response
│
Store in Cache
│
Return Response
Unlike Response Caching, the application itself decides when cached content should be served.
The client doesn't participate in the decision.
Configuring Output Caching
Register the service:
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddOutputCache();
var app = builder.Build();
app.UseOutputCache();
app.MapControllers();
app.Run();
Controller example:
[ApiController]
[Route("api/weather")]
public class WeatherController : ControllerBase
{
[HttpGet]
[OutputCache(Duration = 60)]
public IActionResult Get()
{
Console.WriteLine("Fetching weather data...");
return Ok(new
{
Temperature = 27,
City = "London",
Time = DateTime.UtcNow
});
}
}
When the first request arrives:
Controller executes.
Response is generated.
Middleware stores the response.
Subsequent requests within the 60-second duration are served directly from the cache without invoking the controller.
Request Lifecycle Comparison
The difference becomes clearer when comparing the request paths.
Response Caching
Request
│
Controller
│
Business Logic
│
Database
│
Generate Response
│
Return Headers
│
Browser May Cache
Every request can still execute the application if the client does not use its cache.
Output Caching
Request
│
Output Cache
│
Cache Hit?
┌────┴────┐
│ │
Yes No
│ │
Return Controller
Cached Database
Response Generate
Store
Return
This architectural difference is why Output Caching typically provides much greater server-side performance benefits than Response Caching.
When Response Caching Still Makes Sense
Despite the advantages of Output Caching, Response Caching remains useful in scenarios where intermediary caches can reduce network traffic before requests even reach your application. Common examples include:
Public documentation websites
Static or rarely changing content
CDN-backed APIs
Public REST endpoints with long-lived responses
In these cases, allowing browsers and CDNs to cache responses can reduce bandwidth consumption and improve global response times.
Performance Comparison: Output Caching vs Response Caching
Both caching mechanisms can improve application responsiveness, but they optimize different parts of the request lifecycle. Understanding where the performance gains come from is critical when designing scalable ASP.NET Core applications.
Server-Side Processing
The biggest advantage of Output Caching is that it prevents the application from executing expensive operations repeatedly.
Consider a typical API endpoint that performs the following tasks:
With Output Caching, these steps are performed only for the initial request. Subsequent requests are served directly from the cache until the cached response expires or is evicted.
By contrast, Response Caching does not reduce server-side work unless an intermediary cache (such as a browser or CDN) serves the request before it reaches the application.
Request Processing Comparison
| Processing Step | No Cache | Response Caching | Output Caching |
|---|
| Request reaches ASP.NET Core | ✔ | Usually ✔ | First request only |
| Routing | ✔ | ✔ | First request only |
| Controller execution | ✔ | ✔ | First request only |
| Database access | ✔ | ✔ | First request only |
| JSON serialization | ✔ | ✔ | First request only |
| Cached response returned | ✖ | Browser/Proxy | ASP.NET Core |
The key takeaway is that Output Caching reduces server workload, while Response Caching reduces network traffic when supported by the client or intermediary caches.
Choosing the Right Caching Strategy
Neither mechanism is universally better. The appropriate choice depends on your application's architecture and deployment environment.
| Scenario | Recommended Approach |
|---|
| Public API behind a CDN | Response Caching + CDN |
| High-traffic internal API | Output Caching |
| Expensive database queries | Output Caching |
| Static documentation | Response Caching |
| Product catalog | Output Caching |
| Frequently changing data | Short-duration Output Cache or no cache |
| Personalized responses | Avoid Output Caching unless varied appropriately |
Configuring Output Cache Policies
While the [OutputCache] attribute is convenient, defining named cache policies provides greater flexibility and keeps caching rules centralized.
builder.Services.AddOutputCache(options =>
{
options.AddPolicy("ProductsCache", policy =>
{
policy.Expire(TimeSpan.FromMinutes(5));
});
options.AddPolicy("ShortCache", policy =>
{
policy.Expire(TimeSpan.FromSeconds(30));
});
});
Apply the policy to an endpoint:
[OutputCache(PolicyName = "ProductsCache")]
public IActionResult GetProducts()
{
return Ok(_repository.GetProducts());
}
Centralizing policies makes cache durations easier to maintain and promotes consistency across the application.
Varying Cached Responses
A common mistake is caching a single response for requests that should produce different results.
For example:
GET /products?page=1
GET /products?page=2
These responses should not share the same cache entry.
Output Caching supports cache variation based on query parameters.
builder.Services.AddOutputCache(options =>
{
options.AddPolicy("ProductsPolicy", policy =>
{
policy.SetVaryByQuery("page", "category");
policy.Expire(TimeSpan.FromMinutes(5));
});
});
Now each unique combination of page and category generates its own cached response.
Vary by Route Values
Suppose your API exposes product details:
GET /products/10
GET /products/20
Each product should have an independent cache entry.
builder.Services.AddOutputCache(options =>
{
options.AddPolicy("ProductDetails", policy =>
{
policy.SetVaryByRouteValue("id");
});
});
Without this configuration, different route values could incorrectly share the same cached response.
Vary by Header
Some APIs return different responses depending on request headers, such as language preferences.
Accept-Language: en-US
Accept-Language: fr-FR
Configure variation accordingly:
builder.Services.AddOutputCache(options =>
{
options.AddPolicy("Localization", policy =>
{
policy.SetVaryByHeader("Accept-Language");
});
});
Each language receives its own cached representation.
Cache Expiration Strategies
Choosing an appropriate expiration time is just as important as enabling caching.
Short Expiration (15–60 seconds)
Suitable for:
Dashboards
Stock prices
Weather data
Metrics
Advantages:
Medium Expiration (5–15 minutes)
Suitable for:
Product catalogs
Blog posts
Public APIs
Documentation
Provides a good balance between freshness and performance.
Long Expiration (Hours)
Suitable for:
Configuration data
Country lists
Static reference data
Version information
Long-lived caches minimize repeated computation for data that changes infrequently.
Cache Invalidation
One of the biggest challenges in caching is determining when cached data should be refreshed.
Consider the following scenario:
GET /products
The response is cached for ten minutes.
A new product is added after one minute.
Without invalidation, users continue to receive outdated data until the cache expires.
This illustrates the classic trade-off between performance and data freshness.
When selecting cache durations, consider:
How often the data changes
Whether users require real-time updates
The cost of regenerating the response
The acceptable level of staleness
Shorter expiration times reduce stale data but increase server processing.
Output Caching with Minimal APIs
Output Caching works seamlessly with Minimal APIs.
app.MapGet("/weather", () =>
{
return Results.Ok(new
{
Temperature = 26,
Time = DateTime.UtcNow
});
})
.CacheOutput();
You can also specify a named policy:
app.MapGet("/products", (IProductService service) =>
{
return Results.Ok(service.GetAll());
})
.CacheOutput("ProductsCache");
This allows Minimal APIs to benefit from the same server-side caching capabilities as MVC controllers.
Authentication and Output Caching
One of the most important considerations is avoiding cached responses for authenticated or user-specific content.
For example:
GET /profile
If the response contains personalized information, serving the same cached response to multiple users would be a serious security issue.
As a rule of thumb:
Cache only public content by default.
Carefully configure cache variation for authenticated endpoints.
Avoid caching responses containing sensitive or user-specific data unless you fully understand the implications.
Always validate your cache policies in environments that simulate multiple concurrent users.
Response Caching Behind a CDN
Response Caching remains highly valuable when your application is fronted by a Content Delivery Network (CDN).
In such deployments:
Client
│
CDN
│
ASP.NET Core
If the CDN honors the cache headers emitted by Response Caching, many requests are served directly from edge locations without reaching your application.
Benefits include:
In these scenarios, Response Caching complements Output Caching rather than replacing it.
Combining Output Caching and Response Caching
The two mechanisms are not mutually exclusive.
A common production architecture uses:
Browser
│
CDN
│
Reverse Proxy
│
ASP.NET Core Output Cache
│
Database
In this layered approach:
Browsers cache when appropriate.
The CDN serves globally distributed requests.
ASP.NET Core Output Cache eliminates redundant server processing.
The database handles only cache misses.
Each layer contributes to overall application performance.
Advanced Production Patterns
Choosing the right caching middleware is only part of building a scalable ASP.NET Core application. Production systems require thoughtful cache design, invalidation strategies, and monitoring to ensure caching improves performance without introducing stale or incorrect data.
Cache Only Expensive Endpoints
Not every endpoint benefits from caching.
Good candidates include:
Avoid caching lightweight endpoints that perform little work. The overhead of cache management may outweigh any performance gains.
Cache at the Right Layer
A common anti-pattern is relying on a single caching mechanism for every scenario.
Instead, think in layers.
Client
│
Browser Cache
│
CDN / Reverse Proxy
│
ASP.NET Core Output Cache
│
Application Memory
│
Distributed Cache (Redis)
│
Database
Each layer serves a different purpose:
| Layer | Responsibility |
|---|
| Browser | Reduce repeated client requests |
| CDN | Global content delivery |
| Output Cache | Skip request processing |
| Memory Cache | Cache expensive application objects |
| Redis | Share cache across multiple servers |
| Database | Source of truth |
A layered caching strategy provides better scalability than relying on a single cache.
Output Caching vs In-Memory Caching
Developers sometimes confuse Output Caching with IMemoryCache.
They solve different problems.
| Output Caching | IMemoryCache |
|---|
| Stores HTTP responses | Stores application objects |
| No controller execution on cache hit | Controller still executes |
| Automatic response generation | Developer manages cache |
| Ideal for APIs | Ideal for business data |
For example:
public async Task<Product> GetProductAsync(int id)
{
return await _memoryCache.GetOrCreateAsync($"product-{id}", async entry =>
{
entry.AbsoluteExpirationRelativeToNow = TimeSpan.FromMinutes(10);
return await repository.GetProductAsync(id);
});
}
The controller still executes for every request.
Only the database lookup is avoided.
With Output Caching, even the controller is skipped.
Output Caching in Multi-Server Environments
Suppose your application runs behind a load balancer.
Load Balancer
/ | \
Server1 Server2 Server3
Each server maintains its own in-memory output cache.
Consequences include:
Different servers may have different cache contents.
A cache miss on one server doesn't populate another.
Cache warm-up occurs independently on each instance.
For many applications, this behavior is acceptable. However, in environments with frequent deployments or aggressive autoscaling, consider how cache consistency affects user experience.
Monitoring Cache Effectiveness
Enabling caching is not enough—you should measure its impact.
Useful metrics include:
Cache hit rate
Cache miss rate
Average response time
Database query count
CPU utilization
Memory consumption
Request throughput
A low cache hit rate often indicates that:
Expiration times are too short.
Cache variation is overly granular.
Endpoints are unsuitable for caching.
Monitoring helps you refine cache policies over time.
Common Mistakes
1. Caching Personalized Responses
Incorrect:
GET /profile
If the response contains user-specific information, serving a shared cached response can expose sensitive data.
Recommendation: Cache only public content unless you carefully vary cache entries by user-specific characteristics and understand the security implications.
2. Excessive Cache Duration
A product catalog cached for 24 hours may continue serving outdated prices or inventory long after changes occur.
Recommendation: Choose expiration times that reflect how frequently the underlying data changes.
3. Forgetting Cache Variation
Example:
GET /products?page=1
GET /products?page=2
Without varying by the page query parameter, both requests could return the same cached data.
Always configure variation for:
Query parameters
Route values
Relevant request headers
4. Caching Error Responses
Imagine the database becomes temporarily unavailable.
If a 500 Internal Server Error response is cached, subsequent users may continue receiving the cached error even after the database recovers.
Ensure your caching policies avoid storing transient failure responses.
5. Assuming Response Caching Improves Server Performance
One of the most common misconceptions is believing that Response Caching automatically reduces server load.
Unless browsers, proxies, or CDNs actually serve cached responses, every request still reaches your application.
If your goal is to reduce CPU usage and avoid repeated request processing, Output Caching is the appropriate choice.
Troubleshooting Guide
Cached Responses Never Appear
Possible causes:
UseOutputCache() middleware is missing.
AddOutputCache() wasn't registered.
The endpoint lacks an Output Cache policy or attribute.
Requests aren't eligible for caching.
Verify your middleware order and endpoint configuration.
Every Request Hits the Database
Possible reasons:
Cache duration has expired.
Variation rules create unique cache entries.
The endpoint isn't cacheable.
Responses are intentionally bypassing the cache.
Review your cache policies and request patterns.
Response Caching Doesn't Work
Check the following:
Browser developer tools for Cache-Control headers.
Proxy or CDN configuration.
Whether the client is explicitly disabling caching.
Response headers such as Pragma: no-cache.
Remember that Response Caching depends on clients and intermediaries honoring HTTP caching directives.
High Memory Usage
Output Caching stores complete HTTP responses in memory.
If you cache:
memory consumption can increase significantly.
Monitor memory usage and tune cache policies accordingly.
Best Practices
Cache only expensive or frequently requested endpoints.
Use short expiration times for rapidly changing data.
Prefer named cache policies for maintainability.
Configure cache variation carefully.
Validate behavior with authenticated users.
Monitor cache hit ratios and memory usage.
Combine Output Caching with CDN or reverse proxy caching where appropriate.
Test cache behavior under production-like load before deployment.
Regularly review cache durations as application usage evolves.
Frequently Asked Questions
Is Output Caching a replacement for Response Caching?
No. Output Caching focuses on reducing server-side processing, while Response Caching follows HTTP caching standards to enable browsers, proxies, and CDNs to cache responses.
Can both be used together?
Yes. A common production architecture uses Response Caching to benefit browsers and CDNs while using Output Caching to reduce work on the application server.
Does Output Caching replace Redis?
No.
Redis is a distributed cache used to share application data across multiple servers. Output Caching stores complete HTTP responses in the application's memory and serves a different purpose.
Should authenticated APIs be cached?
Generally, avoid caching personalized responses. If caching authenticated content is necessary, ensure cache entries are correctly varied and reviewed from a security perspective.
Is Output Caching supported by Minimal APIs?
Yes. Minimal APIs support Output Caching through the CacheOutput() extension method or named cache policies.
When should I use Response Caching?
Use Response Caching when clients, reverse proxies, or CDNs can benefit from HTTP cache headers, particularly for public, cacheable content.
Final Comparison
| Feature | Response Caching | Output Caching |
|---|
| Introduced | Early ASP.NET Core | .NET 7 |
| Server-side response storage | ✖ | ✔ |
| Improves server CPU usage | Limited | Significant |
| Reduces database calls | Only if request never reaches server | Yes |
| Controlled by HTTP cache headers | ✔ | ✖ |
| Works with browsers and CDNs | ✔ | Indirectly |
| Best for | Public web content | High-traffic APIs and dynamic endpoints |
Conclusion
Both Output Caching and Response Caching are valuable tools, but they address different performance challenges.
Response Caching leverages standard HTTP caching semantics, making it ideal for browsers, reverse proxies, and CDNs. Its effectiveness depends on downstream clients honoring cache directives.
Output Caching, on the other hand, is a server-side optimization that stores complete HTTP responses and bypasses significant portions of the ASP.NET Core request pipeline. For APIs with expensive business logic or database access, it can substantially reduce server workload and improve scalability.
The most effective production architectures often combine both approaches. Browsers and CDNs handle network-level caching, while Output Caching minimizes repeated processing within the application itself. By selecting appropriate cache policies, varying responses correctly, monitoring cache performance, and balancing freshness against efficiency, you can build ASP.NET Core applications that remain responsive under increasing traffic without compromising correctness or maintainability.
Ultimately, caching should be treated as a deliberate architectural decision rather than a simple configuration switch. Understanding the strengths and limitations of each mechanism allows you to choose the right strategy for each endpoint and deliver better performance where it matters most.
Join the conversation! Your thoughts help the community grow.