Staff Frontend Developer Interview Preparation Guide - FAANG Standards

Overview
Explain approach, create a single global store using Context + useReducer, expose Provider and a dispatch hook, then show how to dispatch from children. Finally list strategies to avoid unnecessary re-renders.

Provider & store

import React, { createContext, useReducer, useContext } from 'react';

const initialState = { user: null, theme: 'light', cart: [] };

function reducer(state, action) {
  switch(action.type) {
    case 'SET_USER': return { ...state, user: action.payload };
    case 'TOGGLE_THEME': return { ...state, theme: state.theme === 'light' ? 'dark' : 'light' };
    case 'ADD_ITEM': return { ...state, cart: [...state.cart, action.payload] };
    default: return state;
  }
}

const StoreContext = createContext();

export function StoreProvider({ children }) {
  const [state, dispatch] = useReducer(reducer, initialState);
  return (
    <StoreContext.Provider value={{ state, dispatch }}>
      {children}
    </StoreContext.Provider>
  );
}

export const useStore = () => useContext(StoreContext);

Dispatching from a child

import React from 'react';
import { useStore } from './store';

function AddToCartButton({ item }) {
  const { dispatch } = useStore();
  return <button onClick={() => dispatch({ type: 'ADD_ITEM', payload: item })}>Add</button>;
}

Avoiding unnecessary re-renders

• Split contexts: create separate contexts for frequently-updated slices (e.g., CartContext, ThemeContext) so components only subscribe to needed slice.
• Selectors + custom hooks: expose hooks like useUser(), useCart() that return selected slice; inside provider memoize derived selectors.
• Memoization: useMemo/useCallback for selector results and action creators; wrap components in React.memo.
• Immutable updates: ensure reducer returns new objects only for changed slices to let shallow compares skip re-renders.
• Example: keep Provider value stable by memoizing:

const contextValue = React.useMemo(() => ({ state, dispatch }), [state, dispatch]);

These patterns keep global state manageable while minimizing render churn.

Direct answer

A production token schema needs four things per token: a stable machine ID, a category discriminator (color, typography, spacing, elevation...), the value scoped by theme, and a platforms block the build pipeline reads to emit a native identifier for web, iOS, and Android without a hand-maintained per-platform lookup table.

Structured elaboration

Theming: put theme variants directly on the token as a themes map (one file tells you everything about that token) rather than separate light.json/dark.json files that have to stay in lock-step. Require every themed token to declare both light and dark explicitly, and fail the build if one is missing, rather than silently falling back.

Platform identifiers: derive names deterministically from id by default, dots to hyphens for the CSS custom property, dots to PascalCase for the iOS name, dots to snake_case for the Android resource name, and let platforms carry an explicit override only for the exceptions (reserved words, legacy names still referenced by existing native code).

Composite and alias tokens: typography tokens are compound values (family, weight, size, line height, letter spacing). A token's value can also be a reference string, e.g. "{color.primary.500}", so a derived token (a focus ring, a hover state) can point at an existing color token instead of duplicating its hex value.

Worked example

Color token:

{
  "id": "color.primary.500",
  "category": "color",
  "description": "Primary brand color for primary actions and focus accents",
  "themes": {
    "light": { "value": "#0B61FF" },
    "dark": { "value": "#7FB1FF" }
  },
  "platforms": {
    "web": { "name": "--color-primary-500" },
    "ios": { "name": "colorPrimary500" },
    "android": { "name": "color_primary_500" }
  }
}

Typography token:

{
  "id": "type.heading.h1",
  "category": "typography",
  "description": "Page-level H1 heading style",
  "value": {
    "fontFamily": "Inter",
    "fontWeight": 700,
    "fontSize": 32,
    "lineHeight": 40,
    "letterSpacing": 0,
    "unit": "px"
  },
  "platforms": {
    "web": { "name": "--type-heading-h1" },
    "ios": { "name": "typeHeadingH1" },
    "android": { "name": "TextAppearance_HeadingH1" }
  }
}

