Frontend II — Advanced / Real-World / System-Level

🔥 How to Optimize Frontend Performance — The Real Answer

Don't list random techniques. Structure your answer around the rendering pipeline: Network → Parse → Render → Interact. Each stage has specific bottlenecks and solutions.

Stage 1: Network — Reduce What You Send

• Code splitting — load only what the current route needs (React.lazy, dynamic import())
• Tree shaking — eliminate dead code at build time (requires ES modules)
• Compression — Brotli > Gzip. Configure at CDN/server level
• Image optimization — WebP/AVIF, responsive srcset, lazy loading with loading="lazy"
• Font optimization — font-display: swap, subset fonts, preload critical fonts
• CDN — serve static assets from edge locations close to users

Stage 2: Parse & Render — Don't Block the Main Thread

• Minimize render-blocking CSS — inline critical CSS, defer non-critical
• Defer/async scripts — defer for scripts that need DOM, async for independent scripts
• Avoid layout thrashing — batch DOM reads before writes
• Use content-visibility: auto for off-screen content

Stage 3: Runtime — Keep Interactions Smooth

• Virtualize long lists (render only visible items)
• Debounce/throttle expensive event handlers
• Use Web Workers for CPU-heavy computation off the main thread
• Memoize expensive React renders (React.memo, useMemo)
• Avoid unnecessary re-renders — stable references, proper key usage

Bundle Size Reduction — Practical Playbook

Bundle size directly impacts load time. Every 100KB of JS adds ~300ms on a mid-range mobile device (parse + compile + execute). Here's the real playbook:

# Step 1: Analyze what's in your bundle
npx webpack-bundle-analyzer stats.json
# or for Next.js:
ANALYZE=true next build

# Step 2: Find the culprits (usually)
# - moment.js → replace with day.js (70KB → 2KB)
# - lodash → import individual functions: import debounce from 'lodash/debounce'
# - icons → import specific icons, not the entire library
# - polyfills → target modern browsers, drop IE11 support

# Step 3: Code split aggressively
# - Route-based splitting (automatic in Next.js)
# - Component-based: React.lazy for heavy components
# - Library-based: dynamic import for rarely-used features

Critical Rendering Path — What Actually Happens

Browser receives HTML → parses to DOM → encounters CSS → builds CSSOM → combines into Render Tree → Layout (geometry) → Paint (pixels) → Composite (layers). CSS blocks rendering. JS blocks parsing (unless async/defer). This is why you inline critical CSS and defer everything else.

Web Workers — When to Use

Web Workers run JavaScript in a background thread, separate from the main thread. They can't access the DOM. Communication happens via postMessage. Use them for: heavy computation (sorting large datasets, image processing, crypto), parsing large JSON, or running WebAssembly.

// main.ts
const worker = new Worker(new URL('./heavy-task.worker.ts', import.meta.url));
worker.postMessage({ data: largeDataset });
worker.onmessage = (e) => {
  console.log('Result:', e.data); // runs on main thread
};

// heavy-task.worker.ts
self.onmessage = (e) => {
  const result = expensiveComputation(e.data);
  self.postMessage(result); // send back to main thread
};

📝 Quick Revision

Common Interview Questions

Real-world apps make dozens of API calls. The hard part isn't making them — it's handling cancellation, race conditions, retries, and error states gracefully. This is where production code diverges from tutorial code.

🔥 AbortController — Cancelling Requests

AbortController is the standard way to cancel fetch requests. Create a controller, pass its signal to fetch, and call abort() when you need to cancel. This is critical in React — if a component unmounts while a fetch is in-flight, you must cancel it to prevent state updates on unmounted components.

// In a React component
useEffect(() => {
  const controller = new AbortController();

  async function fetchData() {
    try {
      const res = await fetch(`/api/search?q=${query}`, {
        signal: controller.signal,
      });
      const data = await res.json();
      setResults(data);
    } catch (err) {
      if (err instanceof DOMException && err.name === 'AbortError') {
        // Request was cancelled — this is expected, not an error
        return;
      }
      setError(err); // actual error
    }
  }

  fetchData();
  return () => controller.abort(); // cancel on unmount or query change
}, [query]);

🔥 Race Conditions — The Silent Bug

User types "react" in a search box. Three requests fire: "r", "re", "react". If "re" returns after "react", the UI shows stale results. This is a race condition. Solutions:

• AbortController — cancel previous request when a new one fires
• Request ID — track the latest request ID, ignore responses from older IDs
• Debounce — don't fire until user stops typing (reduces but doesn't eliminate races)
• Libraries — React Query / SWR handle this automatically with stale-while-revalidate

// Pattern: ignore stale responses with a flag
useEffect(() => {
  let cancelled = false;

  async function fetchResults() {
    const res = await fetch(`/api/search?q=${query}`);
    const data = await res.json();
    if (!cancelled) {
      setResults(data); // only update if this is still the latest request
    }
  }

  fetchResults();
  return () => { cancelled = true; };
}, [query]);

// Better: combine debounce + AbortController
// Debounce reduces request count, AbortController cancels in-flight ones

fetch vs axios — Real Differences

📝 Quick Revision

The Rendering Spectrum

🔥 Hydration — The Bridge Between Server and Client

Hydration is the process where React takes the server-rendered HTML and "attaches" event listeners and state to make it interactive. The server sends static HTML (fast to display), then the client-side JS "hydrates" it into a fully interactive React app.

The critical insight: during hydration, React doesn't re-render from scratch. It walks the existing DOM and attaches handlers. If the server HTML doesn't match what React expects on the client, you get a hydration mismatch error.

// ❌ Common hydration mismatch — using Date or Math.random
function Greeting() {
  // Server renders "Good morning" at 9am server time
  // Client hydrates at 2pm user time → "Good afternoon"
  // React: "Hydration mismatch!"
  const hour = new Date().getHours();
  return <p>{hour < 12 ? 'Good morning' : 'Good afternoon'}</p>;
}

// ✅ Fix: use useEffect for client-only values
function Greeting() {
  const [greeting, setGreeting] = useState('Hello');
  useEffect(() => {
    const hour = new Date().getHours();
    setGreeting(hour < 12 ? 'Good morning' : 'Good afternoon');
  }, []);
  return <p>{greeting}</p>;
}

Dehydration & Rehydration (Data)

Beyond DOM hydration, there's data hydration. Libraries like React Query support "dehydrating" the cache on the server (serializing fetched data into the HTML) and "rehydrating" it on the client (restoring the cache without re-fetching). This avoids the double-fetch problem: server fetches data → renders HTML → client hydrates → client fetches same data again.

📝 Quick Revision

HTTP is request-response: client asks, server answers, connection closes. WebSocket is a persistent, full-duplex connection — both sides can send data at any time. This is the foundation of real-time features.

How WebSocket Works

It starts as an HTTP request with an Upgrade: websocket header. If the server agrees, the connection upgrades to WebSocket protocol (ws:// or wss://). From there, both client and server can push messages without the overhead of HTTP headers on every message.

const ws = new WebSocket('wss://api.example.com/live');

ws.onopen = () => {
  console.log('Connected');
  ws.send(JSON.stringify({ type: 'subscribe', channel: 'prices' }));
};

ws.onmessage = (event) => {
  const data = JSON.parse(event.data);
  updateUI(data); // real-time update
};

ws.onclose = (event) => {
  if (!event.wasClean) {
    // Reconnect with exponential backoff
    setTimeout(() => reconnect(), getBackoffDelay());
  }
};

ws.onerror = (error) => console.error('WebSocket error:', error);

When to Use WebSocket vs Alternatives

📝 Quick Revision

A Service Worker is a script that runs in the background, separate from the web page. It acts as a programmable network proxy — intercepting requests, caching responses, and enabling offline functionality. It's the backbone of Progressive Web Apps (PWAs).

Lifecycle

Register → Install (cache assets) → Activate (clean old caches) → Fetch (intercept requests). The SW doesn't control the page on first visit — only on subsequent navigations. It runs on a separate thread, can't access the DOM, and communicates via postMessage.

Caching Strategies

// Stale-while-revalidate strategy
self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.open('dynamic-v1').then(async (cache) => {
      const cachedResponse = await cache.match(event.request);
      const fetchPromise = fetch(event.request).then((networkResponse) => {
        cache.put(event.request, networkResponse.clone());
        return networkResponse;
      });
      return cachedResponse || fetchPromise; // serve stale, update in background
    })
  );
});

📝 Quick Revision

Security isn't just a backend concern. Frontend devs are the first line of defense against XSS and play a key role in CSRF prevention. Interviewers expect you to know the attack vectors and practical mitigations.

🔥 XSS (Cross-Site Scripting)

Attacker injects malicious script into your page. It runs in the context of your domain — can steal cookies, tokens, user data. Three types: Stored (persisted in DB), Reflected (in URL params), DOM-based (client-side JS manipulation).

Frontend Prevention:

• Never use dangerouslySetInnerHTML with user input (React escapes by default — don't bypass it)
• Sanitize HTML if you must render it (DOMPurify library)
• Use Content Security Policy (CSP) headers to restrict script sources
• Validate and encode user input on both client and server
• Use httpOnly cookies for tokens (JS can't access them)

CSRF (Cross-Site Request Forgery)

Attacker tricks the user's browser into making a request to your site (where the user is authenticated). The browser automatically sends cookies, so the request looks legitimate. Example: a hidden form on evil.com that POSTs to your-bank.com/transfer.

Frontend Prevention:

• CSRF tokens — server generates a unique token per session, frontend sends it with every state-changing request
• SameSite=Strict or Lax on cookies — prevents cross-origin cookie sending
• Check Origin / Referer headers on the server
• Use custom headers (e.g., X-Requested-With) — simple requests can't set custom headers

📝 Quick Revision

🔥 Reconciliation — Deep Understanding

When state changes, React creates a new virtual DOM tree and diffs it against the previous one. The diffing algorithm (reconciliation) uses two heuristics: 1) Different element types produce different trees (full remount). 2) Keys identify which children are stable across renders. React then computes the minimal set of DOM operations needed.

The Fiber architecture (React 16+) made reconciliation interruptible. Instead of processing the entire tree synchronously, React breaks work into units (fibers) and can pause, prioritize, or abort work. This is the foundation of concurrent features.

React 16 vs React 18 — What Changed

State Scheduling & Concurrent Features

React 18 introduced the concept of update priorities. Not all state updates are equal — typing in an input is urgent, filtering a large list is not. startTransition lets you mark non-urgent updates so React can keep the UI responsive.

import { useState, useTransition } from 'react';

function SearchPage() {
  const [query, setQuery] = useState('');
  const [results, setResults] = useState([]);
  const [isPending, startTransition] = useTransition();

  function handleChange(e: React.ChangeEvent<HTMLInputElement>) {
    setQuery(e.target.value); // urgent — update input immediately

    startTransition(() => {
      setResults(filterLargeList(e.target.value)); // non-urgent — can be interrupted
    });
  }

  return (
    <>
      <input value={query} onChange={handleChange} />
      {isPending && <Spinner />}
      <ResultsList results={results} />
    </>
  );
}

Stale Closures — The Hidden Bug

A stale closure happens when a function captures an old value of state or props and doesn't see updates. This is the most common source of subtle bugs in React hooks.

// ❌ Stale closure — count is always 0 inside the interval
function Counter() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    const id = setInterval(() => {
      console.log(count); // always 0 — captured at mount time
      setCount(count + 1); // always sets to 1
    }, 1000);
    return () => clearInterval(id);
  }, []); // empty deps = closure captures initial count

  return <p>{count}</p>;
}

// ✅ Fix 1: Use functional updater
setCount(prev => prev + 1); // doesn't depend on closure value

// ✅ Fix 2: Use ref for latest value
const countRef = useRef(count);
countRef.current = count; // always up to date
// Inside interval: console.log(countRef.current);

Context API — When NOT to Use It

Context is great for low-frequency updates (theme, locale, auth status). It's terrible for high-frequency updates (form state, animation values, frequently changing data) because every consumer re-renders when the context value changes — there's no way to subscribe to a slice of context.

• ✅ Use Context for: theme, locale, auth, feature flags
• ❌ Avoid Context for: form state, frequently updating data, large state objects
• Alternative: Zustand, Jotai (atomic state), or React Query (server state)
• Workaround: split context into multiple smaller contexts to reduce re-renders

Redux Toolkit — Why It Exists

Classic Redux had too much boilerplate: action types, action creators, reducers, immutable updates. Redux Toolkit (RTK) is the official, opinionated way to write Redux. It uses Immer for immutable updates (write "mutating" code that's actually immutable), createSlice for reducers + actions in one place, and RTK Query for data fetching with caching.

Error Boundaries

Error Boundaries are class components that catch JavaScript errors in their child component tree during rendering, lifecycle methods, and constructors. They display a fallback UI instead of crashing the entire app.

class ErrorBoundary extends React.Component<
  { children: React.ReactNode; fallback: React.ReactNode },
  { hasError: boolean }
> {
  state = { hasError: false };

  static getDerivedStateFromError() {
    return { hasError: true };
  }

  componentDidCatch(error: Error, info: React.ErrorInfo) {
    logErrorToService(error, info.componentStack); // send to Sentry/DataDog
  }

  render() {
    if (this.state.hasError) return this.props.fallback;
    return this.props.children;
  }
}

// Usage: wrap sections, not the entire app
<ErrorBoundary fallback={<p>Something went wrong in this section.</p>}>
  <RiskyComponent />
</ErrorBoundary>

Limitations: Error Boundaries do NOT catch errors in event handlers (use try/catch), async code (use .catch()), SSR, or errors in the boundary itself. For event handlers, use a global error handler or try/catch within the handler.

Suspense — Beyond Lazy Loading

Suspense lets you declaratively handle loading states. In React 18, it works with: code splitting (React.lazy), data fetching (via compatible libraries like React Query, Relay), and streaming SSR. The component "suspends" by throwing a Promise — React catches it and shows the fallback until the Promise resolves.

import { Suspense, lazy } from 'react';

const HeavyChart = lazy(() => import('./HeavyChart'));

function Dashboard() {
  return (
    <div>
      <h1>Dashboard</h1>
      <Suspense fallback={<ChartSkeleton />}>
        <HeavyChart /> {/* loads only when rendered */}
      </Suspense>
    </div>
  );
}

// With streaming SSR (Next.js App Router):
// Server streams the shell immediately, then streams
// the Suspense content when it's ready. User sees
// progressive loading instead of a blank page.

Loaders & Actions (React Router Data APIs)

React Router v6.4+ introduced loaders (fetch data before rendering a route) and actions (handle form submissions). This moves data fetching from components to the route level — similar to how Remix/Next.js work. Benefits: no loading spinners (data is ready when the route renders), parallel data fetching, and automatic revalidation after mutations.

📝 Quick Revision

Common Interview Questions

These aren't textbook JS questions — they're the kind of problems you hit in production. Interviewers use them to test whether you've actually built things or just read about them.

🔥 Implement Throttle (With Edge Cases)

Throttle ensures a function fires at most once every N milliseconds. The tricky part: should it fire on the leading edge (immediately), trailing edge (after the delay), or both? Most interviewers expect the leading + trailing version.

function throttle<T extends (...args: unknown[]) => void>(
  fn: T,
  limit: number
): (...args: Parameters<T>) => void {
  let lastCall = 0;
  let timer: ReturnType<typeof setTimeout> | null = null;

  return (...args: Parameters<T>) => {
    const now = Date.now();
    const remaining = limit - (now - lastCall);

    if (remaining <= 0) {
      // Leading edge: enough time has passed, fire immediately
      if (timer) { clearTimeout(timer); timer = null; }
      lastCall = now;
      fn(...args);
    } else if (!timer) {
      // Trailing edge: schedule the last call
      timer = setTimeout(() => {
        lastCall = Date.now();
        timer = null;
        fn(...args);
      }, remaining);
    }
  };
}

// Edge cases to mention in interviews:
// 1. What if the function is called exactly at the limit boundary?
// 2. Should the trailing call use the latest args or the first args?
// 3. Do you need a cancel() method? (yes, for cleanup)
// 4. What about 'this' context? (use .apply or arrow functions)

Memory Leaks in Frontend Apps

Memory leaks happen when the app holds references to objects that are no longer needed, preventing garbage collection. In frontend apps, the most common causes:

• Forgotten event listeners — added in useEffect without cleanup
• Uncleared timers — setInterval/setTimeout without clearInterval/clearTimeout
• Detached DOM nodes — removed from DOM but still referenced in JS
• Closures holding large objects — callbacks that capture entire scope
• Uncancelled fetch requests — updating state on unmounted components
• Global variables / window properties — never garbage collected

// ❌ Memory leak: event listener never removed
useEffect(() => {
  window.addEventListener('resize', handleResize);
  // missing cleanup!
}, []);

// ✅ Fix: always clean up
useEffect(() => {
  window.addEventListener('resize', handleResize);
  return () => window.removeEventListener('resize', handleResize);
}, []);

// ❌ Memory leak: interval never cleared
useEffect(() => {
  setInterval(pollServer, 5000);
}, []);

// ✅ Fix: clear on unmount
useEffect(() => {
  const id = setInterval(pollServer, 5000);
  return () => clearInterval(id);
}, []);

// Debugging: Chrome DevTools → Memory tab → Heap Snapshot
// Take snapshot before and after navigation, compare retained objects

📝 Quick Revision

Architecture questions test your ability to make trade-off decisions at scale. There's no single right answer — the interviewer wants to see your reasoning process.

GraphQL vs REST — When to Use What

How to Choose Libraries — The Real Framework

"Why did you pick X over Y?" is a senior-level question. Here's the decision framework that impresses interviewers:

• Bundle size — Day.js (2KB) vs Moment.js (70KB). Does the size justify the features?
• Maintenance — Is it actively maintained? Check GitHub: last commit, open issues, release frequency
• Tree-shakeable — Can you import only what you need? (lodash-es vs lodash)
• TypeScript support — First-class types or @types package? Quality of types?
• Community & ecosystem — Docs quality, Stack Overflow answers, plugins
• API surface — Does it do too much? Simpler libraries are easier to replace
• Team familiarity — The best library is the one your team can use effectively

Folder Structure for Large-Scale React Apps

# Feature-based (recommended for large apps)
src/
├── features/
│   ├── auth/
│   │   ├── components/    # LoginForm, SignupForm
│   │   ├── hooks/         # useAuth, useSession
│   │   ├── services/      # authApi.ts
│   │   ├── types/         # User, Session
│   │   └── index.ts       # public API of this feature
│   ├── dashboard/
│   │   ├── components/
│   │   ├── hooks/
│   │   └── ...
│   └── payments/
├── shared/                # truly shared utilities
│   ├── components/        # Button, Modal, Input
│   ├── hooks/             # useDebounce, useMediaQuery
│   └── utils/             # formatDate, cn()
├── app/                   # routing, layouts
└── config/                # env, constants

# Key principles:
# 1. Co-locate related code (component + hook + test together)
# 2. Features don't import from other features (use shared/)
# 3. Each feature has a public API (index.ts barrel export)
# 4. Flat > nested — avoid more than 3 levels deep

Scalable Frontend Architecture — How to Think About It

When asked "how would you design a scalable frontend," structure your answer around these pillars:

📝 Quick Revision

🔥 Webpack — How Bundling Works Internally

Webpack starts from an entry point (e.g., index.tsx), follows all import/require statements to build a dependency graph, then bundles everything into one or more output files. Along the way, loaders transform files (Babel for JSX → JS, css-loader for CSS, file-loader for images) and plugins handle optimization (minification, code splitting, HTML generation).

# Webpack internal pipeline:
Entry Point (index.tsx)
  → Resolve imports (build dependency graph)
  → Apply Loaders (transform files)
    → babel-loader: JSX/TS → JS
    → css-loader: CSS → JS module
    → file-loader: images → hashed URLs
  → Apply Plugins (optimize)
    → TerserPlugin: minify JS
    → MiniCssExtractPlugin: extract CSS to files
    → HtmlWebpackPlugin: generate HTML
  → Code Splitting (dynamic imports → separate chunks)
  → Output (dist/bundle.[hash].js)

# Key concepts:
# - Chunks: pieces of the bundle (entry chunk, async chunks)
# - Hash: content-based filename for cache busting
# - Loaders: transform individual files
# - Plugins: operate on the entire compilation

🔥 Tree Shaking — How It Actually Works

Tree shaking eliminates dead code — exports that are imported but never used. It relies on ES module static analysis: because import/export are statically analyzable (unlike require), the bundler can determine at build time which exports are used and remove the rest.

Requirements for tree shaking to work:

• ES modules (import/export), not CommonJS (require)
• "sideEffects": false in package.json (tells bundler it's safe to remove unused exports)
• Production mode (development preserves everything for debugging)
• No side effects in module scope (top-level code that runs on import defeats tree shaking)

// ✅ Tree-shakeable — bundler can remove unused exports
export function add(a: number, b: number) { return a + b; }
export function multiply(a: number, b: number) { return a * b; }

// Consumer only imports add → multiply is removed from bundle
import { add } from './math';

// ❌ NOT tree-shakeable — CommonJS
module.exports = { add, multiply };
const { add } = require('./math'); // bundler can't statically analyze

// ❌ Side effect prevents tree shaking
export function add(a, b) { return a + b; }
console.log('math module loaded'); // this runs on import — can't be removed

// Practical impact:
// import _ from 'lodash'        → 70KB (entire library)
// import debounce from 'lodash/debounce' → 2KB (just debounce)
// import { debounce } from 'lodash-es'   → 2KB (tree-shaken)

package-lock.json — Why It Matters

package.json specifies version ranges (^1.2.3 means >=1.2.3 <2.0.0). package-lock.json pins the exact versions installed, including all transitive dependencies. Without it, two developers running npm install could get different versions. Always commit it. Use npm ci in CI (installs exactly what's in the lockfile, faster than npm install).

Source Maps — Debugging in Production

Minified production code is unreadable. Source maps are files that map minified code back to the original source. They let you debug production errors with original file names, line numbers, and variable names. Configure your error tracking tool (Sentry) to upload source maps during build — then delete them from the public server (don't expose source code to users).

GitHub Actions — CI/CD for Frontend

GitHub Actions automate your build pipeline. A workflow is defined in a YAML file (.github/workflows/ci.yml). It runs on events (push, PR) and executes jobs (lint, test, build, deploy).

name: CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci              # install exact lockfile versions
      - run: npm run lint         # catch code style issues
      - run: npm run type-check   # TypeScript errors
      - run: npm run test -- --run  # run tests (not watch mode)
      - run: npm run build        # ensure production build works

# Why YAML?
# - Human-readable structured data format
# - Used by GitHub Actions, Docker Compose, K8s, CloudFormation
# - Indentation-based (like Python) — spaces, not tabs
# - Supports strings, numbers, booleans, lists, maps

Instrumentation in Next.js

Next.js 13.2+ supports an instrumentation.ts file at the project root. It runs when the Next.js server starts — before any request is handled. Use it for: initializing monitoring tools (OpenTelemetry, Sentry), setting up logging, connecting to databases, or registering custom metrics. It runs once on server startup, not per-request.

Sitemap & robots.txt — SEO Essentials

sitemap.xml tells search engines which pages exist and their priority. robots.txt tells crawlers which pages to index and which to skip. In Next.js, you can generate both programmatically using app/sitemap.ts and app/robots.ts. Always include a sitemap for SEO-critical apps. Use robots.txt to block admin pages, API routes, and staging environments from indexing.

📝 Quick Revision

Common Interview Questions

These are the questions that come up repeatedly in senior frontend interviews. Each one has a short, crisp answer for quick revision and a deeper explanation in the relevant section above.

These are the mistakes that experienced developers still make — and the ones interviewers specifically look for. Knowing these shows self-awareness and production experience.

Architecture questions don't have a single right answer. The interviewer is evaluating your thought process, not checking a rubric. Here's the framework that works.

The RADIO Framework for Frontend System Design

Example Scenarios

🟡 Performance & Rendering

🟢 React Internals

🔵 API & Networking

🟣 Architecture & Tooling

🔥 Must-Remember One-Liners

• Hydration: Server sends static HTML for speed, client JS makes it interactive. Mismatch = bug.
• Tree shaking: Dead code elimination. ES modules only. sideEffects: false is the key.
• Stale closure: useEffect with empty deps + setInterval = captures initial state forever.
• Context re-renders: Every consumer re-renders. Split contexts or use external state.
• AbortController: The only correct way to cancel fetch. Always use in useEffect cleanup.
• Error Boundaries: Only catch render errors. Event handlers need try/catch.
• Bundle size: Every 100KB JS ≈ 300ms on mid-range mobile. Measure, don't guess.
• Webpack loaders vs plugins: Loaders transform files. Plugins operate on the compilation.
• npm ci vs npm install: ci uses lockfile exactly, faster, for CI. install resolves and may update.
• CSR vs SSR decision: Need SEO? → SSR/SSG. Internal tool? → CSR. Personalized + SEO? → SSR.