Performance Expert

Preview — 3 of 10 questions

How does the React Compiler determine what to memoize?

javascript

// Source code:
function ProductList({ products, onBuy }) {
  const discounted = products.filter(p => p.discount > 0);
  return discounted.map(p => <ProductCard key={p.id} product={p} onBuy={onBuy} />);
}

// Compiler output (simplified conceptual):
function ProductList({ products, onBuy }) {
  const $ = useMemoCache(3);
  let t0;
  if ($[0] !== products || $[1] !== onBuy) {
    const discounted = products.filter(p => p.discount > 0);
    t0 = discounted.map(p => <ProductCard key={p.id} product={p} onBuy={onBuy} />);
    $[0] = products; $[1] = onBuy; $[2] = t0;
  } else {
    t0 = $[2];
  }
  return t0;
}

AReact Compiler memoizes every variable in every component

BReact Compiler only works when all dependencies are TypeScript types

CReact Compiler performs static analysis to identify which values and JSX outputs depend on which inputs — it inserts fine-grained caching only where re-computation would be expensive or affect referential equality

DThe compiler replaces the React runtime entirely

How does React prioritize work?

javascript

// React's internal priority lanes (simplified):
const SyncLane         = 0b0000000000000000000000000000001; // highest
const InputContinuousLane = 0b0000000000000000000000000000100;
const DefaultLane      = 0b0000000000000000000000000010000;
const TransitionLane1  = 0b0000000000000000000001000000000; // startTransition
const IdleLane         = 0b0100000000000000000000000000000; // lowest

// Work loop:
function workLoopConcurrent() {
  while (workInProgress !== null && !shouldYield()) {
    performUnitOfWork(workInProgress);
  }
  // shouldYield() = true when scheduler needs to yield to browser
}

AReact processes all state updates in the order they were received

BAll state updates have identical priority in React 18

CReact's scheduler is the same as the browser's requestIdleCallback

DReact uses a lane-based priority system — sync lane (direct DOM mutations, flushSync) never yields; input events have high priority; transitions are interruptible and yield to higher-priority work

What problem does Partial Prerendering solve?

javascript

// PPR (Next.js 15+) — static shell + dynamic holes:
export default function ProductPage({ params }) {
  return (
    <div>
      {/* Static shell — generated at BUILD TIME */}
      <Header />
      <ProductDescription productId={params.id} />  {/* static */}

      {/* Dynamic hole — rendered at REQUEST TIME */}
      <Suspense fallback={<PriceSkeleton />}>
        <DynamicPrice productId={params.id} />       {/* varies by user/time */}
      </Suspense>

      <Suspense fallback={<ReviewsSkeleton />}>
        <PersonalizedRecommendations userId={userId} />  {/* user-specific */}
      </Suspense>
    </div>
  );
}

APPR is the same as traditional static site generation (SSG)

BPPR only works with client-side navigation

CPPR requires all components to be client components

DPPR pre-renders the static shell at build time (CDN-cacheable, instant TTFB) while keeping Suspense-bounded dynamic sections as server-rendered holes that stream on request — combining SSG speed with SSR dynamism

Answer all 10 questions (7 more), see explanations for every answer, and track your score.