ShortPixel

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me image compression that replaces ShortPixel — and note that the tools are free and excellent, so this is about running them rather than writing them.

STACK
- Node 20+ with sharp, plus the specialist encoders where they beat it: pngquant and oxipng for PNG, mozjpeg for JPEG
- A build step and a command-line tool. A service only if you take user uploads
- SQLite through better-sqlite3 for the cache index

WHAT ACTUALLY MAKES A FILE SMALLER, IN ORDER
- **Resize to the sizes actually used.** Serving a 4000-pixel image into a 400-pixel slot is the largest waste on most sites, and no compressor fixes it. Do this first and measure again before tuning anything else
- **Serve a modern format.** AVIF is typically 30% smaller than a good JPEG, WebP around 25%. The format choice saves more than any amount of quality tuning within a format
- Then compress: quantise PNG to a palette, re-encode JPEG with trellis quantisation and progressive scans
- Strip metadata — EXIF, thumbnails, and the location an ordinary phone photograph carries — but **keep the colour profile when the image is not sRGB**, because stripping that shifts every colour

THE QUALITY QUESTION, WHICH IS THE CRAFT
- A fixed quality number is the wrong approach: 80 is wasteful on a flat illustration and visibly poor on foliage
- Target a perceptual metric instead. Encode at several qualities, measure each against the original with SSIM or ssimulacra, and keep the smallest that stays above a threshold
- That search costs a few seconds per image and it happens once, cached by content hash. It is the difference between guessing and knowing
- Calibrate the threshold by eye: run a page of your own images through it, look at them at real size on a real screen, and adjust. Do not trust a number you have not checked

THE PIPELINE
- Input at whatever resolution it arrived, output every declared size in every declared format
- Width and height emitted so the markup can reserve space — layout shift is a worse experience than a large file
- A manifest mapping source to derivatives, which the templates read to build a srcset
- Cached by content hash plus every option, so an unchanged image is never re-encoded and a build that re-encodes everything is a build nobody runs

THE AWKWARD CASES
- Alpha: quantising an image with transparency badly produces fringing. Test with a logo on a coloured background
- Animated GIFs: convert to video or animated WebP, usually ten times smaller. A GIF is a terrible video format
- Screenshots and photographs of text compress badly and artefact visibly. Detect them by edge density and raise the threshold, or keep them lossless
- Very small images: below a few kilobytes the format overhead dominates, so consider inlining them instead

FOR USER UPLOADS
- Then it is a service: a queue with a concurrency cap, a size limit enforced as bytes arrive, type from content rather than filename, and EXIF stripped before storage
- Signed transform parameters, or a fixed set of named presets, so nobody uses your server as a free rendering farm

AND THE CHECK IN CI
- Fail the build if any committed image exceeds a budget. That single rule is how a site stops slowly filling with four-megabyte hero images, and it costs nothing

WHAT MATTERS MOST
Resizing and format, before compression. Those two usually beat any compressor including the paid one, and the perceptual search makes the third step honest rather than guessed.