DEV Community: Rizwan C

Fetch API Caching: A Complete Guide

Rizwan C — Mon, 11 May 2026 08:10:47 +0000

Caching feature of browser's Fetch API is one of the most powerful — and most misunderstood — tools in web development. It gives you fine-grained control over how HTTP requests interact with the cache through a single cache option. Used correctly, it can dramatically speed up your app, reduce server load, and improve offline resilience. Used incorrectly, it can serve stale data, confuse users, and cause hard-to-debug issues.

Before diving into the options, it's worth understanding what "the cache" actually means here.

When your browser makes an HTTP request, it can store the response in a local cache (the HTTP cache, sometimes called the browser cache). On subsequent requests to the same URL, the browser can serve the response directly from this cache instead of going to the network — making the response near-instant and saving bandwidth.

Servers communicate caching rules via HTTP response headers like Cache-Control,ETag, Last-Modified etc. The cache option in fetch() lets you influence how the browser interacts with the HTTP cache alongside these server-defined rules.

fetch(url, {
  cache: 'default' | 'no-store' | 'reload' | 'no-cache' | 'force-cache' | 'only-if-cached'
})

Important: The cache option influences how the browser interacts with the HTTP cache, but it does not completely override HTTP caching rules or browser behavior. Cache-related response headers such as Cache-Control, ETag, and Last-Modified still play a major role in determining whether a response can be cached, reused, or revalidated.

1. `default` — Standard Browser Behavior

fetch('/api/data')
// equivalent to:
fetch('/api/data', { cache: 'default' })

This is the browser's natural caching behavior — the same as if you typed a URL into the address bar. The browser checks its cache:

If a fresh cached response exists, it returns it immediately without contacting the server.
If the cached response is stale, the browser sends a conditional request (with If-None-Match or If-Modified-Since headers) to check if the content has changed. If unchanged, the server returns 304 Not Modified and the browser uses the cached version. If changed, it returns the new response.
If nothing is cached, it fetches from the network and stores the response.

Use default for any standard data fetch. It's the right choice for most API calls, static assets, and anything where the server is already configured with proper caching policies.

2. `no-store` — Never Cache, Ever

fetch('/api/live-prices', { cache: 'no-store' })

With cache: 'no-store', the browser completely bypasses the HTTP cache. It does not check the cache for an existing response, and it does not store the fetched response in the cache. Every request goes directly to the network, and nothing is saved locally. The response is used once and discarded from a caching perspective.

It is useful when you always need a fresh response from the server and never want the data cached locally. Common use cases include real-time data such as stock prices, live scores, sensor readings, or auction bids; sensitive information like banking transactions, medical records; and scenarios where you need to guarantee that you are seeing the latest server response instead of a cached one.

3. `reload` — Fresh From Network, But Save It

fetch('/api/config', { cache: 'reload' })

The browser skips the cache on the way in (always fetches from the network, as if nothing were cached), but saves the new response to the cache on the way out. Think of it as a "force refresh" — you bypass any existing cached version, but the result is still stored for future use.

Unlike no-cache, reload is intended to bypass cache revalidation logic and fetch a fresh response from the network, updating the cached entry if the response is cacheable.

Use it when you want to bypass the existing cache for a request but still store the fresh response for future use. Common scenarios include after a user explicitly requests a refresh through a reload button, sync action, or pull-to-refresh gesture; after a form submission that updates server-side data and requires the latest state to be fetched; and during app initialization when you want to replace potentially stale cached data with a fresh response while keeping the cache populated for later requests.

4. `no-cache` — Always Check With the Server

fetch('/api/user/settings', { cache: 'no-cache' })

Despite the name, no-cache does use the cache — it just always validates first. The browser sends the request to the server with conditional headers (If-None-Match or If-Modified-Since), asking: "Has this changed since I last cached it?"

If the content hasn't changed, the server responds with 304 Not Modified and the browser uses the cached version. This is fast and bandwidth-efficient.
If the content has changed, the server sends the full new response, which the browser stores and returns.

cache: 'no-cache' works well for data that may change unpredictably but does not require constant real-time updates, such as user settings, feature flags, or notifications. It is also useful for authenticated or user-specific data where freshness matters, but you still want to reduce unnecessary bandwidth usage. In general, use it when you want the browser to verify cached data with the server before using it instead of blindly trusting the local cache.

5. `force-cache` — Use Cache, No Matter What

