Template fragment caching in Django - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What does this Django template fragment cache do?

Consider this Django template code:

{% load cache %}
{% cache 600 sidebar user.id %}
  <div>User sidebar content</div>
{% endcache %}

What is the effect of this fragment cache?

Django

{% load cache %}
{% cache 600 sidebar user.id %}
  <div>User sidebar content</div>
{% endcache %}

A Caches the sidebar content for 600 seconds separately for each user based on their user ID.

B Caches the sidebar content globally for 600 seconds, ignoring user differences.

C Caches the sidebar content indefinitely until manually cleared.

D Does not cache anything because the cache tag is missing a required argument.

💡 Hint

Look at the cache tag arguments: the first is time in seconds, the second is a cache key prefix, the third is a variable.

The cache tag caches the content for 600 seconds. The cache key includes 'sidebar' and the current user's ID, so each user gets their own cached version.

📝 Syntax

intermediate

Identify the syntax error in this Django template fragment cache usage

What is wrong with this Django template fragment cache code?

{% load cache %}
{% cache '300' 'menu' %}
  <nav>Menu content</nav>
{% endcache %}

Django

{% load cache %}
{% cache '300' 'menu' %}
  <nav>Menu content</nav>
{% endcache %}

A The cache timeout should be an integer without quotes, not a string.

B The endcache tag is missing a required argument.

C The cache tag requires at least one variable argument after the key.

D The cache key 'menu' should not be quoted.

💡 Hint

Check the type of the timeout argument in the cache tag.

The timeout argument must be an integer, not a string. Using quotes makes it a string, causing a syntax error.

🔧 Debug

advanced

Why does this fragment cache not update after the data changes?

Given this template fragment cache:

{% load cache %}
{% cache 900 product_list %}
  <ul>
  {% for product in products %}
    <li>{{ product.name }}</li>
  {% endfor %}
  </ul>
{% endcache %}

When the products list changes, the cached content does not update. Why?

Django

{% load cache %}
{% cache 900 product_list %}
  <ul>
  {% for product in products %}
    <li>{{ product.name }}</li>
  {% endfor %}
  </ul>
{% endcache %}

A The products variable is not passed to the template, so the cache is empty.

B The cache key 'product_list' is static, so the cache never invalidates when products change.

C The cache timeout of 900 seconds is too short to see updates.

D The cache tag requires a user ID to differentiate cache entries.

💡 Hint

Think about how the cache key affects cache invalidation.

Because the cache key is fixed as 'product_list', the cached content stays the same for 900 seconds regardless of product changes. To update cache on data change, the key must include a variable that changes when data changes.

❓ state_output

advanced

What is the output count of cached items with this fragment cache?

If this template fragment cache is used:

{% load cache %}
{% cache 120 comments post.id user.id %}
  <div>Comments section</div>
{% endcache %}

And there are 3 posts and 2 users, how many separate cache entries will be created?

Django

{% load cache %}
{% cache 120 comments post.id user.id %}
  <div>Comments section</div>
{% endcache %}

A 2 cache entries (one per user, ignoring posts).

B 3 cache entries (one per post, ignoring users).

C 6 cache entries (3 posts × 2 users).

D 1 cache entry shared by all posts and users.

💡 Hint

The cache key includes both post.id and user.id.

The cache key is built from 'comments', post.id, and user.id. With 3 posts and 2 users, the combinations are 3 × 2 = 6 unique keys, so 6 cache entries.

🧠 Conceptual

expert

What is the main advantage of using template fragment caching in Django?

Why would a developer choose to use template fragment caching instead of full-page caching in Django?

A It requires no cache key and thus is simpler to implement than other caching methods.

B It caches the entire page content, improving performance for all users equally.

C It automatically updates cached content whenever the database changes without extra code.

D It allows caching parts of a page that are expensive to render while keeping other parts dynamic and personalized.

💡 Hint

Think about when you want some parts of a page to update often and others to stay fast.

Template fragment caching lets you cache only slow parts of a page, so you can keep other parts fresh and personalized, unlike full-page caching which caches everything.

Practice

1. What is the main purpose of using {% cache %} in Django templates?

easy

A. To permanently store user data in the database

B. To save a part of the page output and reuse it to speed up loading

C. To encrypt sensitive information in the template

D. To validate form inputs before rendering

Solution

1. Step 1: Understand what template fragment caching does

   Template fragment caching stores the rendered output of a part of a template to avoid re-rendering it every time.

2. Step 2: Identify the purpose of the {% cache %} tag

   The {% cache %} tag is used to wrap parts of a template that should be cached for faster page loads.

