Weekly curated resources for designers — thinkers and makers.

Amouage, the Omani House of High Perfumery, expands its global presence with its first Asian flagship in Zhang Yuan, Shanghai’s...

This is a note to my future self, as I’ve setup HTML minification on a few different projects and each time I ask myself, “How did I do that again?” So here’s your guide, future Jim (and anyone else on the internet who finds this). I use html-minifier to minifiy HTML files created by my static site generator. Personally, I use the CLI tool because it's easy to add a CLI command as an npm postbuild step. Example package.json: { "scripts": { "build": "<BUILD-COMMAND>" "postbuild": "html-minifier --input-dir <BUILD-DIR> --output-dir <BUILD-DIR> --file-ext html <OPTIONS>" } } All the minification options are off by default, so you have to turn them on one-by-one (HTML minfication is a tricky concern). Me personally, I’m using the ones exemplified in the project README: --collapse-whitespace --remove-comments --remove-optional-tags --remove-redundant-attributes --remove-script-type-attributes --remove-tag-whitespace --use-short-doctype --minify-css true --minify-js true So, for a site folder named build, the entire command looks like this: html-minifier --input-dir ./build --output-dir ./build --file-ext html --collapse-whitespace --remove-comments --remove-optional-tags --remove-redundant-attributes --remove-script-type-attributes --remove-tag-whitespace --use-short-doctype --minify-css true --minify-js true That’s it — that’s the template. What Kind of Results Do I Get? I use this on a few of my sites, including my notes site and this blog. When testing it locally for my blog’s build, I: Run a build and put files to ./build Copy ./build to ./build-min Command: cp -R build build-min Run html-minifier on build-min and compare the resulting folders in macOS finder. Here’s my results for my blog (2,501 items in ./build): Directory size: Before: 37MB After: 28.4MB Difference: ▼ -8.6MB (-23.24%) Main index.html file lines of code: Before: 1,484 After: 15 lines Difference: ▼ -1,469 lines (-99%) Main index.html file size over the network: Before: 30.6kB After: 17.6kB Difference: ▼ -13kB (-42.48%) And the results for my notes (one big index.html file): File size: Before: 1.5MB After: 1.1MB Difference: ▼ -0.4MB (-26.67%) Lines of code: Before: 25,974 After: 1 Difference: ▼ -25,973 lines (-99.996%) Email :: Mastodon :: Bluesky #html

Meaningful design decisions flow from clear intent, not from data. “We don’t know what people want. We don’t even know what they do.” This confession — which so many clients never truly say but should — drives an almost compulsive need for testing and validation. Heat maps, A/B tests, user surveys — we’ve built an entire industry around the promise that enough data can bridge the gap between uncertainty and understanding. But here’s what testing actually tells us: what users do in artificial scenarios. It doesn’t tell us what they want, and it certainly doesn’t tell us what we should want them to do. We’ve confused observation with insight. A heat map might show where users click, but it won’t reveal why they click there or whether those clicks align with your business objectives. User testing might reveal pain points in your interface, but it won’t tell you if solving those pain points serves your strategic goals. The uncomfortable truth is that meaningful design decisions flow from clear intent, not from data. If you know exactly what outcome you want to achieve, you can design toward that outcome without needing to validate every decision with testing. This isn’t an argument against testing entirely. It’s an argument for testing with purpose. Before running any test, ask yourself: Do you have the intent to act on what you find? Do you have the means to act on what you find? If the answer to either question is no, you’re not testing for insight — you’re testing for comfort. You’re seeking permission to make decisions you should be making based on clear strategic intent. The most successful digital products weren’t built by following heat maps. They were built by teams with crystal-clear visions of what they wanted users to achieve. Testing can refine the path to that vision, but it can’t replace the vision itself.