Suggestions from gtmetrix.com

[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

<IfModule mod_deflate.c>
  # Compress HTML, CSS, JavaScript, Text, XML and fonts
  AddOutputFilterByType DEFLATE application/javascript
  AddOutputFilterByType DEFLATE application/rss+xml
  AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
  AddOutputFilterByType DEFLATE application/x-font
  AddOutputFilterByType DEFLATE application/x-font-opentype
  AddOutputFilterByType DEFLATE application/x-font-otf
  AddOutputFilterByType DEFLATE application/x-font-truetype
  AddOutputFilterByType DEFLATE application/x-font-ttf
  AddOutputFilterByType DEFLATE application/x-javascript
  AddOutputFilterByType DEFLATE application/xhtml+xml
  AddOutputFilterByType DEFLATE application/xml
  AddOutputFilterByType DEFLATE font/opentype
  AddOutputFilterByType DEFLATE font/otf
  AddOutputFilterByType DEFLATE font/ttf
  AddOutputFilterByType DEFLATE image/svg+xml
  AddOutputFilterByType DEFLATE image/x-icon
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/javascript
  AddOutputFilterByType DEFLATE text/plain
  AddOutputFilterByType DEFLATE text/xml

  # Remove browser bugs (only needed for really old browsers)
  BrowserMatch ^Mozilla/4 gzip-only-text/html
  BrowserMatch ^Mozilla/4\.0[678] no-gzip
  BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
  Header append Vary User-Agent
</IfModule>

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

<IfModule mod_expires.c>
  ExpiresActive On

  # Images
  ExpiresByType image/jpeg "access plus 1 year"
  ExpiresByType image/gif "access plus 1 year"
  ExpiresByType image/png "access plus 1 year"
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/svg+xml "access plus 1 year"
  ExpiresByType image/x-icon "access plus 1 year"

  # Video
  ExpiresByType video/mp4 "access plus 1 year"
  ExpiresByType video/mpeg "access plus 1 year"

  # CSS, JavaScript
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType text/javascript "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"

  # Others
  ExpiresByType application/pdf "access plus 1 month"
  ExpiresByType application/x-shockwave-flash "access plus 1 month"
</IfModule>

"Depending on your website's files you can set different expiry times. If certain types of files are updated more frequently, you would set an earlier expiry time on them (ie. css files)"

and:

Recommendations
Be aggressive with your caching for all static resources
Expiry at a minimum of one month (recommended: access plus 1 year)
Don't set your caching more than a year in advance!
Be careful
You want to be careful when enabling browser caching as if you set the parameters too long on certain files, users might not be getting the fresh version of your website after updates.

[polarathene]

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]

@polarathene Hello again. And thanks for all your pointer here.
Re:

Are you open towards replacing Apache with this transition as well?

Unfortunately, given your efforts here on the Caddy front, No. For a variety of reasons Apache is our go-to currently and as-is we have everything working, if not optimised.

I understand if you're more comfortable with Apache and rather manage such config more explicitly/verbosely though.

This is definitely an element of our continued use as it servers all our needs so I'm keen on the not fixing what isn't broken approach. Given that all non trivial software is at least broken in some way or another. But in this case Apache is an at least semi known quantity and we can leverage the the time/effort we have already invested in it's config.

Your pointers/investigations re Hugo are interesting. We arn't really a major traffic site so I'm mostly interested in keeping things simple but not slow if we can help it. Currently we are way under-optimised and I copied this issue in from ages ago when this repo was private and post a bunch of clean-ups we did prior to the publishing. Such as the removal of some early google analytics etc. Another element here is that our images in this repo have been somewhat scaled down from the currently in-play ones on the production website but bar that it's pretty much what is 'live' currently.

I'm not that familiar with Hugo myself just yet but it's intended use was primarily to ease contributions and translations and dig us out of the mess that we currently have; while maintaining our existing urls if possible.

Thanks again for your input here, much appreciated. We have to try not to be too ambitious re optimization but I did want to pop in what we have already. Plus these tests were carried out prior to our now complete https transition so at least we have that one (mostly) sorted. Bar the mixed content issue of course: