When a Django app serves static files through WhiteNoise, when should you put a CDN in front, and what must you configure so it works?

## When WhiteNoise alone stops being enough WhiteNoise serves files efficiently, but it still serves them **from the Django process**. Each asset request occupies an application worker for as long as the transfer takes, and visitors far from the server pay the full network round trip for every file. WhiteNoise's own docs say it gives decent performance on moderate-traffic sites and recommend a CDN for higher traffic or where performance matters. The signals that it is time: - Asset requests make up a large share of worker time. - Users are spread far from the origin region. - Traffic spikes, such as a launch, would otherwise hit the app servers for static bytes. ## The shape of the set-up 1. The CDN is configured with the **Django app as its origin**. 2. `STATIC_URL` becomes an absolute URL on the CDN's host, so `{% static %}` renders links to the CDN. 3. The browser asks the CDN; on a miss, the CDN fetches the same path from the origin, where WhiteNoise serves it with its caching headers. 4. Later requests for that URL are answered by the CDN until its cached copy expires. WhiteNoise derives its URL prefix from the **path** component of `STATIC_URL`, so an absolute `STATIC_URL` still leaves the origin serving `/static/`. Only a CDN that rewrites paths needs `WHITENOISE_STATIC_PREFIX` set explicitly. ```python import os STATIC_HOST = os.environ.get('DJANGO_STATIC_HOST', '') STATIC_URL = STATIC_HOST + '/static/' ``` Reading the host from the environment keeps development on local URLs and lets each environment use its own CDN host without code changes. ## What makes it safe to cache for years | File | Header from WhiteNoise | What the CDN can do | |---|---|---| | Hashed, confirmed by the manifest | `max-age=315360000, public, immutable` | keep it effectively forever | | Unhashed | `max-age=60, public` (default `WHITENOISE_MAX_AGE`) | keep it for a minute | A hashed URL can never refer to different bytes, so a deploy never needs a purge for it: new content has a new name, new HTML points at it, and the CDN fetches it on first request. That only holds if templates use `{% static %}` with a manifest-backed storage. ## The details that break it - **Cross-origin fonts.** Assets now come from a different origin than the page. Fonts, and images read back from a canvas, need CORS. `WHITENOISE_ALLOW_ALL_ORIGINS` defaults to `True` and sends `Access-Control-Allow-Origin: *`; turning it off breaks them. - **Compression.** WhiteNoise serves `.br` or `.gz` based on `Accept-Encoding` and sends `Vary: Accept-Encoding`. The CDN must forward that header and cache per encoding, otherwise users may receive only one encoding, or the CDN may substitute its own compression for WhiteNoise's pre-built files. - **The whole site through the CDN.** With the app as origin, every path can be fetched through the CDN host; restrict the CDN to the static prefix to avoid duplicate pages being indexed. - **Rolling deploys.** New HTML can reach users before every origin instance has the new hashed files, and a request that lands on an old instance gets a 404. Bake `collectstatic` output into the image so each instance starts with its assets, and roll out instances before traffic shifts. - **Old hashed files.** A fresh image contains only the current build's hashed files. Pages cached before the deploy may still request the previous ones; the CDN usually still holds them, but if not, the origin returns 404. ## What stays out of this set-up User uploads are not served through WhiteNoise at all, so putting them behind a CDN is a storage-backend decision, not a WhiteNoise one.