Performant Django
summary
Front-end work takes 80–90% of user response time so start by caching static assets forever (Django’s cacheable static file storage), bundling/minifying with django-pipeline or webassets, and serving via CDN from S3 with django-storages — doing so cuts hundreds of milliseconds on real endpoints. Back end uses profiling (django-debug-toolbar, dev server) to find SQL hot spots and Python hotspots; use select_related/prefetch_related, only/defer, bulk_create, denormalize, or targeted function-level caching (worked via a tiny cache-helper) to remove surprising costs like 50,000 reverse calls or a decimal constant costing ~0.25s.
AI-written summary · about
chapters (17)
- 0:00Intro
- 1:13But first, a quick note about frontend performance
- 2:02Front-End Performance Work
- 3:11Best Practice: Cache static assets forever (as long as they don't change)
- 4:40Best practice: Bundle/minity/ compress static assets
- 7:39Best Practice: Serve static files via a CDN.
- 8:40Best Practice: Serve more stuff as static assets.
- 10:24Back-End Performance Work
- 13:42Backend performance work starts with a profile of the "problem" view Use a profiler middleware!
- 14:31What does a profile look like?
- 15:45Understanding a profile
- 16:27What if the problem is SQL?
- 17:59SQL Tricks, Part 2
- 24:43What if the problem is SQL and none of the above helps?
- 26:18What if the problem is in the Python?
- 28:29Example 2
- 32:56Many types of caching
related talks
28mThe life of a web request - techniques for measuring and improving Django application performance
45mCutting latency in half: What actually worked—and what didn’t
31mHigh Performance Django
21mHigh-Availability Django
47mHigh Performance Django at Ten: Old Tricks & New Picks
32mGreen Coding with Django
45mCaching: A trip down the rabbit hole
28mPython: Ludicrous mode (with Django)