DEV Community: Ben

React's Render Pipeline: A Deep Dive From JSX to the Screen

Ben — Mon, 01 Dec 2025 15:19:21 +0000

How does React transform this code into a visible, interactive interface on the screen? What really happens behind the scenes?

This article provides a deep dive into React's complete rendering pipeline, step by step. We'll use the mental model of a simplified React implementation (like a "mini-react") to understand its core mechanics.

1. The Render Pipeline at a Glance 🏭

Think of React's render pipeline as a factory assembly line:

Raw Materials: Your JSX code.

Initial Processing: It's converted into a Virtual DOM.

Assembly Structure: A Fiber Tree is constructed.

Quality Control: The Diffing Algorithm finds what changed.

Final Product: The real DOM is updated.

The entire flow looks like this:

JSX → Virtual DOM → Fiber Tree → Reconciliation (Diffing) → DOM Commit

Let's break down each stage.

2. Step One: From JSX to Virtual DOM 📄

2.1 What is the Virtual DOM?

The Virtual DOM (VDOM) is a programming concept where a representation of a UI is kept in memory and synced with the "real" DOM. In React, it's a lightweight tree of JavaScript objects that describes what the UI should look like. It's the "blueprint" for the real DOM.

Why do we need a VDOM?

Directly manipulating the real DOM is slow:

Modifying an element forces the browser to recalculate styles, layout, and repaint.
Multiple modifications can trigger this expensive process multiple times.
This leads to performance bottlenecks and a sluggish UI.

The VDOM acts as a middleman:

It's fast to create and modify JavaScript objects in memory.
React can compare the new blueprint with the old one to find the minimal set of changes.
These changes are then "batched" and applied to the real DOM in one go.

2.2 The JSX Transformation

When you write JSX:

<div className="container">
  <h1>Hello</h1>
  <p>World</p>
</div>

A compiler like Babel transforms it into React.createElement() calls:

// The core logic of createElement
const createElement = (type, props = {}, ...children) => {
  // Children that are simple strings or numbers become text nodes
  const processedChildren = children.map((child) =>
    typeof child === 'object' ? child : createTextElement(String(child))
  );

  return {
    type, // 'div'
    props: {
      ...props, // { className: 'container' }
      children: processedChildren,
    },
  };
};

// A special function to create text elements
const createTextElement = (text) => ({
  type: 'TEXT_ELEMENT',
  props: {
    nodeValue: text,
    children: [],
  },
});

This produces a VDOM object tree:

{
  type: 'div',
  props: {
    className: 'container',
    children: [
      { type: 'h1', props: { children: [{ type: 'TEXT_ELEMENT', props: { nodeValue: 'Hello' } }] } },
      { type: 'p', props: { children: [{ type: 'TEXT_ELEMENT', props: { nodeValue: 'World' } }] } }
    ]
  }
}

2.3 Handling Function Components

When the type is a function (a function component), React calls that function during the render phase:

function Welcome({ name }) {
  return <h1>Hello, {name}!</h1>;
}

<Welcome name="React" />

The process is:

createElement creates a VDOM node where type is the Welcome function itself.
During rendering, React sees that the type is a function and calls it: Welcome({ name: 'React' }).
The return value of the function (another VDOM node, <h1>...</h1>) is then processed.

3. Step Two: Building the Fiber Tree 🌳

3.1 What is Fiber?

Introduced in React 16, Fiber is the new reconciliation engine. A Fiber node is an enhanced VDOM node. Each Fiber corresponds to a component or element and contains more information, turning the VDOM tree into a linked list of work units.

A Fiber Node's Structure:

interface FiberNode {
  type: string | Function;      // The component or element type
  props: object;                // Its props
  dom: Element | null;          // A pointer to the real DOM node
  child: FiberNode | null;      // Pointer to the first child Fiber
  sibling: FiberNode | null;    // Pointer to the next sibling Fiber
  return: FiberNode | null;     // Pointer to the parent Fiber (the 'return' keyword is reserved)
  alternate: FiberNode | null;  // A link to the old Fiber from the previous render
  effectTag: string;            // Describes the work to be done (e.g., 'UPDATE', 'PLACEMENT')
  hooks?: any[];                // State storage for Hooks
}

Why was Fiber necessary?

