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.