polarathene
commented
3 years ago Are you open towards replacing Apache with this transition as well?
With Caddy you get common mime types by default when enabling gzip/brotli, all you need is one line: encode zstd gzip. That will compress on the fly, if your static assets are pre-compressed, you can also serve those without on-demand compression overhead:
# The domain name you want to handle responding to requests from, implicit LetsEncrypt + redirect setup.
rockstor.com {
# Make the root of the website map to `/srv/site` on server filesystem:
root * /srv/site
# If the requested file has a file with a compressed extension, use that instead:
file_server {
precompressed zstd br gzip
}
# Otherwise if suitable, compress the asset on-demand:
encode zstd gzip
# Add cache-control for any static assets in the `rockstor.com/assets/static` directory:
# `/srv/site/assets/static` on the server in this case.
header /assets/static/* Cache-Control max-age=31536000
}You could also change the static assets location to be static.rockstor.com/ for example, the config is pretty easy to work with and flexible. That above example will automatically provide HTTPS cert provision and renewal with LetsEncrypt and setup the HTTP to HTTPS redirect by default.
I understand if you're more comfortable with Apache and rather manage such config more explicitly/verbosely though.
The caching concerns can generally be handled by a build tool importing your assets and using a content hash for the filename on the build output, thus the name itself always matches the intended content and can be cached indefinitely (or some other long duration) without concern.
This doesn't appear to be something Hugo supports at a quick glance? (or the documentation isn't particularly clear about it)
If that's not an option, a post process could probably be run to generate the content hashes and replace the original file names from the build output as a workaround if this approach was desirable.
I think Hugo is offering something similar via the assets directory and using their Permalink method. I have read of it being a bit of an issue in the past (possibly before Hugo Pipelines) due to JS/CSS processing, with others setting up Webpack and configuring that to provide the feature for Hugo. I haven't tried a basic Hugo hello world to see if that's been resolved since to simplify it. I do know there's various examples of using the integrity attribute, or query strings for cache busting (which can have some gotchas).
phillxnet
Note the following was based on a test performed prior to our move to https. Some factors may have changed but copying in here from our prior closed repo to keep a note of this performance orentated test facility.
Note also that we are likely to gain some sanity / speed from completing the following issue in this repo: Migrate to Hugo #1 So we may be better off returning to this issue once we are Hugo generated.
Apparently we are a little behind the times: From a quick test we have have a couple of easy speed-ups: https://gtmetrix.com/enable-gzip-compression.html In .htaccess
Potential issues, we also serve Rock-ons and older CentOS base repos from this domain.
And: https://gtmetrix.com/leverage-browser-caching.html
again in .htaccess
and: