關于緩存剩下的問題是數據的隱私性以及在級聯緩存中數據應該在何處儲存的問題。

通常用戶將會面對兩種緩存： 他或她自己的瀏覽器緩存（私有緩存）以及他或她的提供者緩存（公共緩存）。 公共緩存由多個用戶使用，而受其他某人的控制。 這就產生了你不想遇到的敏感數據的問題，比如說你的銀行賬號被存儲在公眾緩存中。 因此，Web 應用程序需要以某種方式告訴緩存那些數據是私有的，哪些是公共的。

解決方案是標示出某個頁面緩存應當是私有的。 要在 Django 中完成此項工作，可使用 cache_control 視圖修飾器： 例如：

            
from django.views.decorators.cache import cache_control

@cache_control(private=True)
def my_view(request):
  # ...


          

該修飾器負責在后臺發送相應的 HTTP 頭部。

還有一些其他方法可以控制緩存參數。 例如, HTTP 允許應用程序執行如下操作:

• ??? 定義頁面可以被緩存的最大時間。
• ??? 指定某個緩存是否總是檢查較新版本，僅當無更新時才傳遞所緩存內容。 （一些緩存即便在服務器頁面發生變化的情況下仍然會傳送所緩存的內容，只因為緩存拷貝沒有過期。）

在 Django 中，可使用 cache_control 視圖修飾器指定這些緩存參數。 在本例中， cache_control 告訴緩存對每次訪問都重新驗證緩存并在最長 3600 秒內保存所緩存版本：

            
from django.views.decorators.cache import cache_control

@cache_control(must_revalidate=True, max_age=3600)
def my_view(request):
  # ...


          

在 cache_control() 中，任何合法的Cache-Control HTTP 指令都是有效的。下面是完整列表：

            
  public=True

  private=True

  no_cache=True

  no_transform=True

  must_revalidate=True

  proxy_revalidate=True

  max_age=num_seconds

  s_maxage=num_seconds


          

緩存中間件已經使用 CACHE_MIDDLEWARE_SETTINGS 設置設定了緩存頭部 max-age 。 如果你在cache_control修飾器中使用了自定義的max_age，該修飾器將會取得優先權，該頭部的值將被正確地被合并。

如果你想用頭部完全禁掉緩存，django.views.decorators.cache.never_cache裝飾器可以添加確保響應不被緩存的頭部信息。 例如：

            
from django.views.decorators.cache import never_cache

@never_cache
def myview(request):
  # ...


          

其他優化

Django 帶有一些其它中間件可幫助您優化應用程序的性能:

• ??? django.middleware.http.ConditionalGetMiddleware 為現代瀏覽器增加了有條件的，基于 ETag 和 Last-Modified 頭標的GET響應的相關支持。
• ??? django.middleware.gzip.GZipMiddleware 為所有現代瀏覽器壓縮響應內容，以節省帶寬和傳送時間。

MIDDLEWARE_CLASSES 的順序

如果使用緩存中間件，注意在MIDDLEWARE_CLASSES設置中正確配置。 因為緩存中間件需要知道哪些頭部信息由哪些緩存區來區分。 中間件總是盡可能得想Vary響應頭中添加信息。

UpdateCacheMiddleware在相應階段運行。因為中間件是以相反順序運行的，所有列表頂部的中間件反而last在相應階段的最后運行。 所有，你需要確保UpdateCacheMiddleware排在任何可能往Vary頭部添加信息的中間件之前。 下面的中間件模塊就是這樣的：

• ??? 添加 Cookie 的 SessionMiddleware
• ??? 添加 Accept-Encoding 的 GZipMiddleware
• ??? 添加Accept-Language的LocaleMiddleware

另一方面，FetchFromCacheMiddleware在請求階段運行，這時中間件循序執行，所以列表頂端的項目會首先執行。 FetchFromCacheMiddleware也需要在會修改Vary頭部的中間件之后運行，所以FetchFromCacheMiddleware必須放在它們后面。