State Management, React Server Actions & Optimization

In the contemporary React and Next.js landscape, state management and data mutation have undergone a profound architectural consolidation. For years, frontend engineering teams built monolithic client-side stores (Redux, MobX) to cache server data, sync form states, and orchestrate network mutations. This resulted in redundant data normalization, complex action creators, and severe bundle bloat.

With the advent of React Server Components (RSC), React Server Actions, and modern micro-state libraries, the industry has separated Server State (data residing in backend datastores) from Client State (ephemeral UI interactions). Server Actions turn asynchronous backend mutations into type-safe, direct Remote Procedure Calls (RPCs), while hooks like useOptimistic and useActionState allow developers to construct lightning-fast interfaces that update optimistically before network round-trips complete.

This guide provides an exhaustive, university-grade architectural analysis of state management, Server Action mechanics, and runtime performance optimization. We dissect Server Action wire protocols, evaluate atomic selector subscription mechanics in Zustand, model optimistic UI rollback dynamics, analyze Cumulative Layout Shift (CLS) optimization with next/image, and solve four comprehensive quantitative checkpoint problems.

1. The Separation of Server State and Client State#

The single most significant breakthrough in modern state architecture is the recognition that Server State and Client State are fundamentally different categories of data:

+-------------------------------------------------------------------------------------------------+
|                                 STATE TAXONOMY & TOPOLOGY                                       |
|                                                                                                 |
|   SERVER STATE (Remote / Shared)                     CLIENT STATE (Local / Transient)           |
|   - Database records, user profiles, orders          - Modal visibility (isOpen: boolean)       |
|   - Asynchronous by nature (requires network fetch)  - Form input draft text                    |
|   - Shared across multiple users                     - UI theme (dark / light mode)             |
|   - Potentially stale; requires cache invalidation   - Selected tab index                       |
|   - Handled by: React Server Components & Actions    - Handled by: useState, Zustand, Jotai     |
+-------------------------------------------------------------------------------------------------+

Why Monolithic Client Stores (Redux) are Obsolete for Server State#

Historically, developers treated Redux as a global database inside the browser. When an application fetched a list of users, it dispatched actions to normalize the data into a Redux slice:

• Architectural Flaw: The client had to manually manage cache invalidation, polling, loading spinners, error states, and optimistic reconciliation.
• Modern Solution: In Next.js, Server Components fetch data directly from databases at the component level. The data never needs to enter a client store. When data changes, Server Actions execute mutations on the server and trigger atomic cache revalidation via revalidatePath() or revalidateTag().

Atomic Micro-State Libraries (Zustand & Jotai)#

For genuine Client State (e.g., audio player playback state, canvas tool selection, notification toasts), modern applications use lightweight atomic stores like Zustand:

import { create } from "zustand";

interface UIState {
  isSidebarOpen: boolean;
  activeTheme: "dark" | "light";
  toggleSidebar: () => void;
}

export const useUIStore = create<UIState>((set) => ({
  isSidebarOpen: false,
  activeTheme: "dark",
  toggleSidebar: () => set((state) => ({ isSidebarOpen: !state.isSidebarOpen })),
}));

Selector-Based Subscription Optimization#

In standard React Context, when any property inside the context object changes, every component consuming the context re-renders, even if it only accesses an unchanged property.

Zustand eliminates this performance bottleneck through atomic selector subscriptions:

// Only re-renders when isSidebarOpen changes! Ignores activeTheme updates completely!
const isSidebarOpen = useUIStore((state) => state.isSidebarOpen);

Internally, Zustand uses useSyncExternalStore (introduced in React 18) to subscribe directly to a vanilla JavaScript closure. It performs strict equality checks (Object.is) on the returned selector value, bypassing React Fiber reconciliation completely if the selected value has not changed.

2. React Server Actions & Remote Procedure Calls (RPC)#

React Server Actions are asynchronous functions declared with the "use server" directive that execute exclusively on the server, but can be invoked directly from Client Components or HTML forms.

