Django includes a flexible caching framework supporting multiple levels of caching (whole pages, view results, template fragments, or arbitrary data) and multiple backends (in-memory, Redis, Memcached, database). Caching avoids repeating expensive work — one of the highest-impact performance optimizations.
CACHES = {
: {
: ,
: ,
}
}
# 1. Per-view caching — cache an entire view's output
from django.views.decorators.cache import cache_page
@cache_page(60 * 15) # cache this view's response for 15 minutes
def article_list(request):
...
<!-- 2. Template fragment caching — cache part of a template -->
{% load cache %}
{% cache 500 sidebar %}
... expensive sidebar rendering ... <!-- cached for 500 seconds -->
{% endcache %}
# 3. Low-level cache API — cache ANY data, full control
from django.core.cache import cache
def get_stats():
stats = cache.get("dashboard_stats") # check cache first
if stats is None: # cache MISS
stats = compute_expensive_stats() # do the work
cache.set("dashboard_stats", stats, 3600) # store for 1 hour
return stats
Django lets you cache at multiple granularities: whole pages (cache_page), template fragments ({% cache %}), and arbitrary data via the low-level API (cache.get/cache.set — the flexible get-or-compute pattern). There's also full-site caching via middleware.
# when underlying data changes, the cache must be updated or cleared, or users see stale data
def update_article(article):
article.save()
cache.delete("article_list") # invalidate affected cache entries
# strategies: TTL (accept brief staleness), explicit deletion on writes, versioned keys,
# or signals to invalidate on model save/delete
Cache invalidation is the classic hard problem: when data changes, stale cached
values must be cleared/refreshed. Approaches: short TTLs (accept some staleness),
explicit cache.delete on writes, or cache versioning/key schemes.
✓ Expensive queries/computations, rendered pages/fragments that change infrequently
✓ Aggregations, external API responses, session data
✗ Highly personalized or rapidly-changing data (or use very short TTLs / vary per user)
✗ Don't cache sensitive data carelessly (consider who can read the cache)
Caching is one of the highest-impact performance optimizations for Django applications, and the framework's comprehensive, multi-level caching system makes it accessible — understanding it is valuable senior-level knowledge for building fast, scalable applications.
The core value is avoiding repeated expensive work: database queries, complex computations, external API calls, and template rendering can be cached so subsequent requests are served quickly, dramatically reducing latency and database/server load.
Django's flexibility across multiple caching levels (whole pages with cache_page, template fragments with {% cache %}, and arbitrary data via the low-level API's get-or-compute pattern) lets you cache at exactly the right granularity for each situation, and its pluggable backends (especially Redis for a shared cache across multiple servers — important since per-process in-memory caches aren't shared when scaling horizontally) suit different deployment needs.
Knowing how to configure caching, choose the appropriate level, and select the right backend for the deployment is practical, frequently-needed knowledge.
Equally important is understanding caching's central difficulty — invalidation (the famously hard problem of clearing or refreshing cached data when the underlying data changes, via TTLs, explicit deletion on writes, or key versioning, to avoid serving stale data) — since getting this wrong is the classic caching failure that shows users outdated information.
Also knowing what to cache (expensive, infrequently-changing data) versus what not to (highly dynamic or sensitive data) is key to using caching effectively.
Because caching delivers major performance gains but requires careful invalidation, mastering Django's caching framework — the levels, backends, and especially the invalidation strategies — is important knowledge for building performant, scalable applications and a hallmark of developers who can make Django apps fast under real load.