fetch('/api/countries', { cache: 'force-cache' })

The browser strongly prefers a cached response if one exists, including stale cached entries, without first revalidating with the server. A cached response from last week? Good enough. Only if there's no cached response at all does it go to the network (and then stores the result).

It is useful for data that rarely changes, such as country lists, currency codes, timezone data, or other static configuration values. It also works well in performance-critical situations where fast responses are more important than absolute freshness. Additionally, it can help reduce server load when the underlying data is known to remain stable for long periods.

6. `only-if-cached` — Cache or Bust

fetch('/data/cached-report', {
  cache: 'only-if-cached',
  mode: 'same-origin' // Required!
})

The browser never makes a network request. Instead, it only checks the HTTP cache. If a matching cached response exists — whether fresh or stale — it is returned immediately. If no cached response is found, the fetch rejects with a network error instead of falling back to the network. In other words, only-if-cached means “use the cache exclusively, or return an error.”

It's useful in offline-first applications where you want to display cached data when available and avoid accidental network requests. It is also commonly used in service workers and advanced caching strategies to check whether a resource already exists offline. Additionally, it can be helpful for testing whether a resource is present in the cache without triggering a network fetch.

Note: This must be used with mode: 'same-origin'. Cross-origin requests with only-if-cached will fail regardless.
Note: only-if-cached only works if the response was previously stored in the browser's HTTP cache. Responses marked with headers like Cache-Control: no-store are never cached, so they cannot be retrieved with only-if-cached.

Example:

// Offline-first article reader
async function loadArticle(articleId) {
  try {
    // Try to get from cache first — don't use network
    const response = await fetch(`/api/articles/${articleId}`, {
      cache: 'only-if-cached',
      mode: 'same-origin'
    });

    const article = await response.json();
    renderArticle(article);
    showOfflineBadge(); // Let user know this might not be latest

  } catch (err) {
    // Not in cache — show appropriate message
    if (!navigator.onLine) {
      showOfflineError('This article isn\'t available offline.');
    } else {
      // Online but not cached — fetch normally
      const response = await fetch(`/api/articles/${articleId}`);
      const article = await response.json();
      renderArticle(article);
    }
  }
}

Pushing data in real time. (Long polling vs SSE vs Websocket vs QUIC with working example)

Rizwan C — Sat, 28 Feb 2026 13:51:42 +0000

Long Polling, Server-Sent Events, WebSockets, and QUIC — four ways to keep your clients in sync. Here's exactly how they work, when to use them, and what you're giving up.

Long Polling

Long polling is HTTP pretending to be real-time.
The client makes a normal HTTP request, but the server holds it open — sometimes for seconds or even minutes — until it has data to send. Once the response arrives, the client immediately fires off the next request.

It's a clever trick, and it works everywhere HTTP works. That's its superpower. But every message costs a full request/response cycle, header overhead and all.

How it works: Client polls -> Server waits -> Data arrives -> Server responds -> Connection closes -> Client immediately polls again.

Best for

Legacy system compatibility
Low-frequency updates
Strict corporate firewalls
Simple fallback mechanism

Pros

Works everywhere, any proxy
No special server setup
Easy to understand
Firewall friendly ### Cons
HTTP overhead (new HTTP request each time)
Not truly real-time
Heavy on server resources
Doesn’t scale well

Server-Sent Events (SSE)

SSE creates one persistent HTTP connection where the server streams a series of events down it indefinitely using a simple text format. The browser handles reconnection automatically.
It's unidirectional: server pushes, client listens.

Best for

AI token streaming (ChatGPT-style)
Live notifications
Stock tickers
CI/CD log tailing

Pros

Lightweight
Built in Auto-reconnect
Easy to implement
Great for notifications, dashboards

Cons

Unidirectional
Limited binary support
Not ideal for chat or gaming

WebSocket

WebSocket is what most developers reach for when they say "real-time."
It starts as an HTTP request, performs a protocol upgrade handshake and then becomes a persistent, full-duplex TCP connection. Both sides can send frames at any time, with minimal overhead.

Best for

Multiplayer games
Collaborative editing (Figma, Notion)
Live chat
IoT device control

Pros

Full-duplex
Low latency
Supports binary

Cons

Harder to scale
Needs load balancer config
No automatic reconnection

QUIC (HTTP/3)

