diff --git a/slides.md b/slides.md
index 1685e22..70bdce5 100644
--- a/slides.md
+++ b/slides.md
@@ -68,9 +68,10 @@ layout: fact
---
@@ -83,12 +84,12 @@ layout: section
- What is caching?
- Caching lets your code remember things it's already done
- Reuse a value you've already done the work to calculate
- - It's always slower to do something than nothing
+ - Because it's always slower to do something than nothing
- Caching comes in many different forms
- From storing a variable outside a loop
- To caching functions
- - To caching entire pages with a CDN
- - Mostly focusing on the higher end today
+ - To caching entire pages
+ - Mostly focusing on the higher end today
- The higher up the list you are, the more smaller processes you're caching
- And the more performance you can get
-->
@@ -121,15 +122,16 @@ h1 {
---
@@ -140,6 +142,7 @@ layout: section
---
@@ -203,14 +206,17 @@ class: p-0 m-0 bg-black
@@ -227,6 +233,7 @@ background: /website-homepage.png
- An example: My website
- Subtle self-promotion, I know
- It's a relatively simple blog
+ - Currently built with Wagtail
-->
---
@@ -235,20 +242,20 @@ image: /website-posts.png
---
---
@@ -327,21 +334,26 @@ layout: none
- Makes them easier to work with
- And makes fragment caching much easier too
- This has no caching at all
- - [click]Let's add some
+ - Every time I used the template, the template is evaluated
+ - All the template tags are run
+ - [click]Let's cache it
+ - Nice and simple
- It's just 2 lines of change[click]
-- The tag might look a bit weird
+- The tag might look a bit strange
- It's not an inclusion or a filter
- It's a fully custom template tag
- - A name: To uniquely identify this template fragment from others
- - A TTL: To determine how long the cache is valid for
- - Whatever variables the tag needs
- - So if the variables change, the cache is automatically invalidated
- - Don't show listing images? Different cache!
- - [click]Put the HTML you want in the middle
- - It's still a Django template, so calling tags etc is completely fine
- - They'll be cached too
+ - Let's look at its structure
+ - A name: To uniquely identify this template fragment from others
+ - A TTL: To determine how long the cache is valid for
+ - Whatever variables the tag needs
+ - So if the variables change, the cache is automatically invalidated
+ - Don't show listing images? Different cache!
+ - [click]Put the HTML you want in the middle
+ - It's still a Django template, so calling tags etc is completely fine
+ - They'll be cached too
- [click]The template is in charge of caching itself
- Keep the complexities hidden, and in 1 place
+ - Pages using it don't need to worry about it too much
-->
---
@@ -353,11 +365,14 @@ class: text-right
# What about
search?
@@ -393,8 +408,9 @@ image: /website-search.png
---
@@ -436,13 +452,16 @@ code {
---
@@ -461,31 +480,37 @@ layout: center
```jinja
{% load wagtail_cache %}
-{% wagtailcache 500 sidebar request.user.username %}
+{% wagtailpagecache 500 sidebar request.user.username %}
+ .. sidebar for logged in user ..
+{% endwagtailpagecache %}
+```
+
+```jinja
+{% load wagtail_cache %}
+{% wagtailcache 500 sidebar request.user.username page.cache_key site.id %}
.. sidebar for logged in user ..
{% endwagtailcache %}
```
````
-
-
-- Current page
-- Current site
-- Skip in preview
-
-
-
---
@@ -496,6 +521,7 @@ layout: section
# Frontend Caching
---
@@ -562,15 +588,16 @@ flowchart TD
```
---
@@ -580,7 +607,7 @@ class: bg-white
---
@@ -614,6 +635,7 @@ transition: fade
---
@@ -621,6 +643,7 @@ layout: cover
background: /map.jpg
transition: fade
---
+
## Arnhem → Ireland
# ~XXms
@@ -633,6 +656,7 @@ h1 {
@@ -652,9 +676,9 @@ h1 {
---
@@ -682,12 +706,15 @@ flowchart LR
Let's cache our content!
- Put a caching layer between users and the site
- Requests are sent via cache
- - Usually just adding a DNS record
- - It's always DNS
+ - If they're cached, return them
+ - Otherwise, get the actual content from Wagtail
- Ensure the CDN knows how long to cache pages for
- - Cache headers
- - Configuration in the CDN itself
- - There's another talk about this
+ - Somewhere between "Forever" and "1 second"
+ - An hour is probably fine
+ - Lots of different options
+ - Cache headers
+ - Configuration in the CDN itself
+ - There's another talk about this
-->
---
@@ -719,7 +746,7 @@ flowchart LR
- Make sure you skip caching authenticated requests (ie the admin)
- These pages are dynamic based on who is viewing them, so we can't cache them easily
- Wagtail does its best to make sure the admin is fast anyway
- - May need to include the session id as part of the cache key
+ - Exactly how to do this will again depend on your CDN
-->
---
@@ -755,6 +782,7 @@ flowchart LR
- Server load should drop drastically
- Might even be able to scale down
- Wagtail.org serves ~70% of all page loads from the CDN
+ - And with some work we could probably get that higher
-->
---
@@ -781,11 +809,12 @@ background: /wagtail-homepage-typo.png
---
@@ -803,7 +832,7 @@ layout: section
---
@@ -887,7 +916,7 @@ code {
---
@@ -934,6 +963,9 @@ background: https://d1nvwtjgmbo5v5.cloudfront.net/media/images/Screen_Shot_2015-
- When most people think of "performance", they tend to think "database queries"
- Which is true, that's where a lot of time goes
- But there's more to optimising a site than sprinkling `select_related` / `prefetch_related`
+- "Performance" means lots of things to different people
+ - Your application is made up of lots of different components
+ - So too must your performance investigations
- It's faster to do less than to do more
- It's faster still to do nothing than something
- The higher up the stack your cache is, the more impactful it can be