The old reconciler (in React 15 and earlier) was synchronous and uninterruptible. If the component tree was large, the main thread would be blocked for a long time, freezing the UI and making user interactions feel laggy.

Fiber's advantages:

It breaks rendering work into small, manageable chunks.
It can pause, resume, and abort work.
It supports scheduling work based on priority.
It performs work during the browser's idle periods.

3.2 Building the Fiber Tree

The Fiber tree is built using a depth-first traversal:

// A function that processes one unit of work (one Fiber)
const performUnitOfWork = (fiber) => {
  // 1. For function components, call the function to get its children
  if (typeof fiber.type === 'function') {
    reconcileChildren(fiber, [fiber.type(fiber.props)]);
  }
  // 2. For host components (like 'div'), create the DOM node
  else if (typeof fiber.type === 'string') {
    if (!fiber.dom) {
      fiber.dom = createDOM(fiber);
    }
    reconcileChildren(fiber, fiber.props.children);
  }

  // 3. Return the next unit of work
  if (fiber.child) {
    return fiber.child; // First, go deep
  }

  // 4. If no child, look for a sibling, then go up to the parent
  let nextFiber = fiber;
  while (nextFiber) {
    if (nextFiber.sibling) {
      return nextFiber.sibling; // Then, go sideways
    }
    nextFiber = nextFiber.return; // Finally, go up
  }

  return null; // All done
};

The traversal order for a <div><h1></h1><p></p></div> tree would be: div → h1 → p → (back up to) div. This linked list structure allows React to pause at any point and resume later.

3.3 Time Slicing

React uses requestIdleCallback to schedule work during browser idle time:

// The main work loop
const workLoop = (deadline) => {
  let shouldYield = false;
  while (nextUnitOfWork && !shouldYield) {
    nextUnitOfWork = performUnitOfWork(nextUnitOfWork);
    shouldYield = deadline.timeRemaining() < 1;
  }

  // If all work is done, commit the changes to the DOM
  if (!nextUnitOfWork && workInProgressRoot) {
    commitRoot();
  }

  // Request the next idle period to continue working
  requestIdleCallback(workLoop);
};

// Start the loop
requestIdleCallback(workLoop);

How Time Slicing Works:

The browser tells React, "You have 5ms of free time."
React works on as many Fiber nodes as it can within those 5ms.
Time's up! React yields control back to the browser, which can now handle user input.
When the browser is idle again, React resumes its work.

This ensures that even a massive render job won't block the main thread, keeping the UI responsive.

4. Step Three: Reconciliation and the Diffing Algorithm 🔍

Reconciliation is the process React uses to compare two VDOM trees to find the differences. This process is often called the "diffing algorithm."

The Goal of Reconciliation:

Find which nodes need to be updated.
Find which nodes need to be deleted.
Find which nodes need to be added.
Reuse existing DOM nodes as much as possible.

4.2 The Diffing Heuristics

React's diffing algorithm follows a few simple rules for performance:

It only diffs nodes at the same level. It won't try to match a <div> at level 2 with a <div> at level 4.
key props optimize lists. A stable key helps React identify if a node was moved, added, or deleted.
Different types produce different trees. If an element's type changes (e.g., from <div> to <span>), React tears down the old tree and builds a new one from scratch.

Core Reconciliation Logic:

const reconcileChildren = (wipFiber, newChildren) => {
  let oldFiber = wipFiber.alternate?.child; // The fiber from the previous render

  for (let i = 0; i < newChildren.length || oldFiber; i++) {
    const newElement = newChildren[i];
    const isSameType = oldFiber && newElement && oldFiber.type === newElement.type;
    let newFiber = null;

    // Case 1: Same type, update props
    if (isSameType) {
      newFiber = {
        type: oldFiber.type,
        dom: oldFiber.dom, // Reuse the DOM node
        alternate: oldFiber,
        props: newElement.props,
        return: wipFiber,
        effectTag: 'UPDATE', // Mark for update
      };
    }

    // Case 2: Different type, create new node
    if (!isSameType && newElement) {
      newFiber = {
        type: newElement.type,
        dom: null, // A new DOM node needs to be created
        props: newElement.props,
        return: wipFiber,
        effectTag: 'PLACEMENT', // Mark for placement
      };
    }

    // Case 3: Old node is gone, delete it
    if (!isSameType && oldFiber) {
      oldFiber.effectTag = 'DELETION';
      deletions.push(oldFiber); // Add to a deletions list
    }

    // ... link fibers together (child/sibling) and advance oldFiber ...
  }
};

