Website Optimization Measures, Part XXXIX

Published on Aug 25, 2026, filed under development, optimization. (Share this post, e.g., on Mastodon.)

Welcome to a brand-new edition of a series in which I share improvements and lessons from the work on my projects—for the benefit of yours:

Refactoring package.json files. With an increasing number of public packages as well as private Node projects, project consistency has been diverging. One inconsistency I noticed was that some packages used the files field to determine what went into the published package, and others used .npmignore. I decided to use the files field going forward. (The update included more consistency-related changes, but none as “exciting” as this one.)
Removing Eleventy config defaults. During my move away from Astro (when I migrated IA Defensa to Eleventy), I used the opportunity to throw an LLM at all my Eleventy configs. Eventually, this exposed a few config options where I had explicitly set defaults—which I might have never changed. I cleaned them up across projects.
Deduplicating CSS after minification. I recommend reading CSS: How to Optimize Your CSS Optimization for details—which is not live at the time of this writing and makes me curious who may follow up on this 😅 (Read this just as me being eager to get this post out—the linked article depends on yet another article, coming up on CSS-Tricks. Both are 3-6 weeks away.)
Reviewing and optimizing Eleventy project performance. This is also half-baked as I took the note without expanding. From memory, this was about testing Fable to review the Eleventy setup of Frontend Dogma—which led to actually digging into the Eleventy core, achieving a 60+ seconds (!) build-time improvement and pinning that improvement via patch-package locally, then submitting #4332 to Eleventy (as one of two culprits, the other already being fixed in Eleventy 4). The moral here? Fable is good (but expensive!) and LLMs are absolutely a great optimization helper.
Qualifying RedirectMatch-based redirects. Especially when entire folders were renamed or moved, but also to catch popular 404 errors, I use RedirectMatch directives, like such:
```
RedirectMatch 301 /old/(.*) https://example.com/new/$1/
RedirectMatch 301 /error_dir/(.*) https://example.com/
```
This has one catch: It would redirect anything with “/old/” (or “/error_dir/”) in it, when the intent is to capture what starts with “/old/”. The fix is adding a start-of-string anchor (^), as shown in this WebGlossary.info example where term redirects now need to start with /r/:
```
RedirectMatch 301 ^/r/(.*) https://webglossary.info/terms/$1/
```
Optimizing GitHub Actions (to reduce their ecological footprint and to avoid reaching quotas). GitHub Actions are free to some extent, but eventually one can hit quotas, and all of the work costs energy. I used Fable to review 33 workflows across 22 of my projects to optimize these actions, cutting down unneeded runs where possible. While I cannot quantify the exact savings, from the number of runs removed these are substantial—and the setup feels more sustainable and more economic.
Removing unneeded RewriteBase / directives. Running into a 2004 (!) comment about RewriteBase (whose rationale may not be accurate though?), I went through my Apache-based projects to check on this directive. Except for two WordPress-generated blocks and one article mention, this didn’t appear anywhere (anymore), but I updated the respective occurrences.
Optimizing Git. On (ultimately unnecessarily) trying to determine SSD wear, something fell out of the investigation that led to more Git optimization: setting untrackedCache (git config --global core.untrackedCache true) and writeCommitGraph (git config --global fetch.writeCommitGraph true). I don’t care so much as to dive in deep, but understand this improves the setup.
Changing GitHub and GitLab issue links. I’m sure you know the GitHub issue tracker and its “new” prompt, following the form https://github.com/USER/PROJECT/issues/new. For the longest time I didn’t realize (for perhaps never checked) that new requires users to be logged in, whereas just going to issues is, in public repos, open. That makes sense—but to me, it changes the whole dynamic of when to link to those new prompts directly. I stopped doing so and updated my projects for two reasons: 1) That login prompt is likely ruining all chances of getting any feedback. 2) Pointing to the issue tracker instead comes with the benefit of suggesting to check if an issue was already reported. Interested users can then still file an issue (and log in or register, if desired).

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

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m an engineering lead, guerrilla philosopher, and indie publisher. I’ve worked as a technical lead and engineering manager at various companies (e.g., Google); I’m an active web and tool developer (code optimization, digital defense), a contributor to web standards (like HTML, CSS, WCAG), and a book author (O’Reilly, Frontend Dogma).

I love trying things—in web development and engineering management, but also in politics and philosophy, where I hold to one idea in particular: that we can only be well if we take good care of everyone. Here on meiert.com I talk about some of my perspectives and experiences. (Interpret charitably but be critical—and share feedback and advice that makes my work better.)