Trade-offs and pitfalls

Naming collision is the most common real-world failure: reusing one literal name for all three platforms breaks the moment naming rules diverge. CSS custom properties allow hyphens (--color-primary-500); Android resource names cannot contain hyphens and must be snake_case (color_primary_500); Swift and Kotlin constants are usually camelCase (colorPrimary500). Keep id platform-neutral and let the transform layer produce each platform's spelling, rather than letting one platform's convention leak into the schema.

Missing theme variant: decide up front what happens to a token with no dark override. A silent fallback to the light value hides real bugs (someone forgot to define dark for a rarely touched token); a build error surfaces it immediately.

Aliasing depth: allow token references, but cap resolution depth (two levels is usually enough) so the build pipeline never has to resolve an arbitrarily long chain, and a broken alias fails the build with a clear "unresolved reference" error instead of quietly emitting undefined into generated CSS.

Direct answer. A Progressive Web App (PWA) that works offline needs its cached content to preserve full semantic structure and an alternate UI state clearly communicating offline status, since a screen reader user relies entirely on the DOM/accessibility tree to know what's happening, and a silently-failed network request with no accessible offline-state communication leaves them with no way to understand why content isn't updating.

Ensuring semantic content and alternate UI are available from cache. Cache the actual rendered HTML (or enough app-shell structure to render meaningful semantic content client-side) rather than only caching raw JSON data that requires a successful script execution to become visible content, since a cache strategy that only stores data, not renderable structure, produces a blank or broken screen if the rendering script itself fails to run correctly offline.

Preserving focus and navigation across offline transitions. When the app detects a network-loss event and switches to an offline UI state (a banner, a disabled-action indicator), announce that transition via a live region ("You're offline. Some features are unavailable.") rather than relying on a purely visual indicator, and avoid silently moving focus away from what the user was doing; when connectivity returns, announce that transition too, and avoid auto-refreshing content in a way that would unexpectedly move focus or lose in-progress user input.

Communicating what's available offline versus not. Interactive elements that require connectivity (a submit button for an action that needs a live network call) should communicate their disabled/unavailable state accessibly (aria-disabled plus a description via aria-describedby explaining why, "unavailable offline") rather than silently failing or appearing clickable but doing nothing when tapped, which is confusing for any user but especially unhelpful for a screen reader user who gets no error feedback beyond an unexplained lack of response.

Service worker cache strategies relevant to accessibility. Use a cache-first (or stale-while-revalidate) strategy specifically for the app-shell HTML and any assistive-technology-relevant static structure (navigation, headings, landmarks), since this needs to be available instantly and reliably offline without waiting on a network request that will fail; use a network-first strategy, falling back to cache, for frequently-changing content where staleness itself needs to be communicated, so a screen reader user isn't silently shown outdated data as if it were current, consistent with the offline-transition announcement described above. Avoid a strategy that leaves the accessibility-tree-relevant shell uncached while only caching data, since that reproduces the exact raw-JSON-only failure mode already named as the core anti-pattern to avoid.

Testing assistive technologies in offline mode specifically. Test with a real screen reader by physically toggling airplane mode or fully disabling the radio mid-session, not only via DevTools' network throttling, which can behave differently from an actual offline device state; confirm the offline-transition live-region announcement described above is genuinely read by VoiceOver, TalkBack, or NVDA when the network actually drops, and confirm the disabled-state announcements on network-dependent controls are accurate, since a control that's visually disabled but not correctly exposed to the accessibility tree will pass a sighted offline-mode test while still failing a screen reader user.

Trade-offs and pitfalls. A common real gap is building a visually polished offline-state UI (a nice illustration, a friendly "you're offline" message) that's entirely presented as a static visual element with no live-region announcement and no connection to the interactive elements' actual disabled state, meaning a screen reader user tabbing through the page has no way to discover the offline banner exists at all unless they happen to navigate directly to it.

