Yup - when we optimize, we move to cloudfront, which won’t match your domain name. For most folks’ sites this isn’t a big deal, but clearly your settings are special. I use hugo with optimization myself and it’s no problem, but I use a BaseURL of / and presumably some other settings are different as well.
At any rate, since we won’t be changing how we process assets in the foreseeable future, you’ll want to not use our asset optimization in case you have strict requirements about URL’s. There is no version of our processing intended or available today that does NOT rewrite to cloudfront. If you’re trying to turn it off please make sure that “disable processing” is checked, rather than just unchecking the other boxes in that asset optimization section of our UI. Those are different - we’ll still rewrite some URL’s if you don’t completely disable our optimization!
Nothing we do is very fancy, you could do it yourself easily using npm modules that are potentially better than the ones we use. The workflow we use is something like this:
- take an asset fingerprinted name for the file, deploy it with very long cache timeouts (1 year). IF the asset changes, so will the path, so the long cache is ok despite our general advice not to monkey with cache timeouts
- bundle CSS and JS appropriately (we make one bundle per “set” of files included in any other file - so it’s not “one bundle for all” but “commons.js + styles.js for most pages, commons.js+styles.js+special-for-one-page.js for the one-page, and no bundle if there is only one JS file used”)
- if you want Pretty URL’s, we create redirects from /page/index.html to /page/ and also rewrite the referring html, js, and css to point to /page/ directly (in case you had links to /page/index.html)