Bildoptimierung im Headless-Stack: leichter, schärfer, schneller

Ein Bild ist auf den meisten Marketing-Seiten das grösste einzelne Asset — und damit der häufigste Grund für einen schlechten Largest Contentful Paint. Im Headless-Stack ist die gute Nachricht: Die Trennung von Backend und Frontend gibt Ihnen genau an dieser Stelle mehr Kontrolle. Die WordPress-Medienbibliothek bleibt die Quelle und liefert über REST oder GraphQL die registrierten Bildvarianten samt srcset; das Frontend entscheidet, in welchem Format, welcher Grösse und mit welcher Ladestrategie sie beim Besucher ankommen. Dieser Beitrag zeigt die konkrete Mechanik — Format-Wahl, responsive Auslieferung, Ladepriorität und Layout-Stabilität — und sagt ehrlich, wo der Stack zusätzlichen Aufwand verlangt.

Die Kurzfassung vorweg: WebP ist 2026 der pragmatische Default, AVIF nur dort, wo der Encode-Aufwand sich rechnet. Das LCP-Bild lädt nie lazy, alle anderen schon. Und jedes Bild trägt width und height, damit das Layout nicht springt. Wer diese drei Regeln befolgt, hat den grössten Teil der Bild-Performance bereits im Griff.

Welches Format soll ich ausliefern — WebP oder AVIF?

WebP ist 2026 die pragmatische Standardwahl, AVIF die technisch überlegene Nische. WebP wird praktisch überall unterstützt, kodiert schnell und liegt deutlich unter der JPEG-Grösse. AVIF komprimiert noch stärker, kostet im Encode aber ein Vielfaches an Rechenzeit. Für die meisten Schweizer KMU-Projekte heisst das: WebP als Default, AVIF gezielt für schwere Hero-Bilder.

Der reale Stand der Verbreitung untermauert das. Im HTTP Archive Web Almanac 2024 macht AVIF nur rund 1,0 % der mobilen Bilder aus — WebP liegt bei 12 %, während JPEG mit 32,4 %, PNG mit 28,4 % und GIF mit 16,8 % das Feld weiter dominieren. AVIF wächst zwar schnell (rund 386 % mehr AVIF-Bilder gegenüber 2022), bleibt aber in absoluten Zahlen die Ausnahme. Format-Überlegenheit im Labor ist eben nicht dasselbe wie Verbreitung im Feld.

Beim Browser-Support ist AVIF inzwischen breit angekommen: Laut caniuse.com liegt die globale Unterstützung bei rund 93 % — Chrome ab Version 85, Firefox ab 93, Safari voll ab 16.4. Das klingt nach „kann man nehmen", heisst aber im Umkehrschluss: Rund jeder vierzehnte Aufruf braucht ein Fallback. Eine <picture>-Kette oder die Bild-Komponente Ihres Frameworks, die AVIF zuerst und WebP als Rückfallebene anbietet, bleibt deshalb Pflicht — nicht Kür.

Wie liefert WordPress die Varianten an das Frontend?

WordPress ist im Headless-Stack die Bildquelle, nicht der Engpass. Der Core erzeugt beim Upload mehrere Grössen jedes Bildes und liefert seit Version 4.4 (Dezember 2015) automatisch srcset und sizes im Markup mit — basierend auf den registrierten Bildgrössen. Im Headless-Setup greift das Frontend diese Varianten über REST oder GraphQL ab und nutzt sie als Grundlage für die responsive Auslieferung.

Dass diese native Funktion existiert, dokumentiert Make WordPress Core seit über zehn Jahren. Praktisch bedeutet das: Die Redaktion lädt ein Bild einmal hoch, WordPress legt die Grössenvarianten an, und das Frontend muss sie nur noch korrekt referenzieren. Welcher API-Layer dabei zum Einsatz kommt, ordnet der Beitrag zu WPGraphQL versus REST API ein — für die Bildauslieferung liefern beide die nötigen Metadaten.

Responsive srcset ist im Web inzwischen etabliert, aber noch nicht flächendeckend: Laut dem Web Almanac 2024 erscheint srcset auf 42 % der mobilen Seiten (gegenüber 34 % zwei Jahre zuvor). Das heisst, mehr als die Hälfte der Seiten verschenkt noch immer die einfachste Bild-Optimierung überhaupt: dem Mobilgerät ein kleineres Bild zu schicken als dem Desktop. Im Headless-Stack ist genau das der Default, nicht die Ausnahme.

Warum das LCP-Bild niemals lazy laden darf

Das LCP-Bild — meist das Hero-Bild über der Falz — ist das grösste sichtbare Element beim ersten Seitenaufbau und damit oft der Wert, der über „gut" oder „verbesserungswürdig" beim Largest Contentful Paint entscheidet. Genau dieses Bild lazy zu laden ist einer der häufigsten Performance-Fehler überhaupt, weil Lazy-Loading den Ladestart künstlich verzögert.

Die offizielle Google-Guidance ist unmissverständlich: web.dev schreibt, man solle das LCP-Bild „niemals lazy laden, da das immer zu unnötiger Ladeverzögerung führt". Stattdessen gehört auf das wahrscheinliche LCP-Element ein fetchpriority="high", damit der Browser es früh und bevorzugt anfordert. In Next.js erledigt das die priority-Prop an der Image-Komponente — sie setzt loading="eager" und fetchpriority="high" in einem Schritt.

Wie verbreitet der Fehler ist, zeigt eine Zahl deutlich: Laut HTTP Archive Web Almanac 2024 verwenden rund 9,5 % der LCP-relevanten mobilen Bild-Elemente fälschlich loading="lazy". Gleichzeitig nutzen mittlerweile rund 35 % aller Websites natives Lazy-Loading (Mitte 2022 waren es noch rund 25 %) — das Werkzeug ist also angekommen, wird aber zu pauschal eingesetzt. Die Regel ist simpel: Lazy-Loading für alles unterhalb der Falz, eager mit hoher Priorität für das eine Bild darüber.

Lazy-Loading ist eine Optimierung für alles, was der Besucher noch nicht sieht — beim ersten sichtbaren Bild wird daraus ein selbstgemachter Bremsklotz.

Wie verhindere ich Layout-Verschiebung durch Bilder?

Layout-Verschiebung durch Bilder verhindert man, indem jedes Bild den Platz reserviert, den es einnehmen wird, bevor es geladen ist. Konkret heisst das: width und height als Attribute setzen — oder ein festes Seitenverhältnis per CSS. Fehlt diese Angabe, springt der Inhalt beim Nachladen nach unten, und der Cumulative Layout Shift verschlechtert sich spürbar.

Das Problem ist verbreitet und ungelöst. Laut HTTP Archive Web Almanac 2024 tragen nur 32 % aller mobilen Bild-Elemente sowohl ein width- als auch ein height-Attribut — ein Plus von vier Prozentpunkten gegenüber 2022, aber noch immer eine Minderheit. Über zwei Drittel der Bilder im mobilen Web riskieren damit eine vermeidbare Layout-Verschiebung.

Im Headless-Stack mit Next.js ist dieser Fehler praktisch ausgeschlossen: Die Image-Komponente erzwingt width und height (oder den fill-Modus mit definiertem Container) und reserviert daraus automatisch das Seitenverhältnis. In rohem Markup oder bei aus WordPress übernommenen Inhalten müssen Sie selbst dafür sorgen, dass die Dimensionen mitkommen — die Medienbibliothek liefert sie über die API mit, sie müssen nur durchgereicht werden. Wie sich CLS, LCP und INP gemeinsam ins Ziel bringen lassen, vertieft der Beitrag zu Core Web Vitals bei WordPress 2026.

Was Bildoptimierung im Headless-Stack nicht automatisch löst

Jetzt die Kehrseite: Der Stack liefert die Werkzeuge für schlanke Bilder, nicht das fertige Ergebnis — drei Aufgaben bleiben am Team hängen. Wer das ignoriert, baut sich neue Engpässe ein, die schwerer zu finden sind als das alte 2-Megabyte-JPEG.

Ein CDN optimiert Bilder nicht von selbst. Ein Content Delivery Network verteilt und cacht Dateien näher beim Besucher — es verkleinert oder konvertiert sie aber nicht standardmässig. Liegt im WordPress-Origin ein unkomprimiertes JPEG, liefert das CDN genau dieses unkomprimierte JPEG nur schneller aus. Echte Verkleinerung braucht eine aktive Transformationsschicht: entweder die Bildoptimierung des Frontend-Frameworks oder ein Bild-CDN, das Format und Grösse tatsächlich umrechnet. „Das CDN macht das schon" ist der häufigste Irrtum, dem wir in eigenen Schweizer Projekt-Reviews 2024–2026 begegnet sind.

Next.js mit externen WordPress-Medien braucht Konfiguration. Die Next.js-Image-Komponente blockiert externe Bilder per Default und verlangt, dass erlaubte Domains explizit über images.remotePatterns freigegeben werden — sonst liesse sie sich als offener Bild-Proxy missbrauchen. Die ältere domains-Option gilt seit Next.js 14 als veraltet zugunsten der strikteren remotePatterns. Wer Medien von einer separaten WordPress-Backend-Domain einbindet, muss diese zuerst eintragen, bevor ein einziges Bild durch die Optimierung läuft. Das ist kein Bug, sondern eine bewusste Sicherheitsschranke — aber eine, die im ersten Deploy gern übersehen wird.

AVIF-Encode ist langsam und damit potenziell teuer. Hier liegt der eigentliche Grund, warum AVIF trotz besserer Kompression Nische bleibt. Laut einem Anbieter-Benchmark ist der AVIF-Encode bei Standardeinstellungen in der Grössenordnung rund 47-mal langsamer als WebP für dasselbe Bild, bei maximaler Qualität sogar über 500-mal. Für 10'000 Produktbilder bedeutet das laut dieser Quelle den Unterschied zwischen rund 15 Minuten (WebP) und über elf Stunden (AVIF-Default). Diese Zahl stammt von einem einzelnen Tool-Anbieter und ist nicht unabhängig geprüft — sie gibt die Grössenordnung wieder, nicht eine physikalische Konstante. Praktisch heisst das: Für ein Hero-Bild lohnt der AVIF-Aufwand, für einen ganzen Produktkatalog wird er zur Last.

On-Demand-Optimierung verschiebt die Kosten, sie entfernt sie nicht. Die Next.js-Image-Komponente optimiert Bilder beim Request, nicht zur Build-Zeit. Das ist bequem, kann aber bei vielen einzigartigen Bildern und engem Hosting-Budget ins Geld gehen. Die Next.js-Dokumentation sieht dafür loaderFile vor, um die Transformation an einen externen Dienst oder ein Bild-CDN auszulagern — eine sinnvolle Option, sobald die Bildmengen wachsen. Wo genau diese Schwelle liegt, hängt am gewählten Hosting; eine Einordnung dazu gibt der Beitrag zu Headless-WordPress-Hosting 2026.

Welche Strategie passt zu welchem Projekt?

Die richtige Bildstrategie hängt am Profil: Bildmenge, Hosting-Budget und wie oft sich der Bestand ändert. Eine schlanke Marketing-Site mit wenigen Hero-Bildern trifft andere Entscheidungen als ein Shop mit Tausenden Produktfotos. Die folgende Matrix fasst zusammen, was sich in eigenen Schweizer Projekten 2024–2026 bewährt hat.