Direct answer

Without formal authority, the entire weight of the decision has to be carried by evidence and process rather than by position: a written proposal, a small prototype that answers the riskiest question first, and an explicit invitation for dissent before you ask anyone to commit. With formal authority you can still do all of that, but you can also make the call and move on if consensus does not converge; without it, converging the room IS the job, and skipping that step means the decision does not stick even if you turn out to be right.

Structured elaboration

The mechanical difference: when you have authority, disagreement can end in "I've decided, let's go" and the team executes because reporting-line accountability backs the call. When you don't, that same sentence has no force. So the practical changes are:

• You over-invest in a written proposal before ever proposing a solution out loud, stating the problem, the options actually considered, and the criteria for choosing between them. A short document lets people react to the reasoning instead of to you personally, and it is reviewable asynchronously by people you have not met yet.
• You lead with a prototype or spike that retires the riskiest unknown, not the whole system. The goal is a concrete artifact stakeholders can react to instead of an abstract argument, because a working example is much harder to dismiss than an opinion.
• You actively route around the accountability gap by getting a genuine owner (your manager, the team lead whose system it affects) to co-sign the recommendation early, before it is finalized, so the decision has a place to live once you move to the next thing.
• You spend more time on the people whose sign-off you need but who have no obligation to give it to you specifically: you ask what would change their mind, and you build that evidence rather than restating your case louder.
• You cannot force a schedule. With authority you can set a decision deadline; without it you have to make the cost of delay visible (a concrete list of what stays blocked) and let that pressure do the work instead of a mandate.

This same shift shows up whenever the scope of what you're deciding outruns your formal standing: influencing a peer-to-peer technical decision without formal authority, influencing architecture or policy decisions beyond your immediate team, leading a multi-team initiative (for example, one aimed at a large inference-latency cut) with no direct reports on it, leading a cross-team machine learning initiative with no direct reports, or influencing an architectural decision in a technology area outside your own deep expertise, where you additionally have to earn credibility on the subject matter itself before anyone weighs your recommendation at all.

Worked example

I was the senior engineer on a customer-support assistant project with no direct reports on it. Research wanted to fine-tune a proprietary model on internal tickets; product wanted the fastest path to a demo; legal needed data minimization and an audit trail. I had a technical opinion (retrieval over a frozen model, rather than fine-tuning, given our data volume and the audit requirement) but no authority to just pick it.

What changed compared to a project where I had formal ownership: instead of assigning the decision, I wrote a one-page comparison of the three real options (fine-tune, retrieval-augmented generation, hosted model with prompting) against the criteria the stakeholders themselves had named (latency budget, an explicit PII-handling requirement, and cost), and I built a small retrieval prototype against a sample of real tickets before asking anyone to agree to anything. The prototype answered the one question people actually disagreed about, whether retrieval could hit acceptable relevance without fine-tuning, and let legal see concretely how redaction and provenance logging would work rather than trusting a description of it. I did not have the standing to just tell research to stop pursuing fine-tuning; instead I proposed it as a phase-two option contingent on the prototype's results, which gave them a reason to agree rather than a reason to be overruled.

Where this differed from a project I did directly own: on an earlier project where I had explicit technical ownership, I skipped the written comparison document entirely and just built the thing, because the team executed on my say-so. Here, skipping that document would have meant three stakeholders continuing to argue past each other indefinitely; the document was not a nice-to-have, it was the actual mechanism that produced a decision.

Trade-offs and pitfalls

• Over-investing in process when you actually do have enough informal trust wastes time; read the room for whether people are truly undecided or just want you to make the call.
• A prototype aimed at the wrong risk (polishing the demo instead of proving the contested assumption) burns the one shot you get at a stakeholder's attention.
• Getting a co-signer too late, after the recommendation is already public, reads as seeking cover rather than building shared ownership; involve them while the document is still a draft.
• The biggest failure mode without authority is silent non-adoption: everyone nods in the room and nothing changes afterward. Treat agreement in the meeting as provisional until you see the decision actually acted on.

