More often than I probably should, I run this site through webpagetest.org 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.”
unsafe-evalsetting. 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.
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.
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
Here’s the latest on where the Hugo SSG stands regarding some shortcomings I mentioned in earlier articles:
- No compatibility yet with the JIT mode in Tailwind CSS 2.1+.
- Not yet using Dart Sass, rather than the deprecated LibSass, for Sass/SCSS support.
- No fix yet to punctuation glitches in the goldmark parser Hugo uses to handle Markdown.
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.