Web performance from the ground up

16 questions drawn from the parts of this series. Answers here count toward each post's own quiz.

1. Question 1 of 16·IntermediateLighthouse on your laptop shows a green LCP, but Search Console flags that URL group red on mobile. What should you trust and do?

   Trust Lighthouse because it measures under control, and ignore Search Console because its data is noisyTrust field data because Google ranks on it (the 75th percentile of real users), then use lab data to find the cause and test fixesTrust both equally and average themWait for CrUX to update because field data is only an estimate of lab data
2. Question 2 of 16·IntermediateA page has an LCP of 3.5s, of which TTFB takes 1.8s. You compress the hero image heavily but LCP barely changes. Why?

   Because AVIF and WebP cannot reduce image load timeBecause the hero image is not counted as the LCP elementBecause CLS adds extra time to LCPBecause the time is being lost in TTFB, not in resource load duration; split LCP into its four phases and fix the largest one, for example by caching HTML at the CDN
3. Question 3 of 16·IntermediateWhy is sizes needed with a w-descriptor srcset, and what happens without it?

   sizes controls compression quality; without it the browser picks the smallest imageThe browser picks the image before CSS and layout are computed, so it doesn't know the rendered width; without sizes it assumes 100vw and a small thumbnail still downloads the largest filesizes is required for the browser to support lazy loadingWithout sizes the srcset is ignored entirely and only src is used
4. Question 4 of 16·IntermediateThe hero image is the page's LCP element. Which setup is best?

   loading="lazy" so it doesn't compete for bandwidth with CSS and JSloading="lazy" with fetchpriority="high" to defer and prioritise at onceInject the image with JavaScript after load so it doesn't block renderingeager (default), fetchpriority="high", and the image present in the initial HTML
5. Question 5 of 16·StarterHow do FOIT and FOUT affect Core Web Vitals?

   FOIT causes CLS while FOUT slows LCPFOIT slows LCP because it hides text until the font loads, while FOUT shows text early but causes CLS when the font swap changes text sizeBoth only affect LCP, with no relation to CLSBoth only affect INP because they involve text rendering
6. Question 6 of 16·IntermediateWhy does the post treat font-display: swap and fallback metric overrides as a pair?

   Because swap makes fonts load faster so overrides reduce the loadBecause metric overrides are required for the browser to accept swapBecause swap hides text longer so overrides help text appear soonerBecause swap guarantees early text but the font swap shifts layout; metric overrides make the fallback occupy the same space as the web font so CLS nearly disappears
7. Question 7 of 16·StarterHow does Cache-Control: no-cache differ from no-store, and which do you usually want for HTML?

   no-cache means store nothing while no-store means store but always revalidate; HTML uses no-storeno-cache still stores but must revalidate with the server on every use (usually a cheap 304); no-store is what means don't store anywhere. Public HTML usually suits no-cacheThey are the same, only named differently across browsersno-cache only applies to CDNs while no-store only applies to browsers
8. Question 8 of 16·IntermediateHow does the "short-lived HTML, long-lived hashed assets" strategy work, and why keep assets from a few previous deploys?

   HTML is the map pointing at assets so it is always fresh; filenames change with content so immutable caching is safe. Users with an old tab still point at old chunks, and deleting them immediately causes chunk load errorsHashed assets never need to be kept because the browser fetches new ones on deployHTML is cached long to reduce server load while assets use no-cache to stay freshThe hash in the filename is only for debugging and does not affect caching
9. Question 9 of 16·StarterIf you can do only one code-splitting step first, where should you split and why?

   Every small component, since more chunks are always betterOnly third-party libraries, since app code is always smallBy route, because pages the user has not opened should not be in the initial bundle, and it is the easiest big winOnly modals, since modals are always the heaviest
10. Question 10 of 16·IntermediateIn the lazy Modal example, why render {showModal && <Suspense>...<Modal/></Suspense>} instead of always rendering <Modal> and hiding it with CSS?

    Because Suspense only works conditionallyBecause the chunk loads only when the component is first actually rendered; conditional rendering means the modal code is not fetched until opened, while Suspense provides a fallback while waitingBecause CSS cannot hide a React componentBecause React.lazy always loads on import, so a condition is needed to block it
11. Question 11 of 16·StarterA parent component re-renders but the props passed to the child, <Child label="abc" />, are unchanged. Does the child re-render?

    No, because React always compares props before renderingNo, because the label string is identical so React skips itYes, because by default when a parent renders all children render too; only with React.memo does React compare props to skipOnly if the child has its own state
12. Question 12 of 16·IntermediateTyping in a search box re-renders the whole dashboard (with a heavy chart) because the state lives at page level. According to the post, which fix comes first?

    Move the state into its own SearchBox component (colocation) or pass the heavy part through children, and only then consider memo if still neededWrap every child in React.memo and every function in useCallbackMove the state into Context so every component can read itDebounce the search box with setTimeout to reduce the number of keystrokes
13. Question 13 of 16·AdvancedIn a variable-height virtual list, a row above the viewport has just been measured and is 80px taller than estimated. If nothing is done, what happens and how is it fixed?

    The content the user is reading is pushed down 80px though they did nothing; fix by adding exactly the delta to scrollTop in useLayoutEffect, before paintThe scrollbar locks and can no longer scroll; fix by resetting scrollTop to 0Content stays put so nothing is needed, because the browser compensates via overflow-anchorRows below get unmounted; fix by raising overscan by 80px
14. Question 14 of 16·IntermediateA user Tabs onto a menu button in one row, then scrolls far away. What happens in a naive virtual list and how is it handled?

    Focus moves to the nearest row automatically; nothing is neededThe row is hidden with CSS but keeps focus; just add aria-hiddenThe browser blocks scrolling while any element has focusThe row is unmounted so focus falls to body and the next Tab returns to the top of the page; always render the focused row or use roving tabindex
15. Question 15 of 16·IntermediateA button handler sets spinner.hidden = false, filters 200,000 rows synchronously for 400ms, then sets spinner.hidden = true. Why does the spinner never appear?

    Because changes to hidden do not take effect until the function ends and React commits.Because DOM changes only reach the screen in the render step, which must wait for the running task to finish, by which time the spinner is hidden again.Because the browser ignores all DOM updates inside an event handler.Because microtasks always run first and overwrite the spinner's state.
16. Question 16 of 16·IntermediateA loop processes 100,000 items and calls await Promise.resolve() after each one to "avoid blocking the UI". What happens?

    The UI stays smooth because each await hands control back to the browser.The UI is smooth but processing becomes noticeably slower.The UI still freezes, because the continuation after await is a microtask and they all run in the same microtask checkpoint, so the browser does not render or handle input between them.The UI freezes only for the first frame and then becomes smooth.