Frontend Architecture
Data fetching: collapse the critical path
Reading about waterfalls is not the same as pulling a real LCP from 2.9s to under 1s. Build a page that fetches everything on the client in a waterfall, then apply the unit’s ladder — move LCP data server-side, parallelise the rest, stream the slow parts, cache the interactive ones — and prove each step with numbers from the Network panel and Lighthouse.
Turn the unit’s mental model into a reproducible engineering loop: measure the critical path, identify which round-trips precede LCP, relocate and parallelise the fetches that gate it, stream the slow tail, and verify the LCP and TTFB win with before/after measurements under the same throttling.
Take a product/profile page that client-fetches its LCP element through a waterfall and bring LCP under 1.5s and TTFB under 200ms — without changing the API or the data — by relocating, parallelising, and streaming the fetches, proving each step with measurements.
- A before/after table: LCP, TTFB, critical-path round-trip count, and client bundle size — all measured under the same throttling preset, not estimated.
- The Network panel after the fix shows the LCP content in the initial HTML/stream and no sequential staircase among the independent fetches.
- LCP is under 1.5s and TTFB under 200ms under the throttled profile, with the slow non-LCP section streaming in behind a Suspense fallback rather than blocking first paint.
- A one-paragraph write-up naming, for each fetch, where it now runs (server / streamed / client cache) and why — tied back to whether it gates LCP.
- Add hover/viewport prefetch for the most likely next navigation and measure the perceived-instant transition; note the mobile-bandwidth tradeoff and where you chose not to prefetch.
- Add an optimistic mutation (like / bookmark / add-to-cart) with the full onMutate snapshot + onError rollback + onSettled invalidate pattern, and force a server rejection to prove the rollback restores the real previous state.
- Add a search-as-you-type box and deliberately reproduce the out-of-order race, then fix it with AbortController (or queryKey cancellation) and show the latest query always wins.
- Wire coordinated multi-layer invalidation for a mutation: revalidateTag on the server plus queryClient.invalidateQueries on the client, and demonstrate that skipping the client step leaves the browser stale while the server is already correct.
This is the loop you will run in every real LCP incident: measure the critical path first, separate the round-trips that gate LCP from the ones that do not, move the LCP element’s data server-side, parallelise and stream the rest, and keep only genuinely interactive state on the client cache without re-fetching what the server already has. Then verify with before/after numbers under identical throttling. Doing it once on a toy page makes the production version — where the same waterfall costs real revenue — muscle memory.