Website Optimization Measures, Part XXIX

Published on Jan 21, 2025, filed under development (feed). (Share this on Mastodon or Bluesky?)

Moin and hola to part 29 of “Website Optimization Measures,” that article series in which I share improvements and lessons from the work on my personal projects, to allow you to pick what you think could benefit yours.

Deleting hundreds of files of browsable code and design samples. For my first one and a half O’Reilly books (Webdesign mit CSS and its second edition), I had provided a browsable archive of all the dozens of examples in the book. With the books being nearly 20 years old, receiving essentially no traffic anymore, this was something to clean up. As the code and design samples are still available for download as a ZIP archive, I now wonder why I didn’t do this 10 years ago.
Integrating view transitions! I’ve been aware of view transitions for some time, but it took John Allsopp and his “HTMHell” article, Smooth Multi-Page Experiences With Just a Few Lines of CSS, for me to make use of them, in their simplest form:
```
@view-transition {
  navigation: auto;
}
```
I’m still testing, and am open to feedback on the criticality of the reduced motion complement John had thought of, but I’m wondering about (as the effect is so subtle).
Removing remnants of Feature-Policy headers. When “Feature Policy” was announced back in 2018, I prepared for its use. For more years than I care to admit, I had the respective lines commented out in my domains’ main .htaccess configs. Eek. As eventually, this may all find a happy end with “Permission Policy,” I may add some modified config back, but for years, this has been dead code that I hence removed.
Improving handling of tables of contents. When randomly looking up something in Apple’s docs—something like this iPhone page—, I noticed how much clearer the “⊕” was in comparison to the “↲” I had been using to indicate TOCs on meiert.com pages. I tested whether the symbol would not look different on other devices (like, say, some arrows do), and when that was successful, switched to a similar handling. You can see for yourself, for example, on 8 AI Tips for Web Developers (and Their Careers).
Converting Eleventy configurations to ESM syntax. I have god-knows what kind of Eleventy setup, given how old some of the respective projects are. But seeing a great AI use case, I worked with GitHub Copilot and Cody to convert my .eleventy.js files into using ESM. It led to some hiccups, but nothing I couldn’t throw AI at, stack-overflow, or just think through.
Reviewing and cleaning up Eleventy plugins. As part of setting up the new meiert.com (which is to use Eleventy), I decided to generally inspect all .eleventy.js config files. There I noticed that for whatever “historical” reason, I had the Eleventy Navigation plugin included in all my Eleventy projects—without using it. Duh 😬
Testing back/forward cache. Not strictly an optimization measure, but I tested my main sites on whether b/f cache worked. It did ✅
Reworking lists into tables. For the longest time, Frontend Dogma used a simple ordered list to feature the many thousands of featured entries. But… a list is only so useful for scanning, and may at some point begin to represent tabular data when containing information of different types. Such was the case here. I took site feedback from a friend to rework how entries are being handled, and opted for a data table. I’m still tweaking, but believe it to already make scanning and accessing the information a lot easier.
Making more use of the :is pseudo-class. During said work on Frontend Dogma, I noticed selector repetition that was entirely avoidable using the :is pseudo-class. For example,
```
div.feature img,
div.feature a {
  display: block;
}
```
could readily be turned into
```
div.feature :is(img, a) {
  display: block;
}
```
More improvements, however, are always in grasp. Which is a good note to close this episode of the “website optimization measures” series with.

This is a part of an open article series. Check out some of the other posts!