# Cascading Cache Invalidation

DevFeed: [Cascading Cache Invalidation](<https://devfeed.tech/articles/cascading-cache-invalidation-29492.md>)

Original publisher: [Read original article](<https://philipwalton.com/articles/cascading-cache-invalidation/>)

Published: 2019-10-09T08:26:44Z

Content type: article

Language: en

Sources: [Philip Walton](<https://devfeed.tech/sources/philip-walton.md>)

Topics: [Caching](<https://devfeed.tech/topics/caching.md>), [JavaScript](<https://devfeed.tech/topics/javascript.md>), [Web Development](<https://devfeed.tech/topics/web-development.md>)

Tags: [cache](<https://devfeed.tech/tags/cache.md>), [caching](<https://devfeed.tech/tags/caching.md>), [code-splitting](<https://devfeed.tech/tags/code-splitting.md>), [dependencies](<https://devfeed.tech/tags/dependencies.md>), [hash](<https://devfeed.tech/tags/hash.md>), [javascript](<https://devfeed.tech/tags/javascript.md>), [production](<https://devfeed.tech/tags/production.md>)

## AI overview

The article examines how revision-hashed JavaScript filenames interact with code splitting and dependency imports. It finds that changing a vendor chunk can alter its filename, forcing importing chunks to change as well and reducing the effectiveness of long-term caching.

## Source excerpt

For several years now, pretty much every article published on caching best practices has recommended the following two things for deploying JavaScript code in production: Add revision information to the filenames of your assets (usually content hashes)