Optimiere deine Assets beim Build, nicht bei jeder Anfrage

Die meisten Assets einer Seite stehen längst fest, bevor ein einziger Besucher auftaucht. Das Hero-Bild, die Icons, das gebündelte CSS, die Schriften: Sie liegen in deinem Repo und sind von einer Anfrage zur nächsten identisch. Es gibt nur zwei Orte, sie zu optimieren. Einmal, beim Build. Oder immer wieder, am Edge, jedes Mal, wenn eine Seite lädt.

Für die Assets, die du selbst auslieferst, ist der Build der bessere Ort.

Warum beim Build

Du machst die Arbeit einmal. Das Ergebnis ist klein, sobald es ausgeliefert wird, und bleibt klein, ohne CPU pro Anfrage, ohne Transform-Cache zum Aufwärmen und ohne On-the-fly-Transform-Rechnung, die mit deinem Traffic wächst.

Das Ergebnis ist außerdem etwas, das du sehen kannst. Die optimierten Dateien liegen direkt in deiner Build-Ausgabe, du kannst sie also vergleichen, wiegen und genau wissen, was rausgeht. Eine Edge-Transformation ist eine Blackbox, der du vertraust; ein Build-Artefakt ist eine Datei, die du öffnen kannst.

Und es deckt mehr als Bilder ab. Dein Build kümmert sich bereits um JavaScript, CSS, SVG und Schriften, und all das schrumpft ebenfalls. Ein rohes TTF, das statt WOFF2 ausgeliefert wird, ist für sich genommen rund zwei Drittel verschwendet.

Wo der Edge sich weiterhin verdient macht

Die Build-Optimierung berührt nur die Assets, die durch deinen Build laufen. Zwei Fälle brauchen wirklich den Anfragepfad:

• Nutzer-Uploads. Wenn Leute Bilder hochladen, während deine Seite läuft, kannst du die nicht beim Build optimieren. Das braucht etwas auf dem Anfragepfad: eine API oder ein CMS-Plugin.
• Riesige, vielfältige Kataloge, die Größen pro Gerät brauchen. Wenn du wirklich pro Gerät eine andere Größe über Millionen von Bildern hinweg auslieferst, rechnet sich ein On-the-fly-Dienst.

Für eine normale Seite, und das sind die meisten Seiten, ist keiner dieser Fälle der Flaschenhals, und der Build ist einfacher und günstiger.

Es umsetzen

Zwei Wege, beide laufen über die Patu-API, sodass die Kodierung außerhalb deiner Maschine passiert.

Ein Befehl, in jedem Build-Skript oder CI-Job:

PATU_KEY=your_key npx @patu.dev/cli ./dist

Es durchläuft den Ordner, optimiert die Bilder, das SVG, das JS, das CSS und die Schriften an Ort und Stelle und überspringt alles, was es nicht wirklich schlagen kann. Füge --cdn hinzu, um sie hochzuladen und die Referenzen auf cdn.patu.dev umzuschreiben, statt zurück auf die Festplatte zu schreiben.

Oder binde es in Vite ein, sodass jeder Build abgedeckt ist, ohne dass du daran denken musst:

import patu from '@patu.dev/vite'
export default { plugins: [patu()] }

Der Punkt

Der Edge ist nicht falsch. Aber es ist gut möglich, dass du dafür zahlst, bei jeder einzelnen Anfrage Assets zu transformieren, die sich zwischen ihnen nie ändern. Optimiere sie einmal, im Build, den du ohnehin schon ausführst, und liefere sie klein aus. Die Integrationsseite hat das CLI, das Vite-Plugin und den Rest.