Add speaker notes
This commit is contained in:
parent
734fba8064
commit
69c0fae0c0
GPG key ID:
57AFB45680EDD477
1 changed files with 328 additions and 26 deletions
354
slides.md
354
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 → 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 → 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
|
||||
---
|
||||
|
|
|
|||
Loading…
Reference in a new issue