By comparing newChildren with oldFiber, React efficiently determines the fate of each node.

5. Step Four: The Commit Phase 🚀

This is the grand finale. The Commit Phase is where React applies all the calculated changes to the real DOM. This phase is synchronous and uninterruptible.

Why can't the Commit Phase be interrupted?

If it were, the user might see a half-updated, broken UI. To ensure a consistent view, all DOM mutations must happen in a single, atomic operation.

5.2 Three Types of Commit Operations

The commit phase iterates through the list of Fibers with effectTags and performs three main operations:

**PLACEMENT**: Add a new node to the DOM.
**UPDATE**: Update the attributes or content of an existing node.
**DELETION**: Remove a node from the DOM.

Simplified Commit Logic:

const commitRoot = () => {
  // 1. First, perform all deletions
  deletions.forEach(commitWork);

  // 2. Then, perform all placements and updates
  commitWork(workInProgressRoot.child);

  // 3. Save the current tree for the next render
  currentRoot = workInProgressRoot;
  workInProgressRoot = null;
};

const commitWork = (fiber) => {
  if (!fiber) return;

  // ... find the nearest parent with a DOM node ...

  if (fiber.effectTag === 'PLACEMENT' && fiber.dom) {
    parentDOM.appendChild(fiber.dom);
  } else if (fiber.effectTag === 'UPDATE' && fiber.dom) {
    updateDOM(fiber.dom, fiber.alternate.props, fiber.props);
  } else if (fiber.effectTag === 'DELETION') {
    parentDOM.removeChild(fiber.dom);
  }

  // Recursively commit children and siblings
  commitWork(fiber.child);
  commitWork(fiber.sibling);
};

6. How Hooks Work 🎣

6.1 useState Under the Hood

How does useState "remember" its value between renders? It stores the state on the component's Fiber node.

let wipFiber = null;
let hookIndex = 0;

function useState(initialState) {
  // Get the old hook from the previous render, if it exists
  const oldHook = wipFiber.alternate?.hooks?.[hookIndex];

  // Initialize the hook with the old state or initial state
  const hook = {
    state: oldHook ? oldHook.state : initialState,
    queue: [], // A queue of state updates
  };

  // Process any pending updates in the queue
  const actions = oldHook ? oldHook.queue : [];
  actions.forEach(action => {
    hook.state = typeof action === 'function' ? action(hook.state) : action;
  });

  // The setState function
  const setState = (action) => {
    hook.queue.push(action);
    // Trigger a new render
    wipRoot = { ... };
    nextUnitOfWork = wipRoot;
    deletions = [];
  };

  // Add the hook to the fiber and increment the index
  wipFiber.hooks.push(hook);
  hookIndex++;

  return [hook.state, setState];
}

6.2 The Rules of Hooks

Crucially, Hooks must be called in the same order on every render.

React doesn't identify hooks by name; it identifies them by their call order. hookIndex is reset to 0 at the beginning of each component render.

// ❌ WRONG: The call order changes
function Component({ condition }) {
  if (condition) {
    useState(0); // Sometimes hook #0
  }
  useState('');    // Sometimes hook #0, sometimes hook #1
}

// ✅ CORRECT: The call order is always the same
function Component({ condition }) {
  const [count, setCount] = useState(0); // Always hook #0
  const [name, setName] = useState('');     // Always hook #1
}

This is why you can't put Hooks inside conditions, loops, or nested functions.

7. A Full Example: Initial Render vs. Update

7.1 Initial Render

React.render(<Counter />, document.getElementById('root'));

Render Phase: React builds a Fiber tree for Counter, div, h1, and button, creating DOM nodes for each in memory. Each gets a PLACEMENT effect tag.
Commit Phase: React appends the div, h1, and button to the real DOM.

7.2 Update Render

The user clicks the button, calling setCount(1).

Trigger Update: setState queues an update and schedules a new render.
Render Phase (Reconciliation):

React compares the new VDOM with the old one.
It finds the h1's text content changed from "Count: 0" to "Count: 1".
The h1's Fiber node gets an UPDATE effect tag. Other nodes have no changes.

