When choosing the tech stack for a project, we often ask ourselves what kind of website we'll be building to better assess the right options for the project.

Every option has its own tradeoffs, so making sure we choose the one that best fits the project requirements is a must. But making this decision can be challenging once project requirements change in the future, and what looks like a good solution now can very well not be later.

In this article, we'll go through one of web developers' most complex problems: cache.

Caching

• What should be cached?
• How long should it be cached for?
• How/When should the cache be updated?

These questions are often underestimated, and the results can lead to unintended behaviors in our users. And before we can answer the previous questions, we should know what a cache is and what kind of caches are available for us.

What is a cache?

A cache is a spot to put stuff. It temporarily stores data, so you don't have to get it whenever you need it. It enhances the performance of recently or frequently accessed data, according to your context.

Types of caches

There are two main types of caches in the HTTP Caching specification: private caches and shared caches.

Private caches

A private cache is a cache bonded to a specific client, typically a browser cache. Since the response isn't shared with other clients, a private cache can store a personalized response for that user.

You must specify a private directive if a response contains personalized content and you want to store the response only in the private cache.

Suppose personalized contents are stored in a cache other than a private cache. In that case, other users may be able to retrieve those contents, which may cause the information to be leaked unintentionally.

Note that if the response has an Authorization header, it cannot be stored in the private cache (or a shared cache, unless public is specified).

Shared cache

The shared cache is located between the client and the server and can store responses that can be shared among users. And shared caches can be further sub-classified into:

• Proxy caches: In addition to the access control function, some proxies implement caching to reduce traffic out of the network. The service developer doesn't usually manage this, so appropriate HTTP headers must control it.
• Managed caches: service developers explicitly deploy managed caches to offload the origin server and deliver content efficiently. Examples include reverse proxies, CDNs, and service workers in combination with the Cache API.
• It's also possible to ignore the standard HTTP Caching spec protocols in favor of explicit manipulation. For example, the following can be specified to opt-out of a private cache or proxy cache, while using your own strategy to cache only in a managed cache.