Django には柔軟なキャッシング フレームワークが含まれており、複数のレベルのキャッシング（ページ全体、ビュー結果、テンプレート フラグメント、または任意のデータ）と複数のバックエンド（インメモリ、Redis、Memcached、データベース）をサポートしています。キャッシングにより、重い処理の繰り返しを避けることができ、パフォーマンス最適化の中でも最も影響力のあるものの 1 つです。
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 では複数の粒度でキャッシングできます：ページ全体（cache_page）、テンプレート フラグメント（{% cache %}）、および低レベル API を経由した任意のデータ（cache.get/cache.set — 柔軟な get-or-compute パターン）です。ミドルウェア経由のサイト全体キャッシングもあります。
# 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)
キャッシングは Django アプリケーションのパフォーマンス最適化の中で最も影響力のあるものの 1 つであり、フレームワークの包括的でマルチレベルのキャッシング システムはこれをアクセス可能にしています — これを理解することは、高速でスケーラブルなアプリケーションを構築するための貴重なシニアレベルの知識です。
コアバリューは重い処理の繰り返しを避けることです：データベース クエリ、複雑な計算、外部 API 呼び出し、テンプレート レンダリングはキャッシュできるため、その後のリクエストは迅速に処理され、レイテンシとデータベース/サーバー負荷を劇的に削減します。
Django の複数のキャッシング レベル（cache_page によるページ全体、{% cache %} によるテンプレート フラグメント、低レベル API の get-or-compute パターンによる任意のデータ）での柔軟性により、各状況に対して正確な粒度でキャッシュでき、そのプラグイン可能なバックエンド（特に複数サーバー間で共有キャッシュを提供する Redis — 水平スケーリング時にプロセスごとのインメモリ キャッシュが共有されないため重要）はさまざまなデプロイメント ニーズに対応します。
キャッシングの設定方法、適切なレベルの選択、デプロイメントに対する正しいバックエンドの選択を知ることは、実用的で頻繁に必要とされる知識です。
同様に重要なのはキャッシングの中心的な困難さ — 無効化（基になるデータが変更されたときにキャッシュされたデータをクリアまたはリフレッシュする有名な問題で、TTL、書き込み時の明示的な削除、またはキー バージョニング経由で行い、古いデータの提供を避ける）— を理解することです。これを間違えると、ユーザーに古い情報を表示してしまう古典的なキャッシング障害になります。
また何をキャッシュするか（高コストで頻繁に変更されないデータ）と何をしないか（非常に動的または機密データ）を知ることは、キャッシングを効果的に使用するためのキーです。
キャッシングは大きなパフォーマンス向上をもたらしますが慎重な無効化が必要であるため、Django のキャッシング フレームワークをマスターすること — レベル、バックエンド、特に無効化戦略 — は、高性能でスケーラブルなアプリケーションを構築するための重要な知識であり、実際の負荷下で Django アプリケーションを高速化できる開発者の証です。