Cacheable describes whether a response may be stored and reused for later identical requests.
It is determined by the combination of method, status code, and cache headers; when set correctly it cuts network round trips, boosting performance and reducing server load.
By default GET and HEAD responses are readily cacheable while POST responses generally are not. Whether and how long something is cached is controlled by `Cache-Control` (max-age, no-store, private, public), `Expires`, and revalidation via `ETag`/`Last-Modified`. For instance, `Cache-Control: public, max-age=31536000, immutable` is ideal for hashed static assets whose filename changes on every build.
A common point of confusion is private vs public. `private` means only a user-specific cache (like the browser) may store it; `public` means shared caches (CDNs, reverse proxies) may store it too. Putting a personalized, per-user response into a shared cache can leak it to other users, so authenticated responses should carefully use `private` or `no-store`. Designing cacheability is the starting point for better TTFB and CDN efficiency.