+-------------------------------------------------------------------------------------------------+
|                                 REACT SERVER ACTION RPC WIRE FLOW                               |
|                                                                                                 |
|   Client Component: <button onClick={() => updateAccount(42, "Enterprise")}>                   |
|                                 |                                                               |
|                                 v (Automatic Next.js RPC Client)                                |
|   HTTP Request:                                                                                 |
|   POST /dashboard HTTP/1.1                                                                      |
|   Content-Type: multipart/form-data or application/json                                         |
|   Next-Action: 8f4a2b91c... (Cryptographic Action ID Hash)                                      |
|   Body: [42, "Enterprise"]                                                                      |
|                                 |                                                               |
|                                 v                                                               |
|   Next.js Origin Server:                                                                        |
|   1. Matches Action ID hash to internal compiled function.                                      |
|   2. Deserializes arguments and executes database mutation.                                     |
|   3. Calls revalidatePath('/dashboard') to purge cache.                                         |
|   4. Returns updated React Flight Protocol stream in the HTTP response!                         |
|                                 |                                                               |
|                                 v                                                               |
|   Client Runtime:                                                                               |
|   Directly merges new Flight stream into UI! Zero manual refetching required!                   |
+-------------------------------------------------------------------------------------------------+

Progressive Enhancement & Zero-JS Form Submission#

A transformative capability of Server Actions is Progressive Enhancement:

When passed to the action attribute of an HTML <form>, the form works even if JavaScript is disabled or still downloading:

// app/actions/auth.ts
"use server";
import { redirect } from "next/navigation";

export async function loginAction(formData: FormData) {
  const email = formData.get("email");
  const password = formData.get("password");
  // Authenticate against database
  redirect("/dashboard");
}

// app/login/page.tsx (Works with ZERO JavaScript!)
import { loginAction } from "@/app/actions/auth";

export default function LoginPage() {
  return (
    <form action={loginAction}>
      <input type="email" name="email" required />
      <input type="password" name="password" required />
      <button type="submit">Sign In</button>
    </form>
  );
}

• Without JavaScript: The browser dispatches a standard HTTP POST form submission. The server processes the mutation and issues an HTTP 303 Redirect.
• With JavaScript: Next.js intercepts the form submission, dispatches an asynchronous fetch() POST request in the background, updates pending state hooks, and transitions smoothly without a browser page reload.

Optimistic UI Updates with `useOptimistic`#

In interactive applications, waiting 200 to 500 milliseconds for a server mutation to complete before updating the UI feels sluggish. useOptimistic allows the UI to update immediately with the expected result, automatically rolling back if the server action fails:

"use client";
import { useOptimistic } from "react";
import { toggleLikeAction } from "@/app/actions/posts";

export function LikeButton({ postId, initialLikes }: { postId: string; initialLikes: number }) {
  const [optimisticLikes, setOptimisticLikes] = useOptimistic(
    initialLikes,
    (currentLikes, update: number) => currentLikes + update
  );

  async function handleLike() {
    // 1. Instantly updates UI to currentLikes + 1 before network request is sent!
    setOptimisticLikes(1);
    try {
      // 2. Dispatches server action RPC
      await toggleLikeAction(postId);
    } catch (err) {
      // 3. If server fails, useOptimistic automatically reverts to initialLikes!
    }
  }

  return <button onClick={handleLike}>Likes: {optimisticLikes}</button>;
}

3. High-Performance Optimization Protocols#

High-velocity Next.js applications achieve sub-second page loads and perfect Google Lighthouse scores by applying targeted optimization techniques.

Core Web Vitals Optimization with `next/image`#

The native HTML <img> tag is the primary driver of poor Largest Contentful Paint (LCP) and high Cumulative Layout Shift (CLS) on the modern web:

• Loading uncompressed 4 MB JPEG images wastes mobile bandwidth.
• Loading images without predefined aspect ratio dimensions causes the layout to jump abruptly when images load, triggering severe CLS penalties.

next/image provides an automated performance pipeline:

1. Zero Layout Shift: Requires explicit width and height (or fill), automatically reserving aspect ratio space in CSS prior to download.
2. Modern Compression: Transcodes source images on-the-fly to modern AVIF and WebP formats, achieving 50% to 70% file size reductions.
3. Responsive `srcset` Generation: Automatically generates a responsive image matrix for various screen widths (mobile, tablet, desktop).
4. Blur-up Placeholders: Generates a low-resolution base64 inline placeholder image for instantaneous visual feedback while high-resolution assets stream in.

Font Optimization with `next/font`#

