Bundle Optimization — Series 3

Preview — 3 of 10 questions

A production build is 400KB larger than expected. How does a tool like rollup-plugin-visualizer (or Vite's built-in bundle analysis) help find the actual cause, versus guessing?

AIt doesn't help identify a specific cause — bundle size regressions can only be diagnosed by manually bisecting commits until the culprit is found

BIt automatically removes any dependency over a certain size threshold from the final bundle, without needing manual intervention

CIt generates a visual (typically a treemap) breakdown of exactly which modules — down to individual npm packages and even specific files within them — contribute how many bytes to each output chunk. Instead of guessing which recent change caused a size regression, this turns "the bundle got bigger" into a concrete, inspectable answer: which specific dependency (a moment-locale bundle pulled in by accident, an entire icon library imported instead of just the icons used, a debug-only library that leaked into a production dependency) is actually responsible, and by how much

DIt only works for CommonJS modules; ES module-based dependencies are invisible to bundle visualizers

What problem does this combination solve for a page using a custom web font?

javascript

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

AWithout font-display set (browser default behavior varies, but often blocks text rendering for a short period waiting for the custom font — a "flash of invisible text," FOIT), and without preload, the font file only starts downloading once the browser discovers the @font-face rule while parsing CSS, later than it could have. preload starts the font file downloading as early as possible, in parallel with other critical resources, and font-display: swap tells the browser to render text immediately in a fallback font rather than waiting, then swap to the custom font once it's ready — trading a brief, visible font swap for avoiding a period of invisible text altogether

Bpreload and font-display: swap together guarantee the custom font is always fully loaded before any text renders, eliminating any visible font change entirely

Cfont-display: swap disables the custom font entirely on slow connections, always falling back to a system font instead

Dpreload and font-display are mutually exclusive — combining them on the same font file is invalid and only the first one applies

How does this static HTML hint differ from a JavaScript-driven hover-prefetch approach for the same route?

javascript

<link rel="modulepreload" href="/assets/reports-a1b2c3.js" />

Amodulepreload downloads a chunk but deliberately skips parsing/compiling it, deferring that cost until the chunk is actually used — the exact opposite of a JS-driven prefetch, which does eagerly parse

Bmodulepreload only works for the application's main entry chunk — it cannot be used for a lazy-loaded route's own chunk

Cmodulepreload and a <script> tag are functionally identical; modulepreload is purely a legacy fallback for browsers that don't support ES modules

Dmodulepreload is a static hint declared directly in the HTML <head>, evaluated by the browser as early as the page's initial HTML parse — before any of the app's own JavaScript has even started executing. This means the hinted chunk can start fetching (and, being a module preload specifically, gets parsed/compiled ahead of time too, not just downloaded) earlier than a JS-driven approach (like the hover-triggered router.resolve() prefetch covered elsewhere) ever could, since that approach necessarily waits for the app's own code to run first and for a user interaction (a hover) to actually happen. The tradeoff is that a static HTML hint can't be conditional on runtime behavior the way a hover-triggered prefetch naturally is — it either always preloads that chunk, or it doesn't

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