Template fragment caching in Django - Step-by-Step Execution

Concept Flow - Template fragment caching

Template Render Start

↓

Check Cache for Fragment

↓

Use Cached

↓

Insert Fragment in Template

↓

Return Full Rendered Template

When rendering a template, Django checks if a cached fragment exists. If yes, it uses it. If no, it renders and caches the fragment for next time.

Execution Sample

Django

{% load cache %}
{% cache 500 sidebar user.id %}
  <div>Sidebar content for user {{ user.id }}</div>
{% endcache %}

This template caches the sidebar fragment for 500 seconds, keyed by the user's id.

Execution Table

Step	Action	Cache Check Result	Fragment Rendered	Cache Updated	Output
1	Start rendering template	N/A	No	No	Template rendering begins
2	Check cache for key 'sidebar42'	Miss	Yes	Yes	<div>Sidebar content for user 42</div> cached
3	Insert rendered fragment into template	N/A	N/A	N/A	Template with sidebar fragment inserted
4	Return full rendered template	N/A	N/A	N/A	Full HTML output with sidebar

💡 Cache hit or miss determines if fragment is rendered or reused; here first render causes cache miss and caching.

Variable Tracker

Variable	Start	After Step 2	After Step 3	Final
cache_fragment	None	Rendered HTML stored	Used in template	Used in template
template_output	Empty	Partial with fragment	Partial with fragment	Complete HTML

Key Moments - 2 Insights

Why does the fragment render again if the cache is missed?

Because the cache check at Step 2 shows a miss, so Django must render the fragment and then store it in cache for future use.

What happens if the cache key includes user.id?

The cache stores a separate fragment for each user.id, so different users get their own cached sidebar content, as shown in Step 2.

Visual Quiz - 3 Questions

Look at the execution table, what happens at Step 2 when the cache is missed?

A The cached fragment is used without rendering

B The fragment is rendered and cached

C The template rendering stops

D The cache is cleared

💡 Hint

Check the 'Cache Check Result' and 'Fragment Rendered' columns at Step 2

At which step is the cached fragment inserted into the template?

A Step 3

B Step 2

C Step 1

D Step 4

💡 Hint

Look at the 'Output' column describing fragment insertion

If the cache key did not include user.id, what would change in the execution?

A The cache would never be used

B Each user would have a unique cache fragment

C All users would share the same cached fragment

D The fragment would never render

💡 Hint

Refer to the 'Cache Check Result' and key naming explanation in key moments

Concept Snapshot

Template fragment caching stores parts of a template output.
Use {% cache timeout key %} ... {% endcache %} tags.
Django checks cache before rendering fragment.
If cached, uses stored HTML.
If not, renders and caches fragment.
Cache keys can include variables like user.id for uniqueness.

Full Transcript

Template fragment caching in Django helps speed up rendering by saving parts of a template's output. When rendering, Django checks if the fragment is already cached using a key. If the cache has the fragment, it uses it directly, skipping rendering. If not, it renders the fragment and stores it in cache for future use. For example, caching a sidebar per user by including user.id in the cache key ensures each user sees their own cached content. This process reduces repeated work and improves performance.

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