QUIC is a modern transport protocol built on UDP, developed by Google. It powers HTTP/3.
QUIC bakes TLS 1.3 into the protocol itself and introduces independent stream multiplexing that eliminates TCP's core flaw: head-of-line blocking.
With TCP, a single lost packet blocks every stream behind it. QUIC streams are truly independent — one dropped packet only stalls its own stream.

Best for

High-performance games
High quality Video streaming (YouTube, Cloudflare)
Latency-sensitive APIs

Pros

Faster than TCP
Better mobile performance
Handles packet loss better
Future of web transport

Cons

Complex
Server infrastructure still maturing
WebTransport API still early

Example codes : https://github.com/rizwanc018/lp_sse_ws_quic

Mastering call, apply, and bind

Rizwan C — Mon, 23 Feb 2026 14:08:13 +0000

Understanding call, apply, and bind is essential if you want to truly master this (JavaScript function context).

In JavaScript, the value of this depends on how a function is called, not where it is defined.

const user = {
  name: "Jon",
  job: "engineer",
  intro() {
    console.log(`${this.name} is ${job}`);
  }
};

user.intro(); // Jon is engineer

But what if we want to use greet for another object?

That’s where call, apply, and bind come in.

call() - invokes function immediately and allows you to pass arguments individually.
apply() - similar to call(), but it accepts arguments as an array.
bind() - Unlike call and apply, bind() does NOT execute immediately. It returns a new function with this permanently bound.

call()

call() method invokes a function immediately. It takes the object you want to use as this as the first argument, followed by individual arguments for the function.

const user1 = { name: "Jon" };
const user2 = { name: "Ron" };

function intro(job) {
  console.log(`${this.name} is ${this.job}`);
}

intro.call(user1, "engineer");   // Jon is engineer
intro.call(user2, "teacher");   // Ron is teacher

apply()

apply() is similar to call(), The only difference is how it handles arguments: it takes them as an array instead of one by one.

function greet(city, country) {
  console.log(this.name + " is from " + city + ", " + country);
}

greet.apply(user1, ["Paris", "France"]); // "Jon is from Paris, France"

bind()

Unlike the other two, bind does not invoke the function immediately. Instead, it returns a new function with this permanently bound to the provided object

const jonIntro = intro.bind(user1, "engineer");

jonIntro(); // Jon is engineer

Polyfill for `call`, `apply` and `bind`

call()

Function.prototype.myCall = function (context, ...args) {
    context = context ?? globalThis;
    context = Object(context);

    const uniqueKey = Symbol();

    context[uniqueKey] = this;
    const result = context[uniqueKey](...args);

    delete context[uniqueKey];
    return result;
};

intro.myCall(user1, "engineer");   // Jon is engineer

apply()

Function.prototype.myApply = function (context, args = []) {
    context = context ?? globalThis;
    context = Object(context);

    const uniqueKey = Symbol();

    context[uniqueKey] = this;
    const result = context[uniqueKey](...args);

    delete context[uniqueKey];
    return result;
};

greet.myApply(user1, ["Paris", "France"]); // "Jon is from Paris, France"

bind()

Function.prototype.myBind = function (context, ...args) {
    const fn = this;

    return function (...newArgs) {
        return fn.apply(context, [...args, ...newArgs]);
    };
};

const jonIntro = intro.myBind(user1, "engineer");
jonIntro(); // Jon is engineer

DEV Community: Rizwan C

Fetch API Caching: A Complete Guide

1. default — Standard Browser Behavior

2. no-store — Never Cache, Ever

3. reload — Fresh From Network, But Save It

4. no-cache — Always Check With the Server

5. force-cache — Use Cache, No Matter What

6. only-if-cached — Cache or Bust

Pushing data in real time. (Long polling vs SSE vs Websocket vs QUIC with working example)

Long Polling

Best for

Pros

Server-Sent Events (SSE)

Best for

Pros

Cons

WebSocket

Best for

Pros

Cons

QUIC (HTTP/3)

Best for

Pros

Cons

Mastering call, apply, and bind

call()

apply()

bind()

Polyfill for call, apply and bind

call()

apply()

bind()

1. `default` — Standard Browser Behavior

2. `no-store` — Never Cache, Ever

3. `reload` — Fresh From Network, But Save It

4. `no-cache` — Always Check With the Server

5. `force-cache` — Use Cache, No Matter What

6. `only-if-cached` — Cache or Bust

Polyfill for `call`, `apply` and `bind`