Direct answer
A good 30-60-90 plan moves someone from learning the environment, to contributing under supervision, to owning outcomes independently, with the phase boundaries defined by demonstrated behavior (what they can do unsupervised) rather than by the calendar alone. Track it with a small number of concrete, visible outputs per phase so "on track" is something you can point to, not just a feeling.

The three phases, by what changes

• Days 1-30 (learn and observe): environment setup, codebase or domain orientation, shadowing, and one small real contribution rather than a toy task, so the first change is real but low-risk.
• Days 31-60 (contribute under guidance): own a medium-sized piece of work end to end with a mentor available for review and unblocking, not doing it alongside them line by line.
• Days 61-90 (own outcomes): lead something (a project, an on-call rotation, a smaller onboarding task for the next hire) with the mentor as a backstop, not a co-pilot.

How you know they're on track

• Define the signal per phase in advance, not retroactively: for phase 1, did they reproduce the environment and ship one small real change without major help; for phase 2, is their review feedback shrinking in volume and severity over successive changes; for phase 3, can they make a reasonable decision alone and only escalate the genuinely hard calls.
• Check in on cadence (weekly early on, less frequent later) rather than waiting for day 30, 60, or 90 to find out something drifted three weeks ago.

Adjusting the plan for real constraints

• Limited training resources: when there's no dedicated ramp-up bandwidth (no spare mentor hours, no formal training material), lean harder on asynchronous artifacts: written runbooks, recorded walkthroughs, a curated list of the most representative recent changes, and a lighter-touch weekly sync instead of daily pairing. The phases stay the same; what changes is how much is self-serve versus live.
• Cross-skill ramp: if someone hired primarily for one skill set is expected to also ship in an adjacent one by day 90 (for example, a backend-focused hire expected to ship frontend work), that adjacent skill needs its own explicit milestone inside the plan, not an assumption it'll happen by osmosis. Concretely: days 1-30 stays focused on their strong area to build early confidence and trust; days 31-60 introduces the adjacent skill on a small, well-scoped, low-risk piece with close review; days 61-90 has them own something end to end in the new area, even if smaller in scope than their core-skill ownership.

Worked example
For a new hire joining an established codebase with a small team and no dedicated onboarding budget (the limited-resources case), the 30-60-90 looked like: days 1-30, self-serve environment setup using a written runbook plus a single half-day pairing session, culminating in one small, real bug fix; days 31-60, ownership of one medium feature with async review as the main touchpoint, and a short weekly 15-minute sync instead of daily check-ins; days 61-90, the new hire wrote the onboarding runbook update for the next person, which served double duty as both a real deliverable and a check on whether they actually understood the system well enough to explain it. Being on track was tracked by a short checklist per phase (environment reproducible, first fix merged with normal review effort, feature shipped with review comments trending down) rather than a single blanket "how's it going" check-in.

Trade-offs and pitfalls

• Treating the day boundaries as fixed calendar dates rather than behavioral milestones creates false confidence; someone can hit day 60 without actually being ready for phase-3 ownership, and pushing them into it anyway sets them up to fail.
• Under-supporting the adjacent-skill ramp (assuming a backend engineer will "pick up" frontend without an explicit milestone) is a common way cross-skill onboarding quietly fails; it needs the same structure as the primary skill, just smaller in scope.
• Compressing the plan under limited training resources by cutting phase 1 short (rushing into real ownership before the environment and codebase are understood) trades a faster-looking ramp for more review overhead and rework later.

Direct answer

Start private, and address the impact of the behavior rather than the person's character. Only introduce a visible, group-level norm if the private conversation doesn't hold, and only escalate further if the pattern continues after that.

The move: graduated response, impact before intent