Commit Phase:

React sees the UPDATE tag on the h1 Fiber.
It performs a single DOM operation: h1.textContent = 'Count: 1'.
The div and button are untouched.

8. Conclusion

React's rendering pipeline is a masterclass in engineering that balances performance, developer experience, and maintainability.

Key Takeaways:

✅ Virtual DOM: A lightweight in-memory representation for efficient diffing.
✅ Fiber Architecture: Enables interruptible rendering, time slicing, and prioritization.
✅ Reconciliation (Diffing): An efficient algorithm to find minimal DOM changes.
✅ Hooks: Leverage the Fiber architecture to attach state to function components.

Understanding these mechanics empowers you to:

🎯 Write better, more performant code.
🐛 Debug performance issues effectively.
🚀 Master the broader React ecosystem.

By demystifying this "magic," we become more capable and confident React developers.

Over to You
What part of React's render pipeline surprised you the most? Or do you have a favorite performance optimization trick related to rendering? Share your thoughts in the comments below! 👇

References

ES2025 is Coming! 5 New Features That Will Change How You Write JavaScript

Ben — Mon, 01 Dec 2025 13:20:32 +0000

The annual ECMAScript update always breathes new life into the JavaScript ecosystem. As we look forward to ES2025, several exciting proposals have already reached "Stage 4," meaning they are officially ready to be included in the next version of the JavaScript standard.

Today, let's explore five of the most impactful new features and see how they can simplify our code and boost our productivity.

1. `Promise.withResolvers()` - The New Way to Create Promises

In the past, creating a Promise that you could resolve or reject from outside its scope required some boilerplate code:

// The old way
let resolve, reject;
const promise = new Promise((res, rej) => {
  resolve = res;
  reject = rej;
});

// Used elsewhere in your code
doSomething().then(() => {
  resolve('Operation successful!');
});

This pattern is clunky and a bit error-prone. ES2025 introduces Promise.withResolvers() to clean this up beautifully.

// ✨ The new ES2025 way
const { promise, resolve, reject } = Promise.withResolvers();

// Now you can use them directly
setTimeout(() => {
  resolve('Data loaded!');
}, 2000);

promise.then(value => {
  console.log(value); // Logs after 2 seconds: "Data loaded!"
});

Why it's cool: It provides a cleaner, more intuitive API for creating externally-controlled Promises, perfect for scenarios like event handling, async queues, and more.

2.Array.prototype.toSpliced() - The Immutable splice()

We all know Array.prototype.splice() is a destructive method—it mutates the original array. This is a big no-no in functional programming and state management libraries like React. To work around this, we often have to create a copy first:

// The old way
const original = [1, 2, 3, 4, 5];
const copy = [...original];   // 1. Create a copy
copy.splice(1, 2, 'a', 'b');  // 2. Mutate the copy

console.log(copy);     // [1, "a", "b", 4, 5]
console.log(original); // [1, 2, 3, 4, 5] (Unchanged)

Now, toSpliced() does this in a single, elegant step:

// ✨ The new ES2025 way
const original = [1, 2, 3, 4, 5];
const result = original.toSpliced(1, 2, 'a', 'b');

console.log(result);   // [1, "a", "b", 4, 5]
console.log(original); // [1, 2, 3, 4, 5] (Still unchanged!)

Why it's cool: Along with toSorted() and toReversed(), this method provides an immutable version of a classic array operation, leading to safer and more predictable code.

3. Object.groupBy() and Map.groupBy() - Effortless Data Grouping

Grouping data is an incredibly common task. Imagine you have a list of products and you want to group them by category.

const inventory = [
  { name: 'Asparagus', type: 'Vegetable', quantity: 5 },
  { name: 'Banana', type: 'Fruit', quantity: 0 },
  { name: 'Goat', type: 'Meat', quantity: 23 },
  { name: 'Cherry', type: 'Fruit', quantity: 5 },
  { name: 'Fish', type: 'Meat', quantity: 22 },
];

Previously, you'd likely reach for reduce:

// The old way
const grouped = inventory.reduce((acc, item) => {
  const key = item.type;
  if (!acc[key]) {
    acc[key] = [];
  }
  acc[key].push(item);
  return acc;
}, {});
// Result: { 'Vegetable': [...], 'Fruit': [...], 'Meat': [...] }

