Gems in the rough #5

More notes, notions, and nitpicks about managing one’s personal website.


Once more, let’s venture bravely into the miscellaneous info one gathers while tinkering with, and learning about, websites built by static site generators (SSGs) such as Eleventy and Hugo.

CSP: good, but gotchas

More often than I probably should, I run this site through to see what I can improve. I’m usually checking mainly for performance ratings, but recently I decided to see if I could improve the security score, which was typically poor. I soon learned that, yes, I could, but it would take some doing.

In the process, I learned about Mozilla Observatory, which is to security testing what Lighthouse is to performance testing. I followed Observatory’s guidelines and, gradually, was able to make big improvements in the site’s security score. Down the line, I may write a separate post about how to go about this; but, for now, I’ll just note that I had to make two key changes in order to have a strict content security policy (CSP):

  • Zero inline styling (e.g., style=) — I had purged most of it recently for other reasons, anyway; but, now, it’s all gone “and nothing of value was lost.”
  • No CSP-violating JavaScript — Once I had the CSP in place, I noticed it was unhappy with the Alpine JavaScript framework on which I’d begun basing the site’s navigation menu a few months back. As it turned out, the only workaround for the current version of Alpine would’ve been to loosen the CSP with an unsafe-eval setting. That earned a quick “Nope” from me. The result was a return to having a CSS-only nav menu, albeit a better one1 than I’d previously used.

It’s all about the cache

In recent months, I’ve issued two different posts (one about Hugo sites and one about Eleventy sites) explaining how you can use internal CSS — i.e., put all your CSS inside your HTML’s head section rather than having one or more separate external CSS files. Although I went that route with this site for a few weeks, I’ve now reverted to the external CSS approach because, unlike internal CSS, it takes full advantage of browser caching. As Google’s Sam Thorogood explained a few months ago in “Love your cache,” you should optimize for the second load.

The continuing PostCSS 8 saga

PostCSS is an amazing product that can give “CSS super-powers” to web developers. However, it’s also a house of cards, in the form of the hundreds (thousands?) of plugins it’s spawned; and it’s clearer by the month that many of those cards got shuffled rather nastily with last year’s update to PostCSS 8.

One of the most widely used PostCSS plugins is postcss-preset-env. It includes many capabilities which could otherwise require the use of numerous other plugins, but it remains broken in PostCSS 8. I’d been using postcss-preset-env mainly to do what one can get with two separate plugins, autoprefixer and postcss-nesting, so I’ve replaced it with those.2

Another PostCSS 8-incompatible plugin I had to replace is postcss-clean for minifying CSS output. Instead, I’m now using postcss-csso.3

Hugo’s problems continue

Here’s the latest on where the Hugo SSG stands regarding some shortcomings I mentioned in earlier articles:

While Hugo’s status as a single binary can be a good thing when one doesn’t want to deal with the many dependencies (as in the aforementioned PostCSS weirdness) required by most other popular SSGs, that also can suck in cases like these because the user, unable to “get under the hood,” has to wait for remedies from the Hugo dev team and the developers of various external packages on which Hugo relies.

  1. It’s based on a video tutorial by Angela Delise↩︎

  2. For the most part, my most recent use of postcss-preset-env was in some of my starter sets↩︎

  3. Since the site is Sass-based at this writing, I could just use Sass’s built-in minification if postcss-csso also becomes a problem, but the latter is more efficient. ↩︎