1. Private conversation first, soon after a recent instance. Waiting until frustration has built up makes the conversation land as an accumulated grievance rather than specific, addressable feedback.
2. Describe the observed behavior and its concrete effect, not a character judgment. "In the last two design reviews, an idea got dropped because it was talked over before it was finished" is addressable; "you're dominating meetings" is not.
3. Ask an open question rather than assuming intent. They may not be aware, or something specific (time pressure, a cultural norm from a prior team) may be driving it.
4. Agree on a visible cue or norm together, rather than telling them what to do. A shared agreement they helped design is one they'll actually hold themselves to.
5. If it continues, make the norm visible to the whole group without naming the individual (a "parking lot", a visible running list where off-track or repeated points get noted and revisited later instead of argued in the moment; or a rotating facilitator), and only return to a private, documented conversation, with specific instances, before considering escalation beyond the two of you.

Worked example

A senior engineer repeatedly interrupts and dismisses ideas in planning meetings, and quieter teammates have stopped proposing alternatives. You raise it privately, citing two specific instances and what was lost each time, and ask if something's driving the pattern. They didn't realize the effect and agree to a shared cue: a raised hand or a "hold that thought, back to you after" from whoever's facilitating. The behavior improves within a couple of meetings once the norm is visible and mutual rather than a private correction only they know about.

The same graduated shape applies to a very different kind of friction: two peers who've been informally swapping on-call shifts in a way the rest of the team has started to perceive as unfair. There the first conversation isn't about correcting a behavior, it's about surfacing that the arrangement looks uneven from outside and asking the two of them how they'd want it made visible. It still ends the same way structurally, not with a cue this time, but with a durable, documented agreement: who's allowed to swap, how it gets logged, and how the rest of the team is notified, so the fairness question doesn't quietly resurface every few weeks.

Trade-offs and pitfalls

Correcting someone publicly on the first instance humiliates them in front of peers and tends to produce defensiveness rather than change, even when the feedback is accurate. A private conversation that stays vague ("try to be more mindful in meetings") doesn't give them anything concrete to change and often needs repeating. When the underlying friction is actually about status or unclear role boundaries rather than a communication habit, a meeting norm won't fix it; that needs a structural conversation about who owns what, not a cue card.

Direct answer

Start with the component diagram. It establishes what pieces exist and who owns each one, before anything about behavior or payloads makes sense; architects can't reason about "what happens when" until they know "what's here."

Structured elaboration

1. Component diagram (what exists). Purpose: boundaries and ownership. Show: application services, cache cluster nodes, the source-of-truth database, an invalidation service, and a message broker. Leave off: exact protocol, message schema, and timing, those belong later.

2. Sequence diagram (what happens, in order). Purpose: the actual interaction for one invalidation event. Show: a write to the database, the database acknowledging it, an event published to the invalidation service, that service publishing an evict message on the broker, the broker fanning out to cache nodes, and one failure path (broker unavailable: what serves stale data, and for how long). Leave off: byte-level payload detail and retention settings, that's the next diagram's job.

3. Data-flow diagram (what exactly, and how stale). Purpose: payloads and guarantees. Show: the invalidation message's schema (key, version, timestamp), time-to-live, message size, and the one metric architects will actually watch, invalidation latency or staleness window. Leave off: anything already covered by the component-level framing.

Why this order helps comprehension: each diagram answers the question the previous one raised. Component diagram: "what is the invalidation service." Sequence diagram: "how does it know to fire." Data-flow diagram: "how stale can a read get before this evicts it." Reversing the order, starting with the sequence diagram, forces you to define every box mid-sentence instead of pointing at one the audience has already seen.

Worked example

The component diagram you'd draw first:

flowchart LR
    App[Application] -->|write| DB[(Database)]
    App -->|read| Cache[(Cache Cluster)]
    DB -->|change event| Invalidator[Invalidation Service]
    Invalidator -->|publish evict msg| Broker[[Message Broker]]
    Broker -->|fan out| Cache
    Cache -->|miss, reload| DB