External font loading (e.g., standard Google Fonts via <link> tags) introduces render-blocking network requests and causes Flash of Invisible Text (FOIT) or Flash of Unstyled Text (FOUT).

next/font solves this completely:

• Automatically downloads font files at build time and self-hosts them locally with your static assets.
• Automatically injects CSS size-adjust rules that match the exact fallback font metrics (e.g., Arial), eliminating layout shifts when custom fonts finish loading.
• Zero external network requests to Google servers at runtime, guaranteeing 100% GDPR compliance and edge caching.

4. Production Engineering Case Study: High-Concurrency Stock Trading Order Form#

Consider a high-frequency equity trading portal. Users execute market buy orders with instantaneous visual feedback while ensuring transactional integrity on the server.

+-------------------------------------------------------------------------------------------------+
|                                 OPTIMISTIC TRADING MUTATION PIPELINE                            |
|                                                                                                 |
|   [User Clicks "Buy 100 AAPL"]                                                                  |
|                 |                                                                               |
|                 v                                                                               |
|   1. useOptimistic triggers instantly:                                                          |
|      - Portfolio Cash: USD 10,000  -->  USD 8,500  (Deducted in 0 ms)                            |
|      - Shares Owned:   0           -->  100        (Appears in UI table in 0 ms)                |
|                 |                                                                               |
|                 v                                                                               |
|   2. Server Action Dispatched: executeMarketOrder("AAPL", 100)                                  |
|      - Encrypted RPC call via Next-Action header                                                |
|      - Verifies JWT authentication token                                                        |
|      - Executes ACID SQL transaction on PostgreSQL cluster                                       |
|                 |                                                                               |
|                 v                                                                               |
|   Did Database Transaction Succeed?                                                             |
|         /                  \                                                                    |
|       YES                  NO                                                                   |
|       /                      \                                                                  |
|   [revalidatePath('/trade')]  [Throw ServerActionError]                                         |
|   [Confirm New Balance]       [useOptimistic automatically rolls balance back to USD 10,000!]   |
|                               [Display Toast: Order Rejected by Settlement Engine]              |
+-------------------------------------------------------------------------------------------------+

Production Implementation#

// app/actions/trading.ts
"use server";
import { db } from "@/lib/db";
import { revalidatePath } from "next/cache";

export async function executeMarketOrder(symbol: string, quantity: number, price: number) {
  const session = await getSession();
  if (!session) throw new Error("Unauthorized");

  const cost = quantity * price;

  // Execute atomic transactional mutation
  await db.transaction(async (tx) => {
    const account = await tx.account.findUnique({ where: { userId: session.userId } });
    if (account.cashBalance < cost) {
      throw new Error("Insufficient funds for purchase");
    }
    await tx.account.update({
      where: { userId: session.userId },
      data: { cashBalance: { decrement: cost } }
    });
    await tx.position.upsert({
      where: { userId_symbol: { userId: session.userId, symbol } },
      update: { shares: { increment: quantity } },
      create: { userId: session.userId, symbol, shares: quantity }
    });
  });

  revalidatePath("/trading");
  return { success: true };
}

5. Anti-Patterns & Common Pitfalls#

Premature Memoization with `useCallback` and `useMemo`#

Developers often wrap every single function declaration in useCallback and every object in useMemo:

// ANTI-PATTERN: Wasteful Memoization
const add = useCallback((a, b) => a + b, []); // MEMORY OVERHEAD EXCEEDS COMPUTATION COST!

Every invocation of useCallback allocates an array for dependencies and an internal hook linked-list node. For simple arithmetic or functions passed to standard HTML tags (<button onClick={...}>), memoization introduces a net memory and CPU penalty.

Remediation: Reserve useCallback strictly for functions passed as props to components wrapped in React.memo or used as dependencies in useEffect.

Unauthenticated Server Actions (The Hidden Endpoint Trap)#

Because Server Actions look like regular TypeScript functions, developers frequently forget that every Server Action is a publicly accessible HTTP POST endpoint:

// CATASTROPHIC SECURITY FLAW
"use server";
export async function deleteUserAccount(targetUserId: string) {
  // Missing authentication check! Anyone who discovers the Action ID can delete ANY user!
  await db.users.delete({ where: { id: targetUserId } });
}

Remediation: Always authenticate and authorize the user inside the Server Action body before mutating state.

6. Checkpoint Practice Problems#

