Frontend Architecture
Data fetching: multiple-choice review
Crux Multiple-choice synthesis across the data-fetching unit — fetch location, waterfalls, RSC streaming, the SWR cache, LCP, and multi-layer invalidation.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a call you make in a real perf review — not a definition to recite, but a tradeoff to weigh against an LCP budget and a stale-data risk.
Goal
Confirm you can connect fetch location, waterfalls, RSC streaming, the client cache, and multi-layer invalidation into one decision: which round-trips are on the critical path, and what each fix actually buys.
Quiz
Completed
A product page renders its title (the LCP element) from a client useEffect fetch. LCP is 2.9s. The team adds a loading skeleton and bumps the CDN cache TTL. LCP barely moves. What is the actual fix?
Heads-up fetchpriority is for resource discovery (images, fonts), not a JS-triggered API call. The title is gated behind bundle download and mount, which fetchpriority cannot touch.
Heads-up Caching the skeleton HTML changes nothing — the LCP element is the title, and it still waits for the client-side fetch after JS runs. CDN TTL on the shell does not collapse that chain.
Heads-up HTTP/3 trims a little handshake latency but leaves the sequential bundle-then-mount-then-fetch ordering intact. The win is server-side fetch, not a faster transport.
Quiz
Completed
A profile page fetches user (200ms), posts (300ms), and followers (150ms) — all independent — via three nested useEffect components. Total is ~650ms. Why, and what bounds it to ~300ms?
Heads-up The browser allows several concurrent connections per origin; the serialisation here is the React render cascade, not connection limits. Promise.all fires all three at once regardless.
Heads-up Nested useEffect fetches genuinely sum because each child cannot mount until its parent re-renders with data. 650ms is the real waterfall, not noise.
Heads-up staleTime governs refetch timing on revisits, not the first-paint waterfall. On a cold load there is nothing cached; the fetches still serialise.
Quiz
Completed
A team marks every component 'use client' in a Next.js App Router app, then complains RSC gave them no bundle win. What happened?
Heads-up RSC genuinely ships zero JS for server components — a real app can drop from ~240KB to ~60KB. The team defeated it by opting every component into the client.
Heads-up Streaming lowers TTFB, not bundle size. The bundle win comes purely from keeping non-interactive components on the server, which 'use client' everywhere prevents.
Heads-up Tree-shaking removes dead code, not legitimately-used interactive components. Every 'use client' leaf is real code the browser must run; that is why the bundle stayed large.
Quiz
Completed
An RSC page fetches data server-side, then a client component calls useQuery for the same data on mount — every page load does two round-trips for one dataset. What is the correct fix?
Heads-up The client component needs the query for post-mount interactivity (background revalidation, mutations). Dropping it loses that; the right move is to seed its cache, not delete it.
Heads-up staleTime=0 makes the client refetch immediately on mount — it guarantees the double fetch instead of preventing it. Dehydration is what removes the second trip.
Heads-up A cheap second fetch is still a second round-trip and still costs the client a request. The dual-fetch trap is fixed by sharing the server's already-fetched data via hydration, not by caching the duplicate.
Quiz
Completed
A search-as-you-type box fires a fetch per keystroke. The user types 'react' but sees results for 'reac'. None of the queries error. Root cause and best fix?
Heads-up The server returned correct results for each query it received; the bug is client-side — the slower 'reac' response landed last and clobbered the newer 'react' state.
Heads-up React batching affects re-render scheduling within a tick, not the arrival order of independent network responses. The race is between fetches, not within React's batcher.
Heads-up staleTime controls when cached data is refetched, not which of two in-flight responses wins. Only cancellation or queryKey versioning resolves the race.
Quiz
Completed
After a mutation updates a product, the server revalidates its cache but users still see the old price for several minutes. The Server Function called revalidateTag correctly. What was missed?
Heads-up revalidateTag works in Server Functions and did its job server-side. The stale data lived in the untouched client query cache, a separate layer.
Heads-up A short TTL would refresh sooner, not pin stale data for minutes. The persistent staleness is the client cache holding the old response under its own lifetime.
Heads-up The DB/Redis cache is invalidated by application code and is one layer here, but the symptom — old data only in the browser — points to the client library cache, which revalidateTag never reaches.
Recap
The through-line across the unit is one map of the critical path. Fetch location decides how many round-trips precede LCP — server fetch collapses them, client fetch after JS stacks them. Waterfalls re-serialise independent fetches through the render cascade; Promise.all and sibling RSC components cap them at the slowest. RSC ships zero JS only for components that stay server-side, and Suspense streaming buys a low TTFB. The client cache (SWR semantics, single-flight, optimistic snapshots) governs revisits and interactions, while AbortController kills races. And every mutation must invalidate every cache layer it touches — server revalidation alone leaves the browser stale.