Narrated: "The application writes to the database. That write triggers a change event to the invalidation service, which publishes an evict message on the broker. The broker fans that message out to every cache node, and the next read that misses reloads from the database."

Translating the core idea for the architects: the jargon term is "cache coherence." Plain version: "keeping the cache from serving an answer that's gone stale since the database changed." Analogy: it's like a library's card catalog. When a book gets re-shelved, someone has to walk over and update the card, or the next person who checks the card gets sent to the wrong shelf. Where the analogy breaks: no single librarian updates every card at once across a building, the fan-out to many cache nodes in parallel, possibly across regions, is exactly what makes this hard in practice, and that's the detail worth naming once the audience has the basic picture.

Trade-offs & pitfalls

The common wrong turn is leading with the sequence diagram because it feels more "technical," which forces you to define the invalidation service, the broker, and the cache cluster mid-sentence instead of pointing at boxes the audience already recognizes. A second pitfall: putting the failure path (broker down) in the component diagram instead of the sequence diagram, error paths are behavior over time and belong where the audience is already reasoning about timing. A third: overloading the data-flow diagram with architectural detail that duplicates the first diagram instead of adding new information (payload size, TTL, staleness), which makes the customer conversation feel repetitive rather than cumulative.

Situation
At my previous job I was the frontend lead for an e‑commerce checkout redesign. Designers pushed a high‑visibility animation and a richer payment UI slated for the next sprint, but our analytics showed rising bounce rates on mobile checkout.

Task
Convince product and design to reprioritize a performance sprint (critical rendering, JS bundle split, image optimization) ahead of the visual feature.

Action
I used STAR: presented data and tradeoffs.

• Quantitative: Crashlytics + GA showed 18% mobile checkout abandonment and Time to Interactive of 6.2s on 3G. Lighthouse reported performance score 42.
• Qualitative: customer support transcripts with 12 mentions of “slow checkout” and user test clips where users abandoned during spinner.
• Proposed focused scope: split vendor bundles, lazy‑load nonessential widgets, compress hero images — estimated 5 dev days.
• Balanced deadlines: suggested phased delivery — performance fixes first, staggered animation work into next sprint; offered a demo branch and a 48‑hour hotfix for critical JS.

Result
Team agreed. After delivery:

• TTI reduced from 6.2s to 2.1s, Lighthouse score rose to 78.
• Mobile checkout abandonment dropped from 18% to 10% in four weeks — estimated $120k/mo recovered revenue.
• Product shipped the animation two sprints later with no regressions. I learned to pair data with a minimal risk plan to get stakeholder buy‑in.

Overview (why this matters for a frontend dev)
Understanding exact scheduling differences avoids subtle bugs (UI jank, starvation, unexpected ordering) and helps write portable async code that behaves consistently across browsers and Node.js.

Browser event loop (high level)

• Macrotasks (tasks): callbacks from setTimeout/setInterval, I/O, user events — browser executes one macrotask at a time.
• Microtasks: Promise callbacks (.then/.catch/.finally), queueMicrotask, MutationObserver callbacks.
• Ordering: after a macrotask finishes the engine drains the entire microtask queue (run all microtasks) before the browser may update rendering and then process the next macrotask. Rendering/layout/paint happens between macrotasks after microtasks complete.
• Practical: Promise callbacks run before the next paint; queueMicrotask and MutationObserver are microtasks — MutationObserver runs after other microtasks in some browsers but is considered a microtask-level callback (consistent ordering: promise microtasks first, MutationObserver typically after).

Node.js event loop (phases)

• Phases: timers -> pending callbacks -> idle/prepare -> poll -> check -> close callbacks.
• setTimeout/setInterval: scheduled in timers phase.
• setImmediate: scheduled in check phase (runs after poll).
• I/O callbacks: poll phase.
• process.nextTick: special — runs immediately after current operation, before any other microtasks or next event-loop phase (can starve the loop if abused).
• Microtasks (Promise .then) are processed between each phase's callback completion (Node drains microtask queue between phases), but process.nextTick is higher priority than Promise microtasks.
• MutationObserver/browser-only; queueMicrotask and Promises exist in both (Promise microtasks behave similarly, but nextTick is Node-specific).