With Object.groupBy(), this becomes a one-liner:

// ✨ The new ES2025 way
const grouped = Object.groupBy(inventory, ({ type }) => type);

console.log(grouped);
/* Output:
{
  "Vegetable": [ { name: "Asparagus", type: "Vegetable", quantity: 5 } ],
  "Fruit": [ { name: "Banana", type: "Fruit", quantity: 0 }, { name: "Cherry", type: "Fruit", quantity: 5 } ],
  "Meat": [ { name: "Goat", type: "Meat", quantity: 23 }, { name: "Fish", type: "Meat", quantity: 22 } ]
}
*/

There's also Map.groupBy(), which works similarly but returns a Map, allowing you to use non-string keys.

Why it's cool: It transforms a common, moderately complex operation into a simple, declarative function call, drastically improving code readability and conciseness.

4.ArrayBuffer.prototype.transfer() - Zero-Cost Memory Transfer

ArrayBuffer is the core object for handling binary data. In high-performance scenarios, you often want to transfer ownership of an ArrayBuffer to another context (like a Web Worker) instead of copying it, which can be expensive.

The transfer() method lets you do just that. It detaches the original ArrayBuffer and returns a new one pointing to the same memory.

// ✨ The new ES2025 way
const originalBuffer = new Uint8Array([1, 2, 3]).buffer;
console.log(originalBuffer.byteLength); // 3

// Transfer ownership
const newBuffer = originalBuffer.transfer();

console.log(originalBuffer.byteLength); // 0 (The original is now detached)
console.log(newBuffer.byteLength);      // 3 (The new buffer owns the data)

Why it's cool: This is a massive performance win for data-intensive applications like file uploads, video/audio streaming, and WebAssembly, enabling true zero-copy memory transfers.

Conclusion

The new features coming in ES2025 are a testament to JavaScript's continuous evolution. They are designed to make our lives as developers easier, our code cleaner, and our applications more performant. From simplified async patterns to safer array methods and powerful data manipulation, these tools are set to become indispensable parts of our daily coding toolkit.

While it might take a little time for them to be available in all browsers and Node.js versions, learning about them now will keep you ahead of the curve.

Browser Caching Explained: From Principles to Practice

Ben — Sat, 29 Nov 2025 09:36:57 +0000

In today's internet era, website performance optimization has become an indispensable part of frontend development. Among various optimization techniques, browser caching is one of the most effective ways to improve website performance. This article will explain browser caching mechanisms in depth, helping you better understand and use caching strategies.

What is Browser Caching?

Code and resources on web pages are downloaded from servers. If the server and the user's browser are far apart, the download process can be time-consuming, making the webpage load slowly. When you visit the same webpage again, it needs to be downloaded again. If the resources haven't changed, this re-download is unnecessary. Therefore, HTTP designed a caching feature that can save downloaded resources locally. When you open the webpage again, it reads directly from the cache, which naturally speeds things up significantly.

Why Do We Need Browser Caching?

In practical applications, browser caching offers several important advantages:

Improve Access Speed
- Read resources directly from local storage, eliminating network request time
- Reduce page white screen time, improving user experience
Save Network Resources
- Reduce duplicate network requests
- Lower server pressure
- Save user bandwidth
Enhance Website Performance
- Reduce server load
- Improve website response speed
- Optimize overall user experience

Browser Caching Mechanisms Explained

Browser caching mechanisms are mainly divided into two categories: Force Cache and Negotiation Cache. It's like shopping - some products have fixed expiration dates (force cache), while others need to be opened and checked to know if they're still usable (negotiation cache).

1. Force Cache

Force cache is the process of looking up the request result in the browser cache and deciding whether to use the cached result based on the cache rules. However, we can't cache forever, otherwise when resources change, users will still see old resources. So we need to set a cache expiration time. Expires and Cache-Control are used to set the cache expiration time.

Control Fields: Cache-Control and Expires

1. Expires (HTTP/1.0)

Expires is a header in HTTP/1.0 that represents the expiration time of a resource.

Expires: Wed, 21 Oct 2025 07:28:00 GMT

Example:

const data = fs.readFileSync('./01.png');
res.writeHead(200,{
   expires:new Date("2024-10-15 22:39:00").toUTCString()
 })
 res.end(data)

