Patu

Faça da otimização de assets um passo de CI, não algo de que você se lembra

A otimização de assets funciona bem até alguém esquecer. Um PNG principal de 3 MB é commitado, o build passa, o deploy sai, e ninguém percebe até uma pontuação de desempenho despencar uma semana depois. Então alguém o otimiza à mão, e o relógio recomeça na próxima pessoa que esquecer.

Depender de as pessoas se lembrarem não é uma estratégia. Mova-a para onde esquecer é impossível.

Coloque no pipeline

A otimização pertence ao lado dos seus testes e do seu build: automática, a cada push, imposta pela máquina em vez de pelo hábito. Adicione um passo depois de o seu build produzir a saída, e cada deploy entrega assets otimizados, tenha alguém pensado nisso ou não.

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

A cada push, a action otimiza o que o build produziu, antes de sair. Guarde a sua chave como um secret do repositório e passe-a; nada mais é necessário.

Dois ajustes que vale a pena conhecer

Os limites honestos

Ele otimiza a saída do seu build, que é o conjunto de assets que você entrega. Uploads de usuários em tempo de execução ainda precisam de algo no caminho da requisição, não na CI.

E adiciona um passo, então custa um pouco de tempo de pipeline. Na prática isso é pequeno, e roda onde nenhum usuário está esperando por ele.

O ponto

O valor não está em nenhuma otimização específica. Está em que “esquecemos de comprimir as imagens” deixa de ser algo que pode acontecer. O pipeline roda da mesma forma toda vez. A página de integrações tem a action, junto com o CLI e os caminhos do WordPress e do Vite para quando os seus assets não vivem em um build.