Mach die Asset-Optimierung zu einem CI-Schritt, nicht zu etwas, woran du denken musst

Asset-Optimierung funktioniert genau so lange, bis jemand es vergisst. Ein 3 MB großes Hero-PNG wird committet, der Build besteht, das Deploy geht raus, und niemand bemerkt es, bis eine Woche später ein Performance-Score abstürzt. Dann optimiert es jemand von Hand, und die Uhr läuft von vorne für die nächste Person, die es vergisst.

Sich darauf zu verlassen, dass Leute daran denken, ist keine Strategie. Verleg es dorthin, wo Vergessen unmöglich ist.

Pack es in die Pipeline

Die Optimierung gehört neben deine Tests und deinen Build: automatisch, bei jedem Push, von der Maschine erzwungen statt von der Gewohnheit. Füge einen Schritt hinzu, nachdem dein Build seine Ausgabe erzeugt hat, und jedes Deploy liefert optimierte Assets aus, ob jemand daran gedacht hat oder nicht.

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

Bei jedem Push optimiert die Action, was der Build erzeugt hat, bevor es rausgeht. Speichere deinen Schlüssel als Repository-Secret und übergib ihn; mehr ist nicht nötig.

Zwei Stellschrauben, die man kennen sollte

• strict. Standardmäßig wird eine Datei, die sich nicht verbessern lässt, in Ruhe gelassen und der Build läuft weiter. Schalte strict ein, um stattdessen den Build fehlschlagen zu lassen, wenn du eine harte Garantie willst, dass nie etwas Unoptimiertes rausgeht.
• mode. optimize (der Standard) schreibt die kleineren Dateien zurück in deine Build-Ausgabe. mode: cdn lädt sie hoch und liefert stattdessen von cdn.patu.dev aus, sodass dein Origin die Bytes nie trägt.

Die ehrlichen Grenzen

Es optimiert deine Build-Ausgabe, also die Menge an Assets, die du auslieferst. Nutzer-Uploads zur Laufzeit brauchen weiterhin etwas auf dem Anfragepfad, nicht in der CI.

Und es fügt einen Schritt hinzu, kostet also ein bisschen Pipeline-Zeit. In der Praxis ist das gering, und es läuft dort, wo kein Nutzer darauf wartet.

Der Punkt

Der Wert liegt nicht in einer einzelnen Optimierung. Er liegt darin, dass „wir haben vergessen, die Bilder zu komprimieren" aufhört, etwas zu sein, das passieren kann. Die Pipeline läuft jedes Mal auf dieselbe Weise. Die Integrationsseite hat die Action, dazu das CLI und die WordPress- und Vite-Wege für den Fall, dass deine Assets nicht in einem Build liegen.