We set the expiration time to 2024-10-15 22:39:00. On the first request, the server returns a 200 status code and the resource, and the browser caches this resource.

If you refresh before 39 minutes, it displays directly from disk cache.

If you refresh after 39 minutes, it re-requests the resource and displays from the server.

The obvious drawback is that it depends on a fixed time (Greenwich Mean Time, no timezone issues). What if the client's local time is inconsistent with the server time? For example, I can directly modify my computer time to 2023 or 2025, then the cache becomes invalid.

2. Cache-Control (HTTP/1.1)

To solve the problem of client-server time inconsistency, Cache-Control was introduced, which uses relative time to solve this problem, allowing the browser to calculate whether it has expired.

Cache-Control: max-age=2000

The above means the resource is cached for 2000 seconds, which is 33 minutes.

no-cache means negotiation cache needs to be used to verify if it has expired
no-store means browser caching is prohibited, always request from the server
public means it can be cached by any intermediary
private means it can only be cached by the user's browser

cache-control:public,max-age=2000 means it can be cached by any intermediary and cached for 2000s

cache-control:private,max-age=2000 means it can only be cached by the user's browser and cached for 2000s

cache-control:no-cache,max-age=2000 means negotiation cache needs to be used to verify if it has expired and cached for 2000s

cache-control:no-store means browser caching is prohibited, always request from the server

Note: Previously, all forms were key:value format, but HTTP 1.1's cache control header Cache-Control can set multiple parameters, centralizing all cache-related headers together, separated by commas.

Expires: xxx is called a message header (header)

max-age in Cache-Control: max-age=xxx is called a directive

Example:

const data = fs.readFileSync('./01.png');
res.writeHead(200,{
   "Cache-Control":"max-age=60"
 })
 res.end(data)

max-age=60 means force cache can be used within 60 seconds. If more than 60 seconds have passed, it needs to be re-fetched.

The browser records the Date time. Within one minute, subsequent fetches go directly to cache.

If more than 60 seconds have passed, it re-fetches.

Note: Advantages of Cache-Control over Expires:

Uses relative time, avoiding the problem of client time being out of sync with server time

Provides more control options

However, even when the expiration time is reached, the resource doesn't necessarily become invalid. For example, if I modify the resource but don't change the resource name, the browser will still use the cache. So we need to use negotiation cache to solve this problem.

2. Negotiation Cache

Negotiation cache is the process where, after force cache expires, the browser sends a request to the server with cache identifiers, and the server decides whether to use the cache based on these identifiers.

Control Fields: Last-Modified and ETag

1. Time-based Negotiation Cache

Last-Modified is a header in HTTP/1.0 that represents the last modification time of a resource.

// Server response header
Last-Modified: Wed, 21 Oct 2023 07:28:00 GMT

// Client request header
If-Modified-Since: Wed, 21 Oct 2023 07:28:00 GMT

The server checks if the resource has changed. If it has, it returns 200 with the new content in the response body, and the browser uses this newly downloaded resource. If there's no change, it returns 304 with an empty response body, and the browser reads directly from cache.

Example:

const data = fs.readFileSync('./01.png');
 const {mtime} =  fs.statSync("./01.png")
 res.setHeader("Last-Modified", mtime.toUTCString())
 res.end(data)

Refresh again:

You can see it's read from disk cache, meaning there's no interaction with the server, equivalent to force cache.

You can see that when using negotiation cache for the second time, the request header includes if-modified-since, which is the value of the previous last-modified. If the server finds that the request header's if-modified-since matches the file's modification time, it tells the browser to use the cache, otherwise use the new file.

  const data = fs.readFileSync('./01.png');
    const { mtime } = fs.statSync("./01.png")
    res.setHeader("Last-Modified", mtime.toUTCString())
    res.setHeader("cache-control", "no-cache")

    const ifModifiedSince = req.headers["if-modified-since"];
    //  Check if browser last-modified equals file modification time
    if (mtime.toUTCString() == ifModifiedSince) {
      res.statusCode = 304;
      res.end()
      return
    }

    res.end(data)

You can see that if the browser's last-modified matches the file's modification time from the last request, it returns 304, otherwise returns 200 with the new resource.

However, if the file modification time is very short but the content has changed, Last-Modified cannot accurately determine if the resource has changed. In this case, we need to use ETag to solve this problem.

