Frontend Performance and Rendering Optimization Questions

Clarify the problem
I’d build a dashboard showing N widgets, each currently backed by its own endpoint (counts, trends, user activity, alerts). Goal: reduce perceived latency and improve UX (fast first paint, progressive hydration).

Strategies & how they interact

• GraphQL batching / single query

  • Combine fields for all widgets into one GraphQL query so client issues one request. Reduces RTTs and enables server-side batching/fetch optimization.
  • Trade-off: resolver N+1 risks; mitigate with dataloader and careful schema design.

• Response shaping (backend-tailored payloads)

  • Return minimal, widget-shaped payloads (e.g., summary + cache hints) so client can render skeletons quickly and lazy-load details.
  • Use delta fields or include "fastPreview" fragments to prioritize essential data.

• HTTP/2 multiplexing

  • Keep multiple parallel API calls inexpensive by using HTTP/2 so browser can multiplex requests on one TCP connection; helpful if endpoints remain separate.
  • Trade-off: initial connection setup and older client support; doesn’t reduce server CPU for many calls.

• Edge-aggregated APIs / CDN functions

  • Aggregate responses at edge (Cloudflare Workers / Lambda@Edge) to fan-in multiple backend calls and return a single combined payload close to user — reduces tail latency and saves client RTT.
  • Also enables near-user caching per-widget and per-user TTLs.

Practical approach

• Start with response shaping + GraphQL single query for implementational simplicity and client-driven needs.
• Add edge aggregation for tail-latency and caching-sensitive widgets.
• Use HTTP/2 as a fallback to keep parallel calls cheap.
• Measure: TTFP, Time-to-interactive, 95th percentile latency; iterate based on hotspots.

High-level goal
Target: Home page LCP ≤ 2.5s on 3G-fast/CPU mid-range device; SLO: 90th percentile users.

Concrete budget (numeric)

• Total JS bundle (initial critical JS) ≤ 150 KB gzipped
• Initial server payload (HTML) ≤ 25 KB gzipped
• Number of critical requests (blocking resources before LCP) ≤ 12
• Time to First Byte (TTFB) ≤ 200 ms (p50) / ≤ 500 ms (p95)
• LCP ≤ 2.5 s (p90)
• CLS ≤ 0.1 (p95)
• Max long task duration ≤ 200 ms (no tasks > 200 ms on main thread during first 5s)

Rationale
Budgets chosen to fit 2.5s LCP on mid-tier mobile; small HTML + minimal critical JS ensures render can start quickly; low request count reduces RTTs; short long-tasks keep main thread responsive.

Enforcement in CI

• Add a build-time performance check step:
  • Run Lighthouse (headless) and WebPageTest in deterministic emulation (3G-fast, CPU slowdowns) against the staging build.
  • Fail build if any numeric budget exceeded (use lighthouse-ci or psi).
  • Static checks: bundle-sizer/webpack-stats to ensure bundle gzipped ≤ 150 KB; HTML-size check.
• Store historical results and only block PRs when regressions exceed thresholds (e.g., +10% or absolute breach).

Handling false positives

• Use repeatable runs (3–5 runs) and compare median/p95 to avoid noisy single-run failures.
• If CI flags intermittent network/infra noise, auto-open a triage issue instead of failing immediately; require two consecutive CI failures to block merge.
• Provide a manual “review override” workflow with justification and remediation plan.
• Add synthetic lab checks + field metrics (RUM) to validate lab failures against real user data before broad rollbacks.

This balances strict, measurable budgets with pragmatic CI guardrails and human-in-the-loop validation to avoid blocking for noisy false positives.

High-level definitions

• Tree-shaking: static removal of unused exports from modules at bundle time (best with ES modules' static import/export). Result: smaller bundles, faster parse & JIT in V8.
• Code splitting: breaking app into chunks loaded on demand instead of one monolith bundle (reduces initial load).

When to prefer route-based vs component-level

• Prefer route-based when:
  • Initial render only needs a small set of routes (SPA) and you want fast Time-to-Interactive.
  • Chunks can map cleanly to navigation boundaries (simpler caching and predictable network requests).
• Prefer component-level when:
  • Large UI components are rarely used (e.g., modals, rich editors) regardless of route.
  • You need fine-grained parallel loading to avoid a single large chunk.

How modern bundlers help

• Webpack / Rollup / Vite
  • Use ES module analysis for tree-shaking and dead-code elimination.
  • Support dynamic import() to create lazy-loaded chunks for code splitting.
  • Produce sourcemaps, long-term hashing, and HTTP/2-friendly chunking.
  • Rollup excels at minimal output for libraries; Vite leverages native ESM during dev for instant HMR and builds with Rollup under the hood.
• Result: smaller, faster bundles that V8 can parse and JIT more efficiently.

Approach (goal): avoid FOIT by showing text quickly, but prevent large layout shifts by keeping fallback metrics close to the web font so layout doesn't jump when the web font loads.

Key techniques

• Preload the most-critical font files so the browser fetches them early.
• Use font-display: swap so fallback text shows immediately then swaps to web font.
• Use font subsets (e.g., latin-basic) to reduce preload size for initial render; lazy-load extended subsets.
• Prefer variable fonts to replace multiple static files (weights/styles) with one compressed file.

Example

<link rel="preload" href="/fonts/Inter-var.woff2" as="font" type="font/woff2" crossorigin>

@font-face{
  font-family: "InterVar";
  src: url("/fonts/Inter-var.woff2") format("woff2");
  font-weight: 100 900;
  font-style: normal;
  font-display: swap;
}
body { font-family: InterVar, system-ui, -apple-system, "Segoe UI", Roboto, sans-serif; }

Practical tips to reduce layout shift

• Match fallback metrics: choose a system fallback that approximates width/line-height; use font-size-adjust or CSS variable line-height to reduce reflow.
• Reserve vertical space: set consistent line-height and prevent FOUT-driven height changes.
• Use subsets for critical UI (nav, hero) and lazy-load full set for content-heavy pages.

Trade-offs

• System fonts: instant, zero download, minimal CLS, but limited branding & weight variety.
• Web fonts: better brand control and consistent rendering, but add payload and potential CLS if not tuned. Variable fonts + subsets + preload mitigate these costs.

When to pick what

• Content-heavy apps where brand consistency matters: web fonts with preload + swap + subsets.
• Performance-sensitive or localized UIs: prefer system fonts or only small subsets.

Definition — reflow (layout) vs repaint

• Reflow (layout): Browser recalculates positions and geometry of elements (width, height, positions) and may update layout tree and render tree. It's more expensive.
• Repaint: Browser recomputes styles like color, visibility, or background and paints pixels without changing geometry.

Examples that cause reflow (layout + paint)

1. Changing an element’s width/height (e.g., element.style.width = "300px") — affects geometry and siblings.
2. Modifying DOM structure that affects size (appendChild/innerHTML change adding elements).
3. Changing fonts or font-size (resolves new text metrics, shifts layout).

Examples that cause only repaint

1. Changing color or background-color (element.style.color = "red") — no geometry change.
2. Changing visibility that doesn't affect layout (using opacity or CSS transform translate) — repaints/compositing but not reflow.

Why minimize reflow for interactive UX

• Reflows are CPU-heavy and can block the main thread, causing jank, dropped frames, and slow response to user input. For snappy UI, batch DOM reads/writes, use transforms/opacity for animations, and use requestAnimationFrame or virtualize updates to reduce reflow frequency.