3. Final Answer:

   To save a part of the page output and reuse it to speed up loading -> Option B

4. Quick Check:

   Template fragment caching = save and reuse output [OK]

Hint: Cache stores parts of page output to speed loading [OK]

Common Mistakes:

• Thinking cache stores user data permanently
• Confusing cache with encryption
• Using cache tag for form validation

2. Which of the following is the correct syntax to cache a template fragment for 300 seconds with key 'sidebar'?

easy

A. {% cache 300 sidebar %} ... {% endcache %}

B. {% cache sidebar 300 %} ... {% endcache %}

C. {% cache 'sidebar' 300 %} ... {% endcache %}

D. {% cache 300 'sidebar' %} ... {% endcache %}

Solution

1. Step 1: Recall the correct order of arguments in the cache tag

   The syntax is {% cache timeout key %} where timeout is an integer and key is a string.

2. Step 2: Match the syntax with the options

   {% cache 300 'sidebar' %} ... {% endcache %} uses 300 as timeout and 'sidebar' as key in correct order and quotes.

3. Final Answer:

   {% cache 300 'sidebar' %} ... {% endcache %} -> Option D

4. Quick Check:

   Cache syntax = timeout then quoted key [OK]

Hint: Timeout first, then quoted key in cache tag [OK]

Common Mistakes:

• Putting key before timeout
• Not quoting the cache key string
• Using variable name without quotes

3. Given this template code:

{% cache 600 'menu' user.id %}

  
Home
  
Profile

{% endcache %}

What happens if user.id changes?

medium

A. A new cache entry is created for the new user.id

B. The cached fragment is reused regardless of user.id

C. The cache is cleared completely

D. An error occurs because user.id cannot be used

Solution

1. Step 1: Understand cache key with extra parameters

   Extra parameters after the key string are used to create a unique cache key per value.

2. Step 2: Effect of changing user.id on cache

   When user.id changes, Django creates a new cache entry for that user, so the fragment is cached separately.

3. Final Answer:

   A new cache entry is created for the new user.id -> Option A

4. Quick Check:

   Cache key + params = unique cache per user [OK]

Hint: Extra params create unique cache keys [OK]

Common Mistakes:

• Assuming cache ignores extra parameters
• Thinking cache clears all entries on param change
• Believing user.id cannot be used in cache tag

4. Identify the error in this template fragment caching usage:

{% cache 'sidebar' 300 %}
Sidebar content
{% endcache %}

medium

A. The timeout and key order is reversed; timeout must come first

B. Missing closing tag {% endcache %}

C. The cache key must be an integer, not a string

D. Cache tag cannot wrap HTML elements

Solution

1. Step 1: Check the order of arguments in the cache tag

   The correct order is timeout (integer) first, then cache key (string).

2. Step 2: Identify the mistake in the given code

   The code uses 'sidebar' first and 300 second, which is reversed.

3. Final Answer:

   The timeout and key order is reversed; timeout must come first -> Option A

4. Quick Check:

   Timeout first, key second in cache tag [OK]

Hint: Timeout always before key in cache tag [OK]

Common Mistakes:

• Swapping timeout and key order
• Forgetting to close cache tag
• Thinking cache tag can't wrap HTML

5. You want to cache a sidebar that shows user-specific data but also updates every 10 minutes. Which is the best way to use template fragment caching?

hard

A. Do not use cache because user data changes

B. {% cache 600 'sidebar' %} ... {% endcache %} to cache once for all users

C. {% cache 600 'sidebar' user.id %} ... {% endcache %} to cache per user for 10 minutes

D. {% cache 'sidebar' 600 user.id %} ... {% endcache %} with wrong argument order

Solution

1. Step 1: Understand caching user-specific data

   To cache user-specific content, include a unique user identifier in the cache key.

2. Step 2: Set cache timeout to 600 seconds (10 minutes)

   Use 600 seconds as timeout to update cache every 10 minutes.

3. Step 3: Verify correct syntax and usage

   {% cache 600 'sidebar' user.id %} ... {% endcache %} to cache per user for 10 minutes uses correct syntax with timeout first, key string second, and user.id as extra parameter.

4. Final Answer:

   {% cache 600 'sidebar' user.id %} ... {% endcache %} to cache per user for 10 minutes -> Option C

5. Quick Check:

   User-specific cache with timeout = {% cache 600 'sidebar' user.id %} ... {% endcache %} to cache per user for 10 minutes [OK]

Hint: Use user.id param and timeout for user-specific cache [OK]

Common Mistakes:

• Caching once for all users ignoring user.id
• Swapping timeout and key order
• Avoiding cache for user data unnecessarily