2. Content-based Negotiation Cache

ETag is a header in HTTP/1.1 that represents a unique identifier for a resource.

Its main function is to perform hash operations on different resources. As long as files are different, the corresponding hash operation results will be different.

// Server response header
ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

// Client request header
If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

Example:

const etag =  require("etag");
if (pathname == "/02.png") {
    const data = fs.readFileSync('./02.png');
    const etagContent = etag(data);
    res.setHeader("etag", etagContent);
    res.setHeader("cache-control", "no-cache")
    res.end(data)
}

Perform hash operation on the 02.png file. On the first request, the response header includes etag.

On the second request, the request header adds if-none-match.

If the etag matches the file's hash operation result, it returns 304, otherwise returns 200 with the new resource.

   const data = fs.readFileSync('./02.png');
    const etagContent = etag(data);
    const ifNoneMatch = req.headers["if-none-match"];
    if (ifNoneMatch == etagContent) {
      res.statusCode = 304;
      res.end()
      return
    }

Proxy Server Caching

Caches in browsers are user-specific and called private caches, while caches on proxy servers can be accessed by everyone and are called public caches. If you only want the resource cached in the browser and not on the proxy server, set it to private, otherwise set it to public:

For example, this setting allows the resource to be cached on the proxy server for one year (proxy server's max-age is set with s-maxage), and cached in the browser for 10 minutes:

Cache-control:public, max-age=600,s-maxage:31536000

This setting means only the browser can cache:

Cache-control:private, max-age=600

Also, when the cache expires, is it completely unusable? No, actually expired resources can still be used. There are directives for this:

Cache-control: max-stale=600

"Stale" means not fresh. Including max-stale in the request with 600s means if it's expired for 10 minutes, it can still be used, but not longer.

Cache-control: stale-while-revalidate=600

You can also set stale-while-revalidate, which means while the browser negotiation hasn't finished, just use the expired cache first.

Cache-control: stale-if-error=600

Or set stale-if-error, which means if the negotiation fails, use the expired cache first.

So, the expiration time of max-age is not completely mandatory - it can allow using expired resources for a period of time.

Caching Strategy Examples for Different Scenarios

1. HTML File Caching

HTML files usually need to stay up-to-date, so it's recommended to use negotiation cache:

// Node.js server configuration
app.get('/*.html', (req, res) => {
  res.setHeader('Cache-Control', 'no-cache');
  res.setHeader('Last-Modified', new Date().toUTCString());
  // ... return HTML content
});

// Nginx configuration
location ~ \.html$ {
  add_header Cache-Control "no-cache";
  etag on;
  if_modified_since exact;
}

2. Static Resource Caching

2.1 JavaScript Files

// webpack configuration
module.exports = {
  output: {
    filename: '[name].[contenthash].js'  // Generate filename with hash
  }
}

// Node.js server configuration
app.get('/*.js', (req, res) => {
  res.setHeader('Cache-Control', 'public, max-age=31536000');  // Cache for one year
  // ... return JS content
});

2.2 Image Resources

// Node.js server configuration
// Fixed images like logos
app.get('/static/images/logo.png', (req, res) => {
  res.setHeader('Cache-Control', 'public, max-age=31536000');
  // ... return image content
});

// Images that may change, like user avatars
app.get('/avatars/*', (req, res) => {
  res.setHeader('Cache-Control', 'public, max-age=3600'); // Cache for 1 hour
  res.setHeader('ETag', generateETag(imageContent));
  // ... return image content
});

// Images that shouldn't be cached, like captcha images
app.get('/captcha', (req, res) => {
  res.setHeader('Cache-Control', 'no-store');
  // ... return captcha image
});

3. API Interface Caching

3.1 Real-time Data Interfaces

// Real-time data like stock prices
app.get('/api/stock-price', (req, res) => {
  res.setHeader('Cache-Control', 'no-store');
  // ... return real-time data
});

3.2 Short-term Cache Interfaces

// Short-term cached data like product lists
app.get('/api/products', (req, res) => {
  res.setHeader('Cache-Control', 'public, max-age=300'); // Cache for 5 minutes
  // ... return product list
});

4. CDN Cache Configuration

# Nginx CDN node configuration
proxy_cache_path /tmp/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;

server {
    location / {
        proxy_cache my_cache;
        proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
        proxy_cache_valid 200 302 1d;    # Cache successful responses for 1 day
        proxy_cache_valid 404 1m;        # Cache 404 responses for 1 minute
        proxy_cache_key $scheme$proxy_host$request_uri;

        # Add cache status header
        add_header X-Cache-Status $upstream_cache_status;
    }
}

Cache Effect Verification

Chrome Developer Tools Verification

Open Chrome Developer Tools (F12)
Switch to the Network panel
Observe the Size column:
- (memory cache): indicates loading from memory cache
- (disk cache): indicates loading from disk cache
- 304: indicates negotiation cache is active

Caching Strategy Best Practices

HTML Files
- Use negotiation cache
- Ensure content freshness
Static Resources (JS/CSS/Images)
- Use force cache
- Include content hash in filenames
- Set longer expiration times
API Requests
- Generally don't cache
- Can use negotiation cache in special scenarios

Summary

Caching can speed up page loading and reduce server pressure, so HTTP designed a caching mechanism.

In HTTP 1.0, the Expires header was used to control caching, specifying a GMT expiration time. However, this caused problems when browser time was inaccurate.

In HTTP 1.1, it was changed to the max-age method to set expiration time, letting the browser calculate it itself. All cache-related controls were put into the Cache-Control header, with things like max-age called directives.

After cache expiration, HTTP 1.1 also designed a negotiation phase, which sends the resource's Etag and Last-Modified to the server through the If-None-Match and If-Modified-Since headers to ask if it has expired. If expired, it returns 200 with new content, otherwise returns 304, telling the browser to use the cache.

Besides the max-age directive, we also learned these directives:

public: Allow proxy servers to cache resources
s-maxage: Resource expiration time for proxy servers
private: Don't allow proxy servers to cache resources, only browsers can cache
immutable: Even if expired, no negotiation needed, the resource is unchanged
max-stale: Resources can still be used if expired for a period of time
stale-while-revalidate: During validation (negotiation), return expired resources
stale-if-error: If validation (negotiation) fails, return expired resources
must-revalidate: Don't allow using expired resources after expiration, must wait for negotiation to finish
no-store: Prohibit caching and negotiation
no-cache: Allow caching, but must negotiate every time

DEV Community: Ben

React's Render Pipeline: A Deep Dive From JSX to the Screen

1. The Render Pipeline at a Glance 🏭

2. Step One: From JSX to Virtual DOM 📄

2.1 What is the Virtual DOM?

2.2 The JSX Transformation

2.3 Handling Function Components

3. Step Two: Building the Fiber Tree 🌳

3.1 What is Fiber?

3.2 Building the Fiber Tree

3.3 Time Slicing

4. Step Three: Reconciliation and the Diffing Algorithm 🔍

4.2 The Diffing Heuristics

5. Step Four: The Commit Phase 🚀

5.2 Three Types of Commit Operations

6. How Hooks Work 🎣

6.1 useState Under the Hood

6.2 The Rules of Hooks

7. A Full Example: Initial Render vs. Update

7.1 Initial Render

7.2 Update Render

8. Conclusion

ES2025 is Coming! 5 New Features That Will Change How You Write JavaScript

1. Promise.withResolvers() - The New Way to Create Promises

2.Array.prototype.toSpliced() - The Immutable splice()

3. Object.groupBy() and Map.groupBy() - Effortless Data Grouping

4.ArrayBuffer.prototype.transfer() - Zero-Cost Memory Transfer

Conclusion

Browser Caching Explained: From Principles to Practice

What is Browser Caching?

Why Do We Need Browser Caching?

Browser Caching Mechanisms Explained

1. Force Cache

1. Expires (HTTP/1.0)

2. Cache-Control (HTTP/1.1)

2. Negotiation Cache

1. Time-based Negotiation Cache

2. Content-based Negotiation Cache

Proxy Server Caching

Caching Strategy Examples for Different Scenarios

1. HTML File Caching

2. Static Resource Caching

2.1 JavaScript Files

2.2 Image Resources

3. API Interface Caching

3.1 Real-time Data Interfaces

3.2 Short-term Cache Interfaces

4. CDN Cache Configuration

Cache Effect Verification

Chrome Developer Tools Verification

Caching Strategy Best Practices

Summary

References

1. `Promise.withResolvers()` - The New Way to Create Promises