Performance "at scale" usually means: high request volume, large bundles, lots of users on slow networks/devices. The approach is to measure, isolate the bottleneck, and fix in layers — not premature micro-optimization.

Step 0: measure first

You can't optimize what you don't measure. Two sources:

• Lab data: Lighthouse, WebPageTest, local profiling. Reproducible, but synthetic.
• Field data (RUM): Real-user metrics via web-vitals.js → analytics. P75/P95 from actual users on actual devices/networks. This is what matters.

Track Core Web Vitals: LCP (largest paint), INP (interaction responsiveness, replaced FID), CLS (layout stability). Add custom marks for app-specific flows (time-to-search-results, time-to-checkout-load).

Network layer

• CDN: serve static assets and ideally HTML from edge.
• HTTP/2 or HTTP/3: multiplexing eliminates 6-conn limit; header compression cuts overhead.
• Compression: Brotli for text (~20% better than gzip).
• Image formats: AVIF / WebP (30–50% smaller than JPEG).
• Responsive images: srcset + sizes so mobile doesn't download 1600w when 400w fits.
• Caching: long max-age on hashed assets; ETag/Last-Modified for HTML; service worker for offline.
• Resource hints: preload LCP image + critical fonts, preconnect to third-party origins.

Bundle layer

• Code split per route and per heavy widget. Initial bundle target: <200KB gzipped for typical SaaS.
• Tree-shaking: import only what you use (import { debounce } from 'lodash-es', not the whole lodash).
• Dependency audit: bundle-analyzer once a quarter; rip out duplicates, replace heavy deps (moment → date-fns or dayjs).
• Modern JS for modern browsers: type=module + nomodule fallback. Skip polyfills for unsupported old browsers if your audience doesn't have them.
• Defer non-critical CSS: inline above-the-fold, async-load the rest.

Render layer (React-specific)

• Avoid unnecessary re-renders: stable callbacks (useCallback) and memoized values (useMemo) where they actually save work. Don't blanket-memoize — useMemo itself has cost.
• List virtualization: react-window / TanStack Virtual for >100 rows.
• Suspend heavy children: React.lazy + Suspense for modals, drawers.
• Concurrent features: useTransition for non-urgent updates (filter input → big list re-sort).
• Avoid layout thrash: don't interleave reads (offsetWidth) with writes (style.x) in a tight loop.

Runtime / interaction layer

• Debounce / throttle rapid events (resize, scroll, input).
• Web workers for CPU-heavy work (parsing, image manipulation, compression) — keeps main thread responsive for INP.
• requestIdleCallback for low-priority background work (analytics flush, log shipping).
• Avoid blocking the main thread: split long tasks (>50ms) with scheduler.yield() or chunked setTimeout.

Data layer

• Cache at HTTP level (Cache-Control, ETag) and app level (React Query / RTKQ).
• Dedup identical concurrent requests.
• Paginate / cursor: don't return 10k rows when 50 will do.
• Stream large responses (SSE for live, ReadableStream for big JSON).
• Optimistic UI: update locally on mutation, reconcile with server.

Process

1. Run RUM. Find the worst metric.
2. Open DevTools → Performance → record the slow flow.
3. Identify the bottleneck (LCP image too big? Long task on render? Waterfall fetch?).
4. Fix the biggest one. Re-measure.
5. Repeat.

What NOT to do

• Don't useMemo every value — the comparison cost can exceed the recompute cost for cheap operations.
• Don't reach for web workers for tiny tasks — postMessage overhead can eat the win.
• Don't optimize what isn't profiled-slow.
• Don't replace clear code with cryptic micro-optimizations for ~1% wins.
• Don't trust synthetic benchmarks — measure real user metrics.

Mental model

Most performance wins at scale come from a handful of changes:

1. Right image format + size.
2. Smaller initial JS bundle.
3. Cache.
4. Defer offscreen.

The exotic stuff (web workers, virtualization, concurrent React) helps in specific cases but is rarely the biggest lever.