Webpack Caching Strategies (Contenthash, Long-Term Caching) Quiz Quiz

Challenge your knowledge of webpack caching strategies, including the use of contenthash and best practices for achieving long-term caching efficiency in modern web development. This quiz covers key concepts, benefits, configuration pitfalls, and advanced approaches to optimizing your build output for improved cache management.

  1. Purpose of Contenthash

    When configuring webpack output filenames, why is using the [contenthash] in filenames preferred for long-term caching, such as output.[contenthash].js?

    1. It allows merging multiple CSS files into a single output file.
    2. It reduces the size of the generated files significantly.
    3. It ensures files are only re-downloaded when their content changes.
    4. It avoids loading images until fonts have finished downloading.

    Explanation: Using [contenthash] in filenames produces unique names based solely on the content, so browsers only download new files when their content actually changes. This supports highly efficient client-side caching and avoids unnecessary downloads. Reducing file size is unrelated to filename hashes. Delaying asset loads or merging CSS files are different concerns not addressed by contenthash.

  2. Impact of Caching on Vendor Bundles

    If your webpack build produces a separate vendor.js bundle containing dependencies, how does effective long-term caching affect this file during small application code updates?

    1. Vendor.js will be merged with the main bundle to reduce HTTP requests.
    2. Vendor.js will be ignored by browsers if main.js changes.
    3. Vendor.js is likely to be served from cache unless dependencies themselves are updated.
    4. Vendor.js will always be replaced with a new version, even for app-only changes.

    Explanation: When vendor bundles are split out with their own hash, they remain unchanged and cached as long as their content (the dependencies) doesn't change. This enables efficient re-use by browsers. The other options either describe incorrect caching outcomes, merging unrelated to caching, or inaccurate browser behavior.

  3. Cache Busting Techniques

    Which strategy can help guarantee users receive updated assets when a bug fix is deployed to production without relying on users refreshing their browser cache?

    1. Combining all scripts into a single script without hashing.
    2. Renaming assets arbitrarily with each deployment.
    3. Including a unique contenthash in the output asset filenames.
    4. Keeping filenames static and only manually invalidating caches.

    Explanation: Using contenthash ensures changed files get a new name, so browsers naturally fetch the latest versions without manual intervention. Combining scripts without hashes makes cache invalidation harder. Static filenames or arbitrary renaming do not reliably connect the filename with the file's content changes, leading to poor cache management.

  4. Potential Pitfalls in Caching Setup

    Suppose your webpack configuration uses [hash] instead of [contenthash] in filenames; what is a likely negative result for end users in terms of cache efficiency?

    1. Browsers will refuse to store any files in the cache.
    2. All output files may be re-downloaded even if only one file changes.
    3. Binary files will not load due to MIME type errors.
    4. Assets will be stored forever, never updating under any circumstance.

    Explanation: Using [hash] applies a build-wide hash, so any change to any file results in all files getting a new name and being re-downloaded, impacting cache efficiency. MIME type errors, cache refusal, or perpetual cache without updates are not direct consequences of using [hash] instead of [contenthash].

  5. Optimizing Caching for CSS Assets

    Why is it important to use separate contenthashes for JavaScript and extracted CSS files when aiming for optimal long-term caching?

    1. It prevents CSS from being loaded before fonts.
    2. It ensures all files use the same contenthash, improving download speed.
    3. It combines CSS and JS into a single output for simpler caching.
    4. It allows browsers to cache unchanged CSS independently from script updates.

    Explanation: Separate contenthashes mean changes in JavaScript do not force browsers to reload cached CSS, and vice versa, thus maximizing cache effectiveness. Preventing asset loading order, enforcing same hash for all files, or combining CSS and JS are unrelated or incorrect, and could actually hurt caching or proper application function.