diff --git a/slides.md b/slides.md
index bc5efb9..a25949a 100644
--- a/slides.md
+++ b/slides.md
@@ -41,6 +41,13 @@ layout: full
   <li><mdi-mastodon /> @jake@theorangeone.net</li>
 </ul>
 
+
+<style>
+  .slidev-layout {
+    background-color: #e85537;
+  }
+</style>
+
 <!--
 - Hi
 - I'm Jake
@@ -49,24 +56,40 @@ layout: full
 - I exist in many places on the internet
 -->
 
-<style>
-    .slidev-layout {
-        background-color: #e85537;
-    }
-</style>
-
 ---
 layout: fact
 ---
 
 # Disclaimer{style="color: #fd5765;"}
 
+<!--
+- Disclaimer: This isn't a general performance talk
+  - Optimising Python, Django and Wagtail are their own topics
+  - Caching can be a part of optimisation
+    - But it's not the only part
+  - It's not a replacement for proper benchmarking and investigations
+-->
+
 ---
 layout: section
 ---
 
 # What _is_ caching?
 
+<!--
+- 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
+  - 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
+  - The higher up the list you are, the more smaller processes you're caching
+    - And the more performance you can get
+-->
+
 ---
 layout: center
 ---
@@ -93,12 +116,32 @@ h1 {
 
 </style>
 
+<!--
+- Caching may not seem needed at some scales
+    - Small sites will probably be _fine_ without it
+    - As your site grows, it becomes more important
+        - Crash under your own weight and success
+- But, you may not notice you need it until it's already an issue
+    - What runs fine locally may not in production
+        - A problem with so many things at scale
+- If a page gets popular, it'll soon meet with the hug of death
+    - Or even if it's not that popular, just shared around a bit
+      - Like the recently-discovered Mastodon issue
+-->
+
 ---
 layout: section
 ---
 
 # <logos-wagtail class="fill-white"/> Caching <em>in Wagtail</em>
 
+<!--
+- Now, back to Wagtail
+- Let's talk about 2 techniques to help you out with caching
+- Both are included in all maintained versions of Wagtail
+  - So you can use them right now!
+-->
+
 ---
 layout: section
 ---
@@ -106,20 +149,17 @@ layout: section
 ## 1:
 # Template Fragment Caching
 
+<!--
+- Template fragment caching
+  - New ish in 5.2
+  - Lots of complex words, but quite a simple concept
+-->
+
 ---
-layout: image
+layout: image-right
 image: https://d1nvwtjgmbo5v5.cloudfront.net/media/images/Screen_Shot_2015-05-14_at_09.01.5.2e16d0ba.fill-1200x996.png
 backgroundSize: cover
----
-
-<style>
-.slidev-layout {
-  background-position: top center !important;
-}
-</style>
-
----
-layout: none
+class: p-0 m-0 bg-black
 ---
 
 ```html
@@ -153,12 +193,19 @@ layout: none
 </p>
 ```
 
-<style>
-.slidev-page, .slidev-code-wrapper, .slidev-code {
-  height: 100%;
-}
-</style>
-
+<!--
+- Most of what you build in Wagtail will come out as HTML
+  - Pages to be shown by the browser
+- But may take lots of intensive actions to create it
+    - Complex lists / filters or suggestions
+    - Finding lots of renditions
+    - Rendering streamfield blocks etc
+- These can all be optimised in many different ways
+  - The deeper down you go, the more complex and often less impactful those optimisations usually are
+- Why not cache an entire chunk of template?
+  - With all of that complexity contained within it
+  - That's the thing people see (sort of)
+-->
 
 ---
 layout: cover
@@ -169,11 +216,34 @@ background: /website-homepage.png
 # My website
 ### https://theorangeone.net
 
+<!--
+- An example: My website
+  - Subtle self-promotion, I know
+- It's a relatively simple blog
+-->
+
 ---
 layout: image
 image: /website-posts.png
 ---
 
+<!--
+ Here's a list of posts
+- Each item has a lot to it
+    - Title
+    - Date
+    - An image (renditions or unsplash)
+    - Introduction text (automatically generated from page content)
+    - Tags
+    - Reading time / Word count
+- These all come from a few different places in code
+    - Database fields
+    - Model properties
+    - Template tags
+- It'd be nice to cache them all together as they are
+    - That's fragment caching!
+-->
+
 ---
 layout: none
 ---
@@ -207,7 +277,7 @@ layout: none
 </article>
 ```
 
-```html {all|3,27|4-26|all}
+```html {all|1-3,27|4-26|all}
 {% load wagtailcore_tags wagtail_cache %}
 
 {% wagtailpagecache FRAGMENT_CACHE_TTL "listing-item" breadcrumbs show_listing_images %}
@@ -244,6 +314,28 @@ layout: none
 }
 </style>
 
+<!--
+- Let's look at the template
+- I like to keep reusable components in separate files
+  - Makes them easier to work with
+  - And makes fragment caching much easier too
+- This has no caching at all
+  - [click]Let's add some
+  - It's just 2 lines of change[click]
+- The tag might look a bit weird
+  - 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
+- [click]The template is in charge of caching itself
+  - Keep the complexities hidden, and in 1 place
+-->
 
 ---
 layout: cover
@@ -251,7 +343,16 @@ background: /website-search.png
 class: text-right
 ---
 
-# Search
+# What about<br>search?
+
+<!--
+ This is a component, it's used in a few different places
+  - There's a posts list, and a search
+  - But the UI for each item is the same
+- It takes the same context: A page, and creates the same HTML
+- If it looks the same, just on different pages, can I reuse it?
+  - Yes!
+-->
 
 ---
 layout: center
@@ -271,11 +372,26 @@ code {
 }
 </style>
 
+<!--
+- Include the template somewhere else, and the cache gets reused
+  - So long as the right variables are available in context
+- Shared components across your site can be accelerated
+  - As can entire sections like the navbar
+-->
+
 ---
 layout: image
 image: /website-search.png
 ---
 
+<!--
+- Caching HTML blocks has a few nice benefits over caching the whole page
+  - Searches are still performed live, but the display of the results are cached
+  - Published pages appear immediately, without needing to invalidate a cache
+-->
+
+---
+layout: full
 ---
 
 # Updating cached content
@@ -312,6 +428,16 @@ code {
 }
 </style>
 
+<!--
+ If I change a page, I want the content to update
+  - How does it know when to regenerate the HTML?
+- [click]`page.cache_key`
+  - Custom attribute on all your pages
+  - [click]You can use it for other things if you need it
+- If a change is published, or the page is moved, the cache key changes, so the existing cache is ignored
+  - And the old cached item will eventually expire
+-->
+
 ---
 layout: center
 ---
@@ -342,6 +468,19 @@ layout: center
 
 </v-click>
 
+<!--
+- This might sound familiar
+  - Django's `{% cache %}`?
+  - This isn't new, Django has had a cache tag for a very long time
+      - In fact, 2007
+- But it's dangerous to use it with Wagtail unmodified
+    - Preview content can get cached
+    - Per-site settings cache the wrong value
+- [click]It's only a few small changes to use Wagtail's
+  - [click]Which wraps this tag, but is aware of the current page and site automatically
+- If you modify the page, the cache is automatically invalidated
+-->
+
 ---
 layout: section
 ---
@@ -349,6 +488,13 @@ layout: section
 ## 2:
 # Frontend Caching
 
+<!--
+- Frontend caching
+- You can spend ages optimising a request
+  - Caching common chunks of HTML
+  - But not handling the request at all is even better
+-->
+
 ---
 layout: fact
 ---
@@ -363,6 +509,13 @@ flowchart LR
   CDN-..->W
 ```
 
+<!--
+- What if we put something in front of Wagtail to serve the requests instead
+  - A CDN (eg Cloudflare, CloudFront)
+  - They cache the page, and serve it themselves
+- A CDN is generally helping you in 2 main ways:
+-->
+
 ---
 layout: fact
 ---
@@ -401,12 +554,32 @@ flowchart TD
   CDN-...->W
 ```
 
+<!--
+Serve a static copy of your website, so your servers aren't processing every request
+- Handle many more requests concurrently
+  - Cloudflare handles 50 million requests per second globally (on average)
+  - Your servers can't
+- Handle more traffic with fewer servers
+- Imagine it like converting your site to be static
+  - 0 Database requests
+  - 0 templates used
+  - 0 cache hits
+-->
+
 ---
 layout: image
 image: https://www.cloudflare.com/network-maps/cloudflare-pops-2O04nulSdNrRpJR9fs9OKv.svg
 class: bg-white
 ---
 
+<!--
+- Store said cached copy closer to your users
+  - Reduced latency
+  - Makes your site seem faster
+  - Even helps on your Google Lighthouse scores
+- Both of these are things you'll want as your website scales
+-->
+
 ---
 layout: cover
 background: /wagtail-homepage.png
@@ -421,17 +594,27 @@ background: /wagtail-homepage.png
   }
 </style>
 
+<!--
+- Let's look at an example: Wagtail.org
+-->
+
 ---
 layout: image
 image: /map.jpg
 transition: fade
 ---
 
+<!--
+- Wagtail.org is hosted in Dublin, Ireland (AWS `eu-west-1`)
+- But I'm in Arnhem
+-->
+
 ---
 layout: cover
 background: /map.jpg
+transition: fade
 ---
-
+## Arnhem &rarr; Ireland
 # ~XXms
 
 <style>
@@ -440,6 +623,33 @@ h1 {
 }
 </style>
 
+<!--
+- XXms away
+- But responses are being served quickly
+  - That's the CDN (Cloudflare, in our case)
+-->
+
+---
+layout: cover
+background: /map.jpg
+---
+
+## Arnhem &rarr; XXX
+# ~XXms
+
+<style>
+h1 {
+  font-size: 4rem;
+}
+</style>
+
+<!--
+- This was actually served from XXX
+  - Just XXms to get a response
+  - Quicker
+  - Closer to us
+-->
+
 ---
 layout: fact
 ---
@@ -461,6 +671,18 @@ flowchart LR
   C-.->CDN
 ```
 
+<!--
+ 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
+- Ensure the CDN knows how long to cache pages for
+  - Cache headers
+  - Configuration in the CDN itself
+  - There's another talk about this
+-->
+
 ---
 layout: fact
 ---
@@ -486,6 +708,13 @@ flowchart LR
   CDN---->W
 ```
 
+<!--
+- 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
+-->
+
 ---
 layout: section
 ---
@@ -513,12 +742,29 @@ flowchart LR
   C-.....->W
 ```
 
+<!--
+- Content is now cached
+  - Pages load much faster
+  - Server load should drop drastically
+    - Might even be able to scale down
+  - Wagtail.org serves ~70% of all page loads from the CDN
+-->
+
 ---
 layout: image
 image: /wagtail-homepage-typo.png
 transition: fade
 ---
 
+<!--
+- Uh oh, there's a typo on one of the pages, better update it
+  - Easy, just publish an update to the page
+    - A quick visit to the admin makes that a breeze
+  - The cache still has the old content
+    - Users see the incorrect content
+  - But how does the CDN know the content has changed?
+-->
+
 ---
 layout: cover
 background: /wagtail-homepage-typo.png
@@ -526,6 +772,15 @@ background: /wagtail-homepage-typo.png
 
 # It doesn't*
 
+<!--
+- Simple: It doesn't!
+    - The whole point of it is it doesn't need to hit Wagtail for every request
+    - So it can't know
+- The cache will expire _eventually_
+    - What if it needs to go out sooner
+    - What if it's more serious than just a typo
+-->
+
 ---
 layout: section
 ---
@@ -534,6 +789,12 @@ layout: section
 # Frontend Cache Invalidation
 ### Wagtail secret sauce <logos-wagtail class="fill-white"/>
 
+<!--
+- Frontend cache invalidation!
+- Wagtail to the rescue
+    - Some magic Wagtail sauce
+-->
+
 ---
 layout: fact
 ---
@@ -557,6 +818,12 @@ flowchart LR
   W-.->|Frontend Cache Invalidation|CDN
 ```
 
+<!--
+- Tighter integrations between Wagtail and the CDN
+- Allows Wagtail to instruct the CDN to clear its cache for a given page
+  - Purging the cache much quicker
+-->
+
 ---
 layout: center
 ---
@@ -606,6 +873,16 @@ code {
 }
 </style>
 
+<!--
+- Integrating is simple
+  - [click]Add entry to `INSTALLED_APPS`
+  - [click]dd credentials and configuration
+    - Wagtail supports quite a few backends!
+- [click]That's it!
+  - All the hooks into all the right places are set up for you!
+    - You can customize this as you need for listing pages / custom configuration etc
+-->
+
 ---
 layout: fact
 ---
@@ -628,6 +905,13 @@ flowchart LR
   CDN-.->C
 ```
 
+<!--
+- When you publish a page, it'll automatically be purged
+  - It can take a minute or so, depending on your CDN
+    - Usually much faster than that
+  - Then when a user loads the page, it's cached, and subsequent loads go back to being lightning fast
+-->
+
 ---
 layout: cover
 background: https://d1nvwtjgmbo5v5.cloudfront.net/media/images/Screen_Shot_2015-05-14_at_09.01.5.2e16d0ba.fill-1200x996.png
@@ -635,6 +919,17 @@ background: https://d1nvwtjgmbo5v5.cloudfront.net/media/images/Screen_Shot_2015-
 
 # Conclusion
 
+<!--
+- 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`
+- 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
+  - More of your code is cached
+  - But a slow page is still a slow page, even if it's not called as often
+-->
+
 ---
 layout: cover
 ---
@@ -653,6 +948,13 @@ layout: cover
 
 </Transform>
 
+<!--
+- So why repeat yourself? Make things faster!
+  - [click]Users are happier
+  - [click]Servers are happier
+  - [click]The planet is happier.
+-->
+
 ---
 layout: end
 ---