CDN
Serve the files visitors need without making your application regenerate them. Put public assets on a delivery path designed for reuse.
Cache files that can be shared
Deliver public JavaScript, stylesheets, images, and other suitable static assets through the CDN. Reusing cached files reduces repeated work at the application origin. Choose cache behavior that matches how often the content changes, and use versioned asset names when a new deployment must refer to a new file instead of an older cached copy.
Keep personalized responses private
A public image and a signed-in account page should not have the same caching behavior. Dynamic and authenticated requests need handling that respects cookies, authorization, and cache directives. Keep user-specific responses out of shared caches, and treat any change to caching for an API or personalized page as an application behavior change worth checking.
Connect delivery to your releases
Ship related pages and assets together so the HTML for a release refers to files that actually exist. When changing a frontend, check older clients and cached pages as well as the latest page load. Object storage can supply public files, while private uploads keep their own access rules rather than becoming public because CDN delivery is enabled.
A little more detail
Questions about CDN?
Will Shipped cache my users’ account pages?
Private and dynamic responses should use uncached delivery unless you deliberately configure and verify a safe caching policy. Shared caching is intended for content that can be served to the relevant visitors without exposing someone else’s data.
Does a CDN replace my application server?
It can serve a static site’s files without a server rendering each request. A dynamic application still needs its web service for private logic and responses that must be generated at request time.
From your workspace to the web