As our caches pull new content from your origin once a request is made for the object, there isn’t a sure-fire way of guaranteeing the caches are warmed up beforehand.
One thing we do generally recommend is to set up shielding. A shield PoP serves as the “source of truth” for the rest of the network PoPs, so that when any other PoP has a cache-miss, it gets directed to your shield. All edge PoPs will attempt to retrieve the object from the shield PoP first before trying your backend, thus optimizing requests to your origin. It’s also a good way to refill the cache a little faster after a purge all. So while it won’t “pre-warm” up the caches per se, it will help with requests made to origin.
Also, utilizing a new feature called soft purge might be helpful. With soft purge, objects that are purged by their URL or by a Key associated with them are still available to be served to the client while the new version is being fetched from the origin. In essence, objects purged with soft purge are treated as stale and can be used as fallback in the case of backend failures. Again, it won’t directly address the issue of cache warming, but it will ensure an object lives in cache while a new object is being pulled in. The following document and table provides more details:
In conjunction with soft purge, setting up serving stale (a cached response that has not been revalidated with the origin for longer than the max-age time that was specified for it), especially
stale-while-revalidate, can be useful in the following two situations:
- to provide a graceful fallback while weathering temporary origin problems
- to avoid the wait that some client requests incur each time the object expires and needs to be refreshed