I’ve since realized that Hugo’s architecture provides a variety of template optimization strategies. Hugo builds pages concurrently, so it might be hard to see on a modern device but before partialCaches or module mount trickery — there’s still the implicit complexity of the output/lookup model.

Generally the complexity cost of the default output formats are: page > term > taxonomy > section > home. Keeping expensive calls inside a section and/or a home template is usually optimal. i/o and maybe memory should be the only problems with lots of pages.

Hugo is a gateway for discovering neat golang libraries. Version 0.104.0 introduced a color extraction method that has lots of use–cases. An easy one is to generate basic image gradient placeholders. The browser has its own deferred/lazy loading logic so fancy image gradients (on a static site) require only a few lines of pre–generated CSS styles.

Reverse pagination is a counter–intuitive strategy for attempting to make links immutable/cacheable and bookmark friendly across older pages. I searched for a visual explanation (difficult to explain concisely) and eventually arrived at an old article on paging apis. Reverse pagination has its gotchas, but then again pagination itself is one big gotcha.. :-) Well, it depends on the use case really.

It’s kinda neat how CSS animation rules are sort of simple in their construction. imo, rules could be made even simpler if the animation-delay property also allowed delays between iterations/intervals instead of at the start only. Interval delays could allow for writing drastically less key frame rules.

text-animation[hang] {
  animation: tilt-rightward 1.3s infinite, tilt-leftward 1.8s infinite;
}