<p>Nesting cache tags shouldn't cause any new problems (assuming you've taken into account all the fun problems already caused by cache).</p>

<p>Each cache tag will store it's contents in a database table for easier access. We can illustrate this a bit easier using cache tags with keys.  Take the following example with two cache tags using the keys <code>dog</code> and <code>cat</code></p>

<pre><code>{% cache using key 'dog' %}
    BUSTER
    {% cache using key 'cat' %} 
        KITTEN
    {% endcache %}
{% endcache %}
</code></pre>

<p>When the cache tags are run they store the following:</p>

<p><code>cat</code> stores the value:</p>

<pre><code>KITTEN
</code></pre>

<p><code>dog</code> stores the value:</p>

<pre><code>BUSTER
KITTEN
</code></pre>

<p>The spacing in my example above may not be perfectly accurate but the gist of what content is stored should be. In the case that the page is loaded a second time, when the <code>dog</code> cache tag is found, Craft will pull it's content from the database.  The <code>cat</code> cache tag will never get run, but it doesn't matter, because the full contents of the wrapping <code>dog</code> cache tag have already been retrieved.</p>

CC BY-SA 3.0
2015-08-15T00:42:23.940Z
2015-08-15T00:42:23.940Z
Ben Parizek
<p>What effect, if any, does nesting cache tags have? It seems like it would be redundant, but are there any inherent drawbacks? </p>

<p>Recently, I can across an instance where I was using the <code>{% cache %}</code> tag in an include to cache a large matrix field. This was very successful at reducing querries and speeding things up on several pages that used that same include.</p>

<p>But one template that included this file used more entries tags so it seemed to make sense to wrap all of them in a cache tag as well. Here's an example.</p>

<p><strong>_includes/article-body.html</strong></p>

<pre><code>{% cache %}
  {% for block in entry.bigMatrixField %}
    ...
  {% endfor %}
{% endcache %}
</code></pre>

<p><strong>blog/_entry.html</strong></p>

<pre><code>{% cache %}
  {% for entry in craft.entries.section('blog') %}
    ...(some expensive queries)...
  {% endfor %}

  {% include "_includes/article-body" %}

  {% for category in craft.categories.group('blogCategories') %}
    ...(some more expensive queries)...
  {% endfor %}
{% endcache %}
</code></pre>

CC BY-SA 3.0
2015-06-18T17:33:27.323Z
It does not really matter, `blog/_entry.html` will load a cached version of `_includes/article_body.html` and cache the whole once again.
Bob Olde Hampsink
<cache><performance>
What effect does nesting cache tags have?
# What effect does nesting cache tags have?

(Asked by: username_0 on 2015-04-14)

What effect, if any, does nesting cache tags have? It seems like it would be redundant, but are there any inherent drawbacks? 
Recently, I can across an instance where I was using the {% cache %} tag in an include to cache a large matrix field. This was very successful at reducing querries and speeding things up on several pages that used that same include.
But one template that included this file used more entries tags so it seemed to make sense to wrap all of them in a cache tag as well. Here's an example.
_includes/article-body.html
{% cache %}
  {% for block in entry.bigMatrixField %}
    ...
  {% endfor %}
{% endcache %}

blog/_entry.html
{% cache %}
  {% for entry in craft.entries.section('blog') %}
    ...(some expensive queries)...
  {% endfor %}

  {% include "_includes/article-body" %}

  {% for category in craft.categories.group('blogCategories') %}
    ...(some more expensive queries)...
  {% endfor %}
{% endcache %}

**Tags:** cache, performance

> **Comments:**
> **username_1**: It does not really matter, `blog/_entry.html` will load a cached version of `_includes/article_body.html` and cache the whole once again.  

---

## 1 answers

### Answer by username_2 on 2015-08-15. Score: 2

Nesting cache tags shouldn't cause any new problems (assuming you've taken into account all the fun problems already caused by cache).
Each cache tag will store it's contents in a database table for easier access. We can illustrate this a bit easier using cache tags with keys.  Take the following example with two cache tags using the keys dog and cat
{% cache using key 'dog' %}
    BUSTER
    {% cache using key 'cat' %} 
        KITTEN
    {% endcache %}
{% endcache %}

When the cache tags are run they store the following:
cat stores the value:
KITTEN

dog stores the value:
BUSTER
KITTEN

The spacing in my example above may not be perfectly accurate but the gist of what content is stored should be. In the case that the page is loaded a second time, when the dog cache tag is found, Craft will pull it's content from the database.  The cat cache tag will never get run, but it doesn't matter, because the full contents of the wrapping dog cache tag have already been retrieved.


---

