Jump into concepts and practice - no test required
or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Implementing Per-view Caching in Django
📖 Scenario: You are building a simple Django web application that shows a list of products. To improve performance, you want to cache the output of the product list page so that repeated visits load faster.
🎯 Goal: Learn how to add per-view caching to a Django view function to speed up page loading by storing the rendered response for a set time.
📋 What You'll Learn
Create a Django view function called product_list that returns a simple HTTP response.
Add a cache timeout variable called CACHE_TTL set to 60 seconds.
Apply the @cache_page decorator with CACHE_TTL to the product_list view.
Ensure the final code includes the necessary import for cache_page and the view returns the expected response.
💡 Why This Matters
🌍 Real World
Per-view caching is used in web applications to speed up page loading by storing the output of views temporarily. This reduces server load and improves user experience.
💼 Career
Understanding per-view caching is important for backend developers working with Django to optimize web application performance and scalability.
Progress0 / 4 steps
1
Create the product_list view function
Create a Django view function called product_list that returns an HttpResponse with the text "Product list page". Import HttpResponse from django.http.
Django
Hint
Remember to define a function named product_list that takes request as a parameter and returns HttpResponse("Product list page").
2
Add a cache timeout variable CACHE_TTL
Add a variable called CACHE_TTL and set it to 60 to represent the cache timeout in seconds.
Django
Hint
Define CACHE_TTL = 60 above the view function.
3
Import and apply the @cache_page decorator
Import cache_page from django.views.decorators.cache. Then apply the @cache_page(CACHE_TTL) decorator above the product_list view function.
Django
Hint
Use @cache_page(CACHE_TTL) just above the def product_list(request): line.
4
Complete the view with caching applied
Ensure the final code includes the import of HttpResponse, the import of cache_page, the CACHE_TTL variable set to 60, and the product_list view decorated with @cache_page(CACHE_TTL) returning the correct response.
Django
Hint
Check that all parts are present and the view is decorated correctly.
Practice
(1/5)
1. What is the main purpose of using @cache_page(timeout) in Django views?
easy
A. To connect the view to the database
B. To save the view's output and speed up repeated visits
C. To validate user input before processing
D. To handle user authentication automatically
Solution
Step 1: Understand what caching does
Caching stores the output of a view so it can be reused without recalculating.
Step 2: Recognize the role of @cache_page(timeout)
This decorator saves the rendered page for the given timeout to speed up future requests.
Final Answer:
To save the view's output and speed up repeated visits -> Option B
Quick Check:
Per-view caching = save output for speed [OK]
Hint: Caching saves page output to speed up repeated visits [OK]
Common Mistakes:
Thinking it validates input
Confusing caching with authentication
Assuming it connects to the database
2. Which of the following is the correct way to apply per-view caching with a 5-minute timeout in Django?
easy
A. @cache_page('300')
def my_view(request):
pass
B. @cache_page(5)
def my_view(request):
pass
C. @cache_page(timeout=5)
def my_view(request):
pass
D. @cache_page(300)
def my_view(request):
pass
Solution
Step 1: Understand the timeout parameter
The timeout is in seconds, so 5 minutes = 300 seconds.
Step 2: Check correct syntax for @cache_page
The decorator takes an integer timeout in seconds without quotes.
Final Answer:
@cache_page(300)\ndef my_view(request):\n pass -> Option D
Quick Check:
Timeout in seconds, no quotes = @cache_page(300)
def my_view(request):
pass [OK]
Hint: Timeout is seconds as integer, no quotes [OK]
What will happen if you refresh the page multiple times within 60 seconds?
medium
A. The page shows the same timestamp for 60 seconds
B. The page shows a new timestamp on every refresh
C. The page raises an error because time.time() is not cached
D. The page shows timestamps increasing by 60 seconds
Solution
Step 1: Understand what @cache_page(60) does
It caches the entire response for 60 seconds.
Step 2: Analyze the effect on time.time()
Since the response is cached, the timestamp won't update until cache expires.
Final Answer:
The page shows the same timestamp for 60 seconds -> Option A
Quick Check:
Cache holds output unchanged for timeout [OK]
Hint: Cached view returns same output until timeout expires [OK]
Common Mistakes:
Expecting timestamp to update every refresh
Thinking caching only affects database queries
Assuming cache raises errors with dynamic content
4. You wrote this Django view with caching:
from django.views.decorators.cache import cache_page
@cache_page('60')
def about(request):
return HttpResponse('About page')
Why does this code cause an error?
medium
A. The timeout value is a string instead of an integer
B. The decorator is missing parentheses
C. The view function must be a class-based view
D. The import statement is incorrect
Solution
Step 1: Check the timeout argument type
The timeout must be an integer number of seconds, not a string.
Step 2: Identify the error cause
Passing '60' as a string causes a TypeError in the decorator.
Final Answer:
The timeout value is a string instead of an integer -> Option A
Quick Check:
Timeout must be int, not string [OK]
Hint: Timeout must be integer, not string [OK]
Common Mistakes:
Using quotes around timeout number
Forgetting parentheses on decorator
Thinking function type matters here
5. You want to cache a Django view that shows user-specific data but still use per-view caching. Which approach correctly applies caching without showing wrong data to users?
hard
A. Cache the view globally and add user ID in the URL to separate cache keys
B. Use @cache_page(120) without changes; caching will separate users automatically
C. Use @cache_page(120) and add Vary: Cookie header to cache per user session
D. Do not use caching on user-specific views at all
Solution
Step 1: Understand caching user-specific data risks
Global caching can show one user's data to others if not separated.
Step 2: Use Vary header to separate cache by user session
Adding Vary: Cookie tells cache to store different versions per user session cookie.
Final Answer:
Use @cache_page(120) and add Vary: Cookie header to cache per user session -> Option C
Quick Check:
Vary header separates cache by user [OK]
Hint: Use Vary header to separate cache per user [OK]