Skip to content
Optimal Lab

Frontend · interactive

HTTP caching

Response headers tell the browser how long it may reuse a file without asking, and how to ask cheaply when it must check. Get them right and repeat visits load almost nothing; get them wrong and users see stale code after a deploy.

  • index.html304

    Cache-Control: no-cache, ETag: "v41"

    Asks “still v41?” and gets 304 Not Modified: tiny response.

  • app.3f9a1c.jsfrom cache

    Cache-Control: public, max-age=31536000, immutable

    Served from disk. No request at all.

  • logo.pngfrom cache

    Cache-Control: public, max-age=3600

    Within the hour: from cache.

  • /api/cartnetwork

    Cache-Control: private, no-store

    Never stored: always fetched fresh.

Hashed assets never hit the network again; the HTML costs one tiny 304; the API is always live.

Visit

Step 2 of 4

  1. 1

    Fingerprint and cache forever

    Put a content hash in asset filenames and cache them for a year, immutable. A change makes a new name.

    max-age=31536000, immutable

  2. 2

    Always revalidate HTML

    no-cache means “check before using”. With an ETag, unchanged pages cost a 304 with no body.

    no-cache ≠ no-store.

  3. 3

    no-store and private

    Personal or sensitive responses shouldn't sit in shared caches, or any cache.

    CDNs honour s-maxage separately.

  4. 4

    stale-while-revalidate

    Serve the cached copy instantly and refresh it in the background for next time.

    max-age=60, stale-while-revalidate=600

In production

Tools and technologies

Cache headers decide how repeat visits load.

Not tied to one language — use these names when you search docs or design a system.