Clean up script for smoother delivery

slides.md

@@ -68,6 +68,7 @@ layout: fact
 <!--
 - Disclaimer: This isn't a general performance talk
   - Optimising Python, Django and Wagtail are their own topics
+    - Big 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
@@ -83,11 +84,11 @@ 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
+    - 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
@@ -123,11 +124,12 @@ h1 {
 - 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
+    - Otherwise you'll 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
+  - Where it gets overload by its on popularity
   - Or even if it's not that popular, just shared around a bit
     - Like the recently-discovered Mastodon issue
 -->
@@ -140,6 +142,7 @@ layout: section
 
 <!--
 - Now, back to Wagtail
+  - This is Wagtail Space, after all
 - 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!
@@ -158,8 +161,8 @@ layout: section
 
 <!--
 - Template fragment caching
-  - New ish in 5.2
   - Lots of complex words, but quite a simple concept
+  - Introduced ish in 5.2
 -->
 
 ---
@@ -203,14 +206,17 @@ class: p-0 m-0 bg-black
 <!--
 - 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
+- But probably takes lots of intensive actions to create it
     - Complex lists / filters or suggestions
     - Finding lots of renditions
-    - Rendering streamfield blocks etc
+    - Rendering streamfield blocks
+    - etc 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
+  - The deeper down you go, the more complex and often less impactful those optimisations are
 - Why not cache an entire chunk of template?
   - With all of that complexity contained within it
+  - Rather than cache the name of a page for the navbar
+    - Cache the entire navbar
   - That's the thing people see (sort of)
 -->
 
@@ -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,7 +242,7 @@ image: /website-posts.png
 ---
 
 <!--
- Here's a list of posts
+- Here's a list of posts
 - Each item has a lot to it
   - Title
   - Date
@@ -327,11 +334,15 @@ 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
+  - 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
@@ -342,6 +353,7 @@ layout: none
         - 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<br>search?
 
 <!--
- This is a component, it's used in a few different places
+- The 'listing item' is a component, it's used in a few different places
   - There's a posts list, and a search
+    - And a few others
   - But the UI for each item is the same
-- It takes the same context: A page, and creates the same HTML
+- 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?
+  - Including its cache?
   - Yes!
 -->
 
@@ -393,6 +408,7 @@ image: /website-search.png
 
 <!--
 - Caching HTML blocks has a few nice benefits over caching the whole page
+  - For example, a search page
     - Searches are still performed live, but the display of the results are cached
     - Published pages appear immediately, without needing to invalidate a cache
 -->
@@ -436,13 +452,16 @@ code {
 </style>
 
 <!--
- If I change a page, I want the content to update
+- Cache invalidation is one of the 2 hardest problems in computer science
+  - Alongside naming things and off-by-one errors
+- 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
+- If that's not enough, and you want to manually clear the cache, you can do that too
 -->
 
 ---
@@ -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 %}
 ```
 ````
 
-<v-click>
-
-- Current page
-- Current site
-- Skip in preview
-
-</v-click>
-
 <!--
-- This might sound familiar
+- This might sound familiar to some
-  - Django's `{% cache %}`?
+  - Django's `{% cache %}` tag
   - 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
+  - A host of other weird bugs
-  - [click]Which wraps this tag, but is aware of the current page and site automatically
+- [click]It's only a few small changes to use Wagtail's `wagtailpagecache`
+  - Which wraps this tag, but is aware of the current page and site automatically
 - If you modify the page, the cache is automatically invalidated
+  - If you use the on different sites, they're cached separately
+- If that's not enough, and you want something more manual
+  - [click]There's `wagtailcache`
+  - This doesn't automatically use the page and site
+  - But _does_ ignore preview requests
+  - Making it a closer analogue for Django's `cache` tag
 -->
 
 ---
@@ -496,6 +521,7 @@ layout: section
 # Frontend Caching
 
 <!--
+- Part 2
 - Frontend caching
 - You can spend ages optimising a request
   - Caching common chunks of HTML
@@ -520,7 +546,7 @@ flowchart LR
 - 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:
+- A CDN generally helps you in 2 main ways:
 -->
 
 ---
@@ -562,15 +588,16 @@ flowchart TD
 ```
 
 <!--
-Serve a static copy of your website, so your servers aren't processing every request
+- Firstly: Serve a static copy of your website, so your servers aren't processing every request
-- Handle many more requests concurrently
+- Allows you to 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 Database queries
   - 0 templates used
   - 0 cache hits
+  - 0 lines of code
 -->
 
 ---
@@ -580,7 +607,7 @@ class: bg-white
 ---
 
 <!--
-- Store said cached copy closer to your users
+- Secondly: Store said cached copy closer to your users
   - Reduced latency
   - Makes your site seem faster
   - Even helps on your Google Lighthouse scores
@@ -595,12 +622,6 @@ background: /wagtail-homepage.png
 ## Example
 # https://wagtail.org
 
-<style>
-  code {
-    background-color: transparent !important;
-  }
-</style>
-
 <!--
 - Let's look at an example: Wagtail.org
 -->
@@ -614,6 +635,7 @@ transition: fade
 <!--
 - Wagtail.org is hosted in Dublin, Ireland (AWS `eu-west-1`)
 - But I'm in Arnhem
+  - Quite far away
 -->
 
 ---
@@ -621,6 +643,7 @@ layout: cover
 background: /map.jpg
 transition: fade
 ---
+
 ## Arnhem &rarr; Ireland
 # ~XXms
 
@@ -633,6 +656,7 @@ h1 {
 <!--
 - XXms away
 - But responses are being served quickly
+  - Page loads take just XXms
   - That's the CDN (Cloudflare, in our case)
 -->
 
@@ -652,9 +676,9 @@ h1 {
 
 <!--
 - This was actually served from XXX
-  - Just XXms to get a response
+  - Just XXms from me
+- It's closer to us
   - Quicker
-  - Closer to us
 -->
 
 ---
@@ -682,9 +706,12 @@ 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
+  - If they're cached, return them
-      - It's always DNS
+    - Otherwise, get the actual content from Wagtail
 - Ensure the CDN knows how long to cache pages for
+  - 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
 -->
 
 ---
@@ -784,6 +812,7 @@ background: /wagtail-homepage-typo.png
   - 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_
+  - After an hour or so
   - What if it needs to go out sooner
 - What if it's more serious than just a typo
 -->
@@ -887,7 +916,7 @@ code {
 <!--
 - Integrating is simple
   - [click]Add entry to `INSTALLED_APPS`
-  - [click]dd credentials and configuration
+  - [click]Add configuration and credentials
     - Wagtail supports quite a few backends!
 - [click]That's it!
   - All the hooks into all the right places are set up for you!
@@ -920,7 +949,7 @@ flowchart LR
 - 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
+  - Then when a user loads the page from Wagtail, it's cached, and subsequent loads go back to being lightning fast
 -->
 
 ---
@@ -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