Issue #31 asks for image minification to stop being a manual step before every post. `scripts/optimize-images` is that step: run bare it rewrites oversized images in place, and `--check` reports them without touching anything. `scripts/test` now runs `--check` first, so CI fails a pull request that adds an image over budget instead of letting it ship. The budgets are 300 KB for photos, capped at 1600px on the long edge, and 1.2 MB for animated GIFs, capped at 1200px wide. Files already inside their budget are skipped, which keeps the script idempotent — re-encoding a JPEG that is already fine would lose quality for nothing. Running it over the existing images takes assets/images from 25 MB to 10 MB. Photos went from 17.5 MB to 7.4 MB and the screencasts from 7.1 MB to 2.8 MB. This also answers #32, which asked for a second smaller copy of each image for feed readers: the largest photo any reader now receives is 256 KB, so a separate RSS variant would add a build step and a second set of files to maintain for no practical gain. Two findings shaped the pipeline. sips resizes correctly but writes bulky JPEGs. On a 2048px photo it produced 452 KB where cjpeg produced 262 KB from the identical pixels — 25% off the total versus 58%. So sips only resizes and cjpeg encodes, at quality 80, optimized and progressive. For the screencasts, only dimensions matter. On the largest one, palette reduction and lossy LZW each saved under 7%, while halving the width saved 60%. They are 1920px recordings shown in an 800px column, so 1200px still leaves headroom and the terminal text stays legible. Closes #31 Closes #32 Co-authored-by: Jaysinh Shukla <jaysinhshukla@Jaysinhs-MacBook-Pro-2.local> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

Solution for minifying uploaded image automatically #31

Description

Activity

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions