Make asset optimization a CI step, not a thing you remember

Asset optimization works right up until someone forgets. A 3 MB hero PNG gets committed, the build passes, the deploy goes out, and nobody notices until a performance score falls off a cliff a week later. Then someone optimizes it by hand, and the clock starts again on the next person who forgets.

Relying on people to remember is not a strategy. Move it to where forgetting is impossible.

Put it in the pipeline

Optimization belongs next to your tests and your build: automatic, on every push, enforced by the machine instead of by habit. Add one step after your build produces its output, and every deploy ships optimized assets whether or not anyone thought about it.

- run: npm run build
- uses: Gheop/patu-action@v1
  with:
    directory: dist
    api-key: ${{ secrets.PATU_KEY }}

On every push, the action optimizes what the build produced, before it ships. Store your key as a repository secret and pass it in; nothing else is required.

Two dials worth knowing

• strict. By default a file that can’t be improved is left alone and the build continues. Turn on strict to fail the build instead, when you want a hard guarantee that nothing unoptimized ever ships.
• mode. optimize (the default) writes the smaller files back into your build output. mode: cdn uploads them and serves from cdn.patu.dev instead, so your origin never carries the bytes.

The honest limits

It optimizes your build output, which is the set of assets you ship. Runtime user uploads still need something on the request path, not in CI.

And it adds a step, so it costs a little pipeline time. In practice that is small, and it runs where no user is waiting on it.

The point

The value isn’t any one optimization. It’s that “we forgot to compress the images” stops being a thing that can happen. The pipeline runs the same way every time. The integrations page has the action, along with the CLI and the WordPress and Vite paths for when your assets don’t live in a build.