Where each API is scheduled

• Promise callbacks (.then/.catch/.finally): microtask queue — run after current macrotask, before rendering (browsers) and between Node phases (Node).
• queueMicrotask: explicit microtask — same timing as Promise microtasks.
• MutationObserver: microtask-level, typically runs after Promise microtasks in browsers — useful for DOM-change reactions but not available in Node.
• setTimeout(..., 0): macrotask/timers phase — runs after microtasks and next tick; unpredictable minimum delay due to clamping and phase ordering.
• setImmediate: Node-only, runs in check phase — often executes before a zero-timeout if scheduled from an I/O callback.
• process.nextTick: Node-only, runs before other microtasks and next event-loop phase.

Practical consequences & portable patterns

• For immediate "after current sync" work that must run before rendering: use queueMicrotask or Promise microtasks (portable to browsers and Node). Example: queueMicrotask(()=> update internal state before repaint).
• To schedule work after paint: use requestAnimationFrame (browser) or setTimeout(..., 0) as fallback; do not rely on microtasks to let paint occur.
• Avoid process.nextTick or setImmediate if you need cross-environment behavior — use Promises/queueMicrotask (portable) or feature-detect.
• Avoid assuming ordering between MutationObserver and Promise across all browsers; use explicit microtask APIs (queueMicrotask/Promise) for predictable ordering, and MutationObserver only for DOM change observation.
• Beware starvation: heavy microtask chains (Promises/nextTick) can block rendering and I/O — yield via setTimeout/setImmediate/requestAnimationFrame when needed.

Examples (ordering):

• In browser: setTimeout -> Promise.then -> render
  • Execution: sync code -> Promise.then -> render -> setTimeout callback
• In Node: from I/O callback, setImmediate may run before setTimeout(0); process.nextTick runs before Promise microtasks.

Use feature detection and prefer Promise/queueMicrotask + rAF for UI timing; reserve Node-specific APIs for server-side code.

Approach
Use React.lazy + Suspense for route-level lazy loading, and configure webpack splitChunks to separate vendor code. Verify with build analysis and browser network tab.

Code (React routes)

// App.jsx
import React, { Suspense } from "react";
import { BrowserRouter, Routes, Route } from "react-router-dom";

const Home = React.lazy(() => import("./pages/Home"));
const Dashboard = React.lazy(() => import("./pages/Dashboard"));
const Settings = React.lazy(() => import("./pages/Settings"));

export default function App(){
  return (
    <BrowserRouter>
      <Suspense fallback={<div>Loading...</div>}>
        <Routes>
          <Route path="/" element={<Home/>}/>
          <Route path="/dashboard" element={<Dashboard/>}/>
          <Route path="/settings" element={<Settings/>}/>
        </Routes>
      </Suspense>
    </BrowserRouter>
  );
}

webpack splitChunks

// webpack.config.js (production)
module.exports = {
  // ...entry, output, etc.
  optimization: {
    splitChunks: {
      chunks: "all",
      cacheGroups: {
        vendors: {
          test: /[\\/]node_modules[\\/]/,
          name: "vendors",
          chunks: "all",
          priority: -10
        },
        default: {
          minChunks: 2,
          priority: -20,
          reuseExistingChunk: true
        }
      }
    }
  }
};

How to verify

• Run production build and inspect output/ filenames (vendors~.js, Home~.js).
• Use webpack-bundle-analyzer: new BundleAnalyzerPlugin() to see chunk composition.
• Check Chrome DevTools Network tab on navigation to confirm route chunks load on-demand and vendor chunk is cached/shared.
• Ensure long-term caching by adding contenthash to filenames and validate cache headers.