The following four multi-part quantitative problems evaluate Server Action RPC execution mechanics, optimistic UI rollback modeling, Zustand selector subscription performance, and Core Web Vitals image optimization mathematics. Complete step-by-step solutions follow each problem prompt.

Problem 1: Server Action RPC Execution Trace & Progressive Enhancement Mechanics#

Context:

A user submits an account profile update on a Next.js 15 application:

// app/actions/user.ts
"use server";
export async function updateUsername(formData: FormData) {
  const newName = formData.get("username") as string;
  if (!newName || newName.length < 3) {
    return { error: "Name must be at least 3 characters" };
  }
  await db.user.update({ where: { id: 1 }, data: { name: newName } });
  revalidatePath("/profile");
  return { success: true };
}

The user submits "Kamran" into the form.

Questions:

1. Detail the exact HTTP request generated when the form is submitted with JavaScript disabled in the browser.
2. Detail the exact HTTP request generated when the form is submitted with JavaScript enabled.
3. What is the value of the Next-Action HTTP request header, and how does the Next.js runtime map this header to the underlying server action code?
4. Explain how Next.js synchronizes the client UI after revalidatePath("/profile") executes on the server.

Solution:

Step 1: HTTP Request With JavaScript Disabled

When JavaScript is disabled, the browser relies on native HTML form submission:

POST /profile HTTP/1.1
Host: devthesis.com
Content-Type: application/x-www-form-urlencoded

username=Kamran&ACTION_ID_8f4a2b91c=

• The browser triggers a full-page navigation.
• Next.js detects the hidden input field ACTION_ID_... injected during server pre-rendering.
• The server processes the mutation, executes revalidatePath, and responds with an HTTP 303 See Other redirect back to /profile.
• The browser reloads the page, rendering the fresh database state with zero client JS required.

Step 2: HTTP Request With JavaScript Enabled

When JavaScript is enabled, Next.js's runtime intercepts the submit event:

POST /profile HTTP/1.1
Host: devthesis.com
Accept: text/x-component
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryXYZ
Next-Action: 8f4a2b91c7d23e5a1b0284f

------WebKitFormBoundaryXYZ
Content-Disposition: form-data; name="username"

Kamran
------WebKitFormBoundaryXYZ--

• Dispatched via an asynchronous fetch() call.
• The browser URL does not reload.

Step 3: Role of the `Next-Action` Header

Next-Action: 8f4a2b91c... contains an immutable cryptographic hash ID generated during the Next.js build compilation step.

• The Next.js production server maintains an internal action manifest (server-reference-manifest.json) mapping each hash ID to the specific exported function in the server bundle.
• The runtime verifies the hash, instantiates the FormData object, and invokes updateUsername(formData).

Step 4: UI Synchronization via Flight Protocol

Because revalidatePath("/profile") was called inside the action:

1. The server re-renders the /profile Server Component tree in memory.
2. Instead of returning plain JSON, the server streams the updated React Flight Protocol representation directly in the HTTP POST response body.
3. The client-side React reconciler merges the Flight stream into the existing DOM without destroying client state or unmounting surrounding layouts.

Problem 2: Optimistic UI Rollback Mathematics & Latency Perceived Modeling#

Context:

A collaborative social coding platform features an upvote button for code snippets. The team uses useOptimistic to maximize user perceived responsiveness.

Operational Parameters:

• Baseline upvote count: C_0 = 42.
• Network Round-Trip Latency: RTT = 280 ms.
• Server database processing latency: T_{db} = 40 ms.
• Total round-trip mutation duration: T_{mutation} = RTT + T_{db} = 320 ms.
• Server Failure Probability: The backend settlement engine rejects 10% of mutations (p_{fail} = 0.10) due to rate-limiting constraints.

Questions:

1. Calculate the user-perceived response latency (the elapsed time between the user clicking "Upvote" and the button visually incrementing from 42 to 43) under a traditional non-optimistic implementation vs. the useOptimistic implementation.
2. In the 90% of cases where the server mutation succeeds, describe the visual transition observed by the user.
3. In the 10% of cases where the server action throws a RateLimitError at t = 320 ms, describe the exact state rollback mechanism executed by React.
4. Calculate the average user-perceived responsiveness speedup factor delivered by useOptimistic.

Solution:

Step 1: Perceived Response Latency Comparison

• Traditional Non-Optimistic Implementation:

The UI does not update until the network request completes and the server confirms:

Latency_{traditional} = T_{mutation} = 320.0 ms.

• `useOptimistic` Implementation:

The setOptimistic dispatch function executes synchronously in the client event loop tick:

Latency_{optimistic} = ≤ 1.0 ms (Instantaneous!).

Step 2: Visual Transition on Successful Mutation (90% of cases)

• At t = 0 ms: User clicks. useOptimistic immediately displays 43.
• At t = 320 ms: Server action returns { success: true, count: 43 }.
• React updates the underlying base state from 42 to 43.
• Because the optimistic value (43) matches the new base state (43), zero visual flicker or layout jump occurs. The transition is perfectly seamless.

Step 3: Rollback Mechanism on Server Failure (10% of cases)

• At t = 0 ms: User clicks. UI displays 43.
• At t = 320 ms: Server throws RateLimitError.
• The catch block in the client handler captures the error.
• Because the pending Server Action Promise was rejected, React discards the optimistic delta.
• React automatically reverts the displayed value from `43` back to the original base state `42`.
• An error toast alert is displayed: "Rate limit exceeded. Vote not recorded."

Step 4: Average Perceived Speedup Factor

Speedup = Latency_{traditional} / Latency_{optimistic}

Speedup = 320.0 / 1.0 = 320x faster perceived user responsiveness.

Problem 3: Client State Management Selector Subscription & Re-render Efficiency#

Context:

A high-frequency trading platform renders a watchlist table containing N = 500 financial asset rows.

The engineering team compares two global client state management architectures:

• Architecture A (React Context): A single monolithic WatchlistContext.Provider wrapping the table, supplying a state dictionary of all 500 quotes: { [symbol]: quoteData }.
• Architecture B (Zustand with Atomic Selectors): An external Zustand store where each individual WatchlistRow subscribes strictly to its own symbol:

const quote = useWatchlistStore(state => state.quotes[symbol]);.

Workload Parameters:

• Inbound WebSocket ticker stream pushes an update for a single asset ("NVDA") every 10 milliseconds (100 updates per second).
• Re-rendering a single WatchlistRow Fiber node in the DOM requires τ_{row} = 0.08 ms of JavaScript computation.

Questions:

1. When a single update for "NVDA" arrives, calculate how many WatchlistRow component instances re-render under Architecture A (React Context).
2. Calculate how many instances re-render under Architecture B (Zustand).
3. Compute the total CPU time consumed per second by rendering in both architectures under the 100 updates/second stream.
4. Calculate the main-thread CPU load percentage for both architectures, assuming an available single-thread CPU budget of 1,000 ms per second. Conclude which architecture causes UI freezing.

Solution:

Step 1: Component Re-render Counts Under Architecture A (React Context)

In React Context, any mutation to the context value object triggers a re-render of every consumer component:

• Total rows re-rendered per update = 500 rows.
• Even though 499 rows experienced zero price change, they are forced to re-evaluate their component bodies.

Step 2: Component Re-render Counts Under Architecture B (Zustand)

Zustand's selector executes Object.is(prevQuote, newQuote) for each subscriber:

• For the 499 unchanged symbols: Selector returns the identical object reference. Re-render is bypassed completely (0 re-renders).
• For "NVDA": Reference changed.
• Total rows re-rendered per update = exactly 1 row.

Step 3: Total CPU Time Consumed per Second

Workload = 100 updates per second. Time per row τ_{row} = 0.08 ms.

• Architecture A (React Context):

CPU time per update = 500 rows × 0.08 ms = 40.0 ms.

CPU time per second = 100 updates/sec × 40.0 ms = 4,000.0 ms of CPU work per second!

• Architecture B (Zustand):

CPU time per update = 1 row × 0.08 ms = 0.08 ms.

Selector equality checks for 499 rows = 499 × 0.001 ms ≈ 0.50 ms.

Total per update = 0.08 + 0.50 = 0.58 ms.

CPU time per second = 100 updates/sec × 0.58 ms = 58.0 ms of CPU work per second.

Step 4: Main-Thread CPU Load & UI Responsiveness Assessment

Available time budget per second = 1,000.0 ms.

• Architecture A CPU Load:

Load = (4,000.0 / 1,000.0) × 100% = 400% CPU Load.

Result: The main thread is catastrophically overloaded by 4x. The browser completely freezes, drops 100% of animation frames, and displays an "Unresponsive Page" crash dialog.

• Architecture B CPU Load:

Load = (58.0 / 1,000.0) × 100% = 5.8% CPU Load.

Result: Consumes less than 6% of the CPU budget. The application runs smoothly at a locked 60 FPS, maintaining full interactivity.

Problem 4: Core Web Vitals Image Optimization & Cumulative Layout Shift (CLS) Modeling#

Context:

An e-commerce homepage features a large promotional hero banner image. The page is audited on Google Lighthouse under two image implementations:

• Implementation 1 (Native Unoptimized Image):

<img src="/hero.jpg" alt="Summer Sale" />

- Source image file format: Baseline JPEG. File size: S_1 = 2.4 MB = 2,457.6 KB.

- The image lacks explicit width or height attributes.

- Browser displays an empty 0-pixel height container until the image loads. Upon image download, the image expands to a height of 500 pixels, pushing down a text content block that occupies 60% of the mobile viewport.

• Implementation 2 (Next.js Optimized Image):

<Image src="/hero.jpg" alt="Summer Sale" width={1200} height={500} priority placeholder="blur" />

- Next.js automatically transcodes the image to AVIF format. File size: S_2 = 180 KB.

- Explicit aspect ratio (1200 / 500 = 2.4) reserves the exact 500 px height in the layout skeleton before download.

Network Connection: Mobile 4G (B = 2 MB/sec = 2,048 KB/sec).

Cumulative Layout Shift (CLS) Formula:

CLS = Impact Fraction × Distance Fraction

• Impact Fraction: The fraction of the viewport shifted by the unstable element.
• Distance Fraction: The vertical distance the unstable elements moved relative to the viewport height.
• In Implementation 1: The text content block shifts down by 40% of the viewport height (Distance Fraction = 0.40). The total viewport area affected by the shift is 75% of the screen (Impact Fraction = 0.75).

Questions:

1. Calculate the download time for the hero image under Implementation 1 vs. Implementation 2.
2. Calculate the Cumulative Layout Shift (CLS) score for Implementation 1 and assess whether it complies with Google's Core Web Vitals target (CLS ≤ 0.10).
3. Calculate the CLS score for Implementation 2.
4. Calculate the total bandwidth saved and the percentage reduction in mobile data transfer.

Solution:

Step 1: Download Time Comparison

Bandwidth B = 2,048 KB/sec.

• Implementation 1 (Native JPEG):

Download Time = 2,457.6 KB / 2,048 KB/s = 1.200 seconds (1,200 ms).

The hero image blocks Largest Contentful Paint for over 1.2 seconds.

• Implementation 2 (`next/image` AVIF):

Download Time = 180 KB / 2,048 KB/s = 0.0879 seconds (87.9 ms).

Downloaded 13.6x faster!

Step 2: CLS Score Calculation for Implementation 1

Impact Fraction = 0.75.

Distance Fraction = 0.40.

CLS_1 = Impact Fraction × Distance Fraction

CLS_1 = 0.75 × 0.40 = 0.300.

Assessment: Google Core Web Vitals threshold for "Good" is CLS ≤ 0.10. A score of 0.300 is classified as POOR (Failing), directly penalizing SEO ranking and organic search visibility.

Step 3: CLS Score Calculation for Implementation 2

In Implementation 2, width={1200} and height={500} instructs the browser to reserve the exact aspect ratio box immediately in the initial CSS layout pass.

When the AVIF image arrives 88 ms later, it fills the pre-allocated container.

The surrounding text elements move by exactly 0 pixels (Distance Fraction = 0.0).

CLS_2 = Impact Fraction × 0.0 = 0.000 (Perfect Zero Layout Shift!).

Assessment: Complies 100% with Google's "Good" Core Web Vitals threshold.

Step 4: Bandwidth Reduction

• Original payload: 2,457.6 KB.
• Optimized payload: 180.0 KB.
• Bandwidth saved per visitor = 2,457.6 - 180.0 = 2,277.6 KB (2.28 MB saved per page view).
• Percentage reduction = (2,277.6 / 2,457.6) × 100% ≈ 92.68% mobile bandwidth reduction.