Quick answer: fast Django pages come from four layers in order: quick server response (queries, caching), small compressed assets, non-blocking JavaScript and fonts, and right-sized images. Measure with PageSpeed Insights and Search Console's Core Web Vitals report first — optimising without measuring means tuning the wrong layer. Most business sites we see lose their speed budget to unoptimized images and render-blocking scripts, not to Django itself.
Step 0: measure the right thing
Run the URL through PageSpeed Insights (mobile first) and note LCP, INP, and CLS separately — each has different fixes. Check Search Console's Core Web Vitals for the site-wide pattern: one slow template (often the homepage or a listing page) usually drags the whole average. Record the numbers before changing anything; otherwise you cannot tell which fix worked.
Layer 1: server response (TTFB)
Django-specific wins: kill N+1 queries with select_related/prefetch_related (the single most common Django slowdown), add DB indexes on filtered/ordered columns, cache expensive fragments and querysets in Redis, keep Gunicorn workers matched to CPU, and compress responses (WhiteNoise + Brotli/Gzip). A page doing 200 queries will never feel fast no matter how pretty the frontend is.
Layer 2: asset weight
Serve one minified CSS/JS path, enable Brotli at the proxy, and audit images ruthlessly — on our own site, resizing the logo from 1536px to display-appropriate 768px cut 76% of its bytes, and re-encoding the favicon properly cut 99%. Apply the same method to every template image: resize to a small multiple of displayed size, serve WebP with a PNG/JPEG fallback, and add explicit width/height to kill layout shift.
Layer 3: render-blocking JS, fonts, and third parties
Defer every script that isn't needed for first paint, preconnect to CDN origins you actually use, subset font weights (loading eight weights of two families is a classic self-inflicted wound), and question each third-party tag: chat widgets, heatmaps, and pixels each tax INP. Our rule: every tag must justify itself against a conversion it measurably supports.
The checklist (in priority order)
- Today: compress + resize all template images; add width/height; enable text compression; defer non-critical JS.
- This week: fix N+1 queries; add missing DB indexes; fragment-cache the slowest view; subset fonts.
- This month: Redis object caching; CDN for static/media; remove or lazy-load one heavy third-party script; re-measure and compare.
When tuning isn't enough
If the stack is a page-builder with 40 plugins or a theme loading five sliders, tuning buys 20% and a focused rebuild buys 70%. Signs you need the rebuild: template count in triple digits, no one knows what half the plugins do, or mobile PageSpeed stuck red after the checklist above. A clean hand-built business site starts fast instead of being optimised back to fast.
FAQs
Does speed directly affect Google rankings?
Page experience signals (including Core Web Vitals) are ranking inputs, but the bigger effect is conversion: slow pages lose visitors before rankings even matter. Fix speed for revenue first, rankings second.
What should I ask a developer about speed?
Ask for before/after PageSpeed numbers on mobile, what they changed per layer above, and how they prevent regression (budgets, image rules). If the answer is "we installed a caching plugin," keep interviewing. Or skip the quiz — our free audit includes a speed and technical SEO pass over your current site.
