Cache control and cache keys

Cache behaviour is the single largest lever on origin egress and delivered cost. The goal is simple — serve as many bytes as possible from the edge without ever serving stale or wrong content — but the mechanism depends on what you cache, how long, and what the cache key includes. This page covers cache modes, TTLs, origin versus edge policy, and key composition.

Cache modes and TTL

A resource applies a cache mode that decides how aggressively the edge caches and when it revalidates origin.

TTLs should reflect how the object changes, not how often it is requested. Versioned media (…-v3.mp4, hashed filenames) can be cached for days or weeks because the name changes when the bytes do. Manifests change constantly and need short TTLs. Thumbnails and static assets sit in between.

Origin versus edge policy

Two authorities can set caching: the origin, via Cache-Control, and the edge, via the resource. Decide which wins deliberately.

• Origin-controlled keeps the edge a faithful mirror. Good when many teams own content and the origin is trusted to be correct.
• Edge-controlled overrides origin headers. Good when origin headers are inconsistent or when you want one policy across heterogeneous backends.

A practical split: let origin set s-maxage for shared caches, and use the resource to clamp, extend, or ignore it. Always define a sensible default for responses with no caching headers — an uncacheable-by-accident media response is an origin-egress incident waiting to happen.

Cache-key composition

The cache key is everything that identifies a unique cached object. Every field you add to it multiplies the number of stored variants and divides hit ratio. Keep the key minimal: by default, the host and path, plus only the query parameters that genuinely change the response.

• Normalise case, trailing slashes, and parameter order so equivalent requests share one entry.
• Whitelist query parameters that affect content (for example, ?quality=), and drop the rest.
• Use the Vary header carefully. Vary: Accept-Encoding is normal; Vary: User-Agent fragments the cache into thousands of near-duplicates.
• Do not include cookies in the key unless a cookie truly changes the object.

Per-viewer parameters destroy hit ratio

The most common adult-platform cache failure is a per-viewer parameter in the URL — a session ID, a token, an analytics or cache-buster value, a device fingerprint. Each unique value produces a unique cache key, so the cache becomes a pass-through and origin egress tracks requests instead of viewership.

Keep authentication out of the reusable cache key. Validate entitlement at the edge while deriving the media key only from fields that change the object. See Secure token and signed access. A signed URL should identify the same cached object regardless of who holds the signature.

CDN-Cache-Control (RFC 9213)

RFC 9213 defines CDN-Cache-Control, a response header aimed at shared caches while leaving the browser’s Cache-Control untouched. This lets an origin tell the edge to cache for an hour while telling browsers to revalidate on every use, or vice versa. Use it when browser and edge lifetimes genuinely differ — for example, a manifest the edge holds for 30 seconds but the player must refetch each session. Pair it with Cache-Status (RFC 9211) to make cache behaviour observable per response.

Byte offload is the KPI

Request-hit ratio is a poor proxy on adult sites, where images dominate request counts and video dominates bytes. Track byte offload — the share of delivered bytes served from the edge — and origin bytes as the primary cache metrics. A high request-hit ratio can hide expensive origin video egress. See Why tube-site video buffers for the request-versus-byte divergence.

Where AdultInfra fits

AdultInfra designs cache modes, TTLs, and key composition around your actual traffic shape, then proves the result on a controlled slice: byte offload, origin bytes, and delivered cost against the incumbent path. Bring one hostname and the metric you want to move and talk to us.