<p>I am by no means a caching expert, but here's what I do know...</p>

<p>When you wrap a chunk of Twig code in a <code>cache</code> tag, it processes that chunk of code all the way down to HTML, then stores that HTML in the database. A cache key references this pre-parsed HTML code, so it can be easily called up later.</p>

<p>But in addition to the HTML itself, two other pieces of data are stored alongside it:</p>

<ul>
<li>A list of <strong>criteria</strong> used to generate the HTML</li>
<li>A list of <strong>elements</strong> used to generate the HTML</li>
</ul>

<p>The main reason that criteria and elements are also recorded is for the purpose of <strong>cache invalidation</strong>... So for example, if someone were to change an element associated with a cached chunk, that chunk would <em>immediately</em> become invalidated. You wouldn't need to write a separate plugin in that case, the cache would be invalidated simply by updating a corresponding element. Something similar happens to criteria, if the criteria results would have changed.</p>

<p>Check out <a href="https://craftcms.stackexchange.com/questions/6633/how-does-template-caching-work">this question</a> which I asked awhile ago... It goes into greater depth about the related caching tables, and how they work together to make sure your cache stays fresh.</p>

<p>Also, make sure you've reviewed the <a href="http://buildwithcraft.com/docs/templating/cache#when-to-use-cache-tags" rel="nofollow noreferrer">official recommendations</a> about the proper usage of cache tags, to figure out the best times to use (and not to use) the tag.</p>

<p>Lastly, I'd recommend taking the time to watch this excellent <a href="https://straightupcraft.com/articles/the-cache-tag" rel="nofollow noreferrer">video from Barrel Strength Design</a> about the wonders of the cache tag. There is a lot to be learned from that video, and it's a great way to get your bearings on caching in general.</p>

CC BY-SA 3.0
2015-06-24T02:34:27.287Z
I've seen the recommendations, but haven't watched the video, I'll check it out, thx!
andrew wisener
CC BY-SA 3.0
2015-06-23T05:52:56.620Z
2015-06-23T05:52:56.620Z
2017-04-13T12:51:00.253Z
Lindsey D
<p>Part of our go live process is to put caching in place for the site. It is a great feature. But I am unsure on the best strategy, not from a technical perspective but from a non-technical cms editor perspective...</p>

<p>For example, we usually setup the cache on the header and footer includes on our templates. I like to set it up for 1 hour, that way it will clear reasonably often. That way if the editor changes some header or footer markup they just need to wait an hour for the new content to appear. Which brings me to the issue, our cms editors find this all a bit confusing, they are never sure what will be cached and what won't, if you show them how to clear the cache they end up doing it almost every edit just to be sure. Or they make edits and when it doesn't look they way they want they think it must be the cache and leave it looking odd for days before they admit something must be wrong.</p>

<p>So how do other people deal with this? I am thinking we might write a plugin to clear the entire cache on any entry save or structure modification. But this seems a bit crude.</p>

CC BY-SA 3.0
2015-06-23T01:24:21.747Z
Are you using the `{% cache %}` tag or are you cacheing from a plugin? The cache tag should automatically clear and re-save when whatever entry they are cacheing for is updated, assuming you have your configs set up correctly.
Aaron Berkowitz
CC BY-SA 3.0
2015-06-24T02:30:49.177Z
yes using the cache tag so something like {% cache for 1 hour if craft.config.siteCached  %} where siteCached is a var. I understand the cache clears when a page is edited. But some things don't quite work that way, for example if the a new page is added to the top navigation, or the home page lists the latest 3 news items and a new news item is added. Or global header or footer values are changed.
andrew wisener
<cache>
Best Caching strategy
# Best Caching strategy

(Asked by: username_0 on 2015-06-22)

Part of our go live process is to put caching in place for the site. It is a great feature. But I am unsure on the best strategy, not from a technical perspective but from a non-technical cms editor perspective...

For example, we usually setup the cache on the header and footer includes on our templates. I like to set it up for 1 hour, that way it will clear reasonably often. That way if the editor changes some header or footer markup they just need to wait an hour for the new content to appear. Which brings me to the issue, our cms editors find this all a bit confusing, they are never sure what will be cached and what won't, if you show them how to clear the cache they end up doing it almost every edit just to be sure. Or they make edits and when it doesn't look they way they want they think it must be the cache and leave it looking odd for days before they admit something must be wrong.

So how do other people deal with this? I am thinking we might write a plugin to clear the entire cache on any entry save or structure modification. But this seems a bit crude.

**Tags:** cache
> **Comments:**
> **username_1**: Are you using the `{% cache %}` tag or are you cacheing from a plugin? The cache tag should automatically clear and re-save when whatever entry they are cacheing for is updated, assuming you have your configs set up correctly.  
> **username_0**: yes using the cache tag so something like {% cache for 1 hour if craft.config.siteCached  %} where siteCached is a var. I understand the cache clears when a page is edited. But some things don't quite work that way, for example if the a new page is added to the top navigation, or the home page lists the latest 3 news items and a new news item is added. Or global header or footer values are changed.  

---

## 1 answers

### Answer by username_2 on 2015-06-23. Score: 3

I am by no means a caching expert, but here's what I do know...

When you wrap a chunk of Twig code in a `cache` tag, it processes that chunk of code all the way down to HTML, then stores that HTML in the database. A cache key references this pre-parsed HTML code, so it can be easily called up later.

But in addition to the HTML itself, two other pieces of data are stored alongside it:

* A list of **criteria** used to generate the HTML
* A list of **elements** used to generate the HTML

The main reason that criteria and elements are also recorded is for the purpose of **cache invalidation**... So for example, if someone were to change an element associated with a cached chunk, that chunk would *immediately* become invalidated. You wouldn't need to write a separate plugin in that case, the cache would be invalidated simply by updating a corresponding element. Something similar happens to criteria, if the criteria results would have changed.

Check out [this question](https://craftcms.stackexchange.com/questions/6633/how-does-template-caching-work) which I asked awhile ago... It goes into greater depth about the related caching tables, and how they work together to make sure your cache stays fresh.

Also, make sure you've reviewed the [official recommendations](http://buildwithcraft.com/docs/templating/cache#when-to-use-cache-tags) about the proper usage of cache tags, to figure out the best times to use (and not to use) the tag.

Lastly, I'd recommend taking the time to watch this excellent [video from Barrel Strength Design](https://straightupcraft.com/articles/the-cache-tag) about the wonders of the cache tag. There is a lot to be learned from that video, and it's a great way to get your bearings on caching in general.

> **Comments:**
> **username_0**: I've seen the recommendations, but haven't watched the video, I'll check it out, thx!  

---

