Asset Optimization and Caching

I have read various postings about your caching and about asset optimization, but am still a little confused about the best way to handle it. I create simple, low traffic Bootstrap sites, and I don’t use a CMS or program like Gatsby or Hugo. I instead use a website builder such as Bootstrap Studio and Mobirise. An example site is .

I only update each site a few times a month at most, and the images (which are loaded using relative path name) rarely change. Do I need to do anything to make it so your system caches the assets? I know your CDN does not really cache long term like a traditional CDN does, but your headers seem to accomplish that same goal. But when I view the source code for my site in my browser, I don’t see that you added any caching headers?

Also, for sites like mine, is there any reason not to use your Asset Optimization?

My overall goal is to cache as much as possible so I don’t go over the Netlify bandwidth limit.

Hiya @impulsecorp and welcome to our community!

For non-optimized assets, we do cache your assets between deploys, and we instruct browsers to use their cached copies. Some of the dumber “site testing” tools do not recognize our caching strategy as valid, but it does work - allows browsers to use their cache (after verifying it is up to date with a smaller web request), but allows instant rollbacks and atomic deploys.

If you use our asset optimization, something totally different happens. We will:

  1. create asset-fingerprinted filenames for the resources
  2. upload them to cloudfront (rather than serving from our CDN) under those names
  3. upload them to our CDN under the original names (so if you hotlink from an external source to your site - you’ll get the non-optimized, normal-caching-behavior-described-above version)
  4. rewrite your html/js/css to point to those optimized assets
  5. serve those assets with a year-long cache timeout that even the dumber performance tools believe we are caching effectively.

The optimized assets will present a slightly improved bandwidth profile for you since the browser doesn’t “check in” to ensure freshness - if the checksum of an asset changes, we make a new copy of it under a new name.

But in the end, we’ll still be sending the traffic as long as the browser doesn’t have it, and we won’t be sending it if the browser already has it up to date either way (optimized or no).

1 Like

Thanks, that explains it. The only other thing I want to make sure of, which if I understood correctly from another posting I read on this community, is that no matter how I configure it, your CloudFront upload (or your own CDN) is not really caching my page the same way as if I used a CDN directly. What I mean is that if I upload my 1 page site directly to a CDN (such as CloudFront) and never edit the site again, it will cache that page (and related assets) on each POP. So if the CDN had 30 POPs and my site gets 100,000 visits in a month, I would only be charged for around 30 page loads of bandwidth instead of 100,000. But, with your system, assuming all 100,000 visits are from different (new) users, I would get charged for the bandwidth of all 100,000 page loads. Is that correct?

I currently use BunnyCDN for the images on one of my sites (not on Netlify), but it has 5000 images and each user only looks at a few of them, so the cache hit rate is only 35%.

Hi, @impulsecorp, you are correct that we calculate data transfer as the data sent from each CDN node to each enduser’s browser. If 100k different people/browsers visit the site there would be data transfer added for all 100k visitors.

If there are other questions about this, we’ll be happy to answer.

If I were to upgrade to your Enterprise version, to use the High-Performance Edge CDN, would it still work that way?

hi @impulsecorp, the general philosophy is the same yes. Would you like to speak with someone who can tell you more about the benefits of the high performance edge cdn?

Thanks, but Shafali Raj from your company already emailed me about it.

1 Like

fantastic! I’m glad to hear.