353 KB oder 23 KB? Wie uns dieselbe Bild-URL zwei Wahrheiten lieferte

Es fing als Routinefrage an: Wie schwer sind die Bilder auf einer Salespage? Es endete damit, dass wir eine Messlücke gefunden haben, die die komplette Standard-Messkette betrifft, also Lighthouse, PageSpeed Insights und sogar Googles CrUX-Felddaten. Und mit einem Fix, der das Bildgewicht der Seite mehr als halbiert hat.

Das hier ist das ehrliche Protokoll. Mit dem Streit, mit den Fehlmessungen auf beiden Seiten und mit dem Moment, in dem ein einziger HTTP-Header alles erklärt hat.

Kurz gesagt: Shopifys CDN entscheidet anhand des User-Agents, welche Datei es ausliefert. Chrome, Firefox und aktuelle Safaris bekommen automatisch kleine WebP-Transcodes. Ältere Safari-Versionen (bis Safari 17, also ältere iPhones und ältere Macs) bekommen das Original, bei Grafiken mit Alpha-Kanal sogar ein aufgeblasenes PNG. Wer nur mit Chrome-basierten Tools misst, sieht davon nichts. Wer seine Kundschaft auf Apple-Geräten hat, sollte genau hier hinschauen.

Zwei Messungen, zwei Wahrheiten

Auf der Salespage eines D2C-Beauty-Shops aus unserer eigenen Markenfamilie liegen 31 Content-Bilder: Produktfotos, Vorher-nachher-Bilder, eine Wirkstoff-Grafik. Unser Image-Check-Tool meldete: alles gut, die Bilder kommen als schlanke WebPs, das größte mit rund 23 KB.

Dann kam die Gegenmessung, mit anderem Werkzeug und anderem Ansatz: dieselbe Bild-URL, exakt wie sie im Markup der Seite steht, geladen mit den Headern eines iPhone-Safari. Ergebnis: 353 KB, Content-Type image/png. Nicht ungefähr, sondern byte-genau, mit content-length: 361963 im Response-Header.

Beide Seiten haben nachgemessen, beide Zahlen waren reproduzierbar. Dieselbe URL. 23 KB WebP gegen 353 KB PNG. Einer musste sich irren.

Das Schöne an diesem Abend: Wir haben nicht diskutiert, wir haben eskaliert. Unsere beiden KI-Agenten haben sich gegenseitig die Messungen um die Ohren gehauen, jede Behauptung musste mit Headern, Byte-Zahlen und reproduzierbaren Requests belegt werden. Genau dieses Challenging hat am Ende die Ursache freigelegt, die keine der beiden Einzelmessungen gesehen hätte.

Verdächtiger Nummer eins: die Dateiendung lügt

Der erste echte Befund: Die Datei heißt zwar wirkstoffe.webp, aber der Inhalt ist gar kein WebP. Die Magic Bytes am Dateianfang sagen PNG. Jemand hatte beim Bau der Seite PNGs und JPEGs schlicht in .webp umbenannt statt konvertiert. Das CDN ist dabei ehrlich geblieben: Es liefert content-type: image/png, weil es den Inhalt anschaut, nicht den Dateinamen. Die Endung ist für ein CDN nur Deko.

Das erklärte die 353 KB. Es erklärte aber nicht die 23 KB der anderen Messung. Wo kam die schlanke WebP-Variante her, wenn die Quelldatei ein fettes PNG ist?

Die Header-Bisektion: ein Header kippt alles

Also haben wir es sauber isoliert. Dieselbe URL, identische Requests, und dann Header für Header getauscht: Accept, Accept-Encoding, Sec-Fetch-*, User-Agent. Das Ergebnis war eindeutig und hat uns trotzdem überrascht:

GET .../wirkstoffe.webp?v=...

User-Agent: Chrome (macOS)      →  23.372 B   image/webp
User-Agent: Chrome (Android)    →  23.372 B   image/webp
User-Agent: Firefox             →  23.372 B   image/webp
User-Agent: Safari (iPhone)     → 361.963 B   image/png

Der Accept-Header, mit dem Browser eigentlich signalisieren, welche Bildformate sie können, spielte keine Rolle. Der User-Agent entscheidet. Shopifys CDN transcodiert Bilder on the fly zu WebP, aber nur für Browser, die es anhand des User-Agent-Strings als WebP-fähig einstuft.

Damit war der Streit aufgelöst, und zwar zugunsten beider Seiten: Die 23 KB waren echt (Chrome-Welt), die 353 KB waren echt (Safari-Welt). Zwei Messungen, zwei User-Agents, zwei Wahrheiten.

Es kommt noch besser: die Versions-Weiche

Beim Absichern der Ergebnisse fiel eine weitere Feinheit auf. Ein aktueller Safari bekam plötzlich auch das schlanke WebP. Also haben wir die Safari-Versionen durchprobiert:

Safari 17 (iPhone, iOS 17)  → 361.963 B  image/png
Safari 17 (macOS)           → 361.963 B  image/png
Safari 18                   →  23.372 B  image/webp
Safari 19, 20, …            →  23.372 B  image/webp

Shopify zieht die Grenze bei Safari 18. Alles darunter gilt als Legacy und bekommt den schweren Pfad. Das klingt akademisch, ist es aber nicht: Safari 17 und älter, das sind ältere iPhones und vor allem ältere Macs, die nicht mehr auf das neueste macOS aktualisieren. In vielen Zielgruppen ist das ein relevanter zweistelliger Prozentsatz des Traffics.

Und der Legacy-Pfad ist nicht einfach nur „das Original". Die Wirkstoff-Grafik lag als WebP mit Alpha-Kanal vor. Für den alten Safari transcodiert Shopify WebP zurück, und weil Transparenz im Spiel ist, wird daraus ein PNG. Aus 23 KB werden 362 KB, eine Aufblähung um Faktor 15, erzeugt vom CDN selbst. Der naheliegende Gegenversuch, das Bild per URL-Parameter kleiner zu rechnen, macht es für Safari sogar schlimmer: Ein Resize auf 908 Pixel lieferte ein frisch encodiertes PNG mit 508 KB.

Warum kein Google-Tool das je gezeigt hätte

Jetzt kommt der Teil, der uns wirklich beschäftigt hat. Wo hätte man dieses Problem gesehen?

• Lighthouse und PageSpeed Insights (Lab): rendern mit Chrome. Chrome bekommt die kleinen WebPs. Alles grün.
• CrUX (Field): Der Chrome User Experience Report sammelt Felddaten ausschließlich von echten Chrome-Nutzern. Die bekommen die kleinen WebPs. Alles grün.
• Eigene Tools auf Chromium-Basis: dito. Unser eigener Image Check ist so in die Falle gelaufen.

Die schwere Welt, also ältere Safaris auf iPhones und Macs, taucht in keiner dieser Messungen auf. Für Core Web Vitals und Ranking war der Schaden deshalb praktisch null. Für echte Menschen nicht: Eine Salespage, die auf Paid Traffic läuft und deren Zielgruppe überdurchschnittlich auf Apple-Geräten unterwegs ist, hat einem Teil genau dieser Zielgruppe 2,6 MB Bilder ausgeliefert statt 1,1 MB. So etwas sieht man nur in Bounce Rate und Conversion, und dort steht nie die Ursache dabei.

Das ist die eigentliche Lektion: Die gesamte Standard-Messkette schaut mit Chrome-Augen auf eine Apple-Zielgruppe. Wer nur grüne Lighthouse-Scores einsammelt, hat einen blinden Fleck exakt dort, wo im D2C-Geschäft das Geld verdient wird.

Der Fix: Quelldateien reparieren, nicht Symptome

CDN-Transcodes lassen sich für den Legacy-Pfad nicht per URL-Parameter erzwingen. Also haben wir das Problem an der Wurzel behoben:

1. Alle 31 Bilder aus dem Theme gezogen und die echten Formate per Magic Bytes geprüft (Mischung aus umbenannten JPEGs, umbenannten PNGs und echten, aber schweren WebPs, darunter ein 2245 Pixel breiter Master für eine Anzeige mit 350 CSS-Pixeln).
2. Neu encodiert: Fotos als sauber komprimierte JPEGs in sinnvoller Maximalbreite, die Grafik mit Alpha-Kanal auf Weiß geflattet. Der Alpha-Kanal war visuell ohnehin unsichtbar, hat aber den PNG-Blowup ausgelöst.
3. Als ehrliche .jpg-Assets hochgeladen und die Templates auf die neuen URLs umgestellt. Die moderne Welt bekommt weiterhin automatisch WebP vom CDN, die Legacy-Welt bekommt jetzt kleine JPEGs statt fetter PNGs.

Das Ergebnis, gemessen mit echtem Chrome über das Chrome DevTools Protocol, einmal als Safari-Welt und einmal als Chrome-Welt:

Bildgewicht der Salespage      vorher      nachher
Safari (ältere Versionen)     2.611 KB    1.117 KB   (−57 %)
Chrome                        2.611 KB    1.116 KB
Wirkstoff-Grafik                362 KB       25 KB   (−93 %)

Optisch hat sich nichts verändert, das haben wir mit Live-Screenshots vor und nach dem Deploy abgesichert.

Die Konsequenz fürs Tooling: beide Welten messen, immer

Ein Fehler, den ein Tool einmal übersehen hat, darf kein zweites Mal durchrutschen. Deshalb haben wir unseren Image Check noch am selben Abend umgebaut:

• UA-Delivery-Probe: Die größten Bilder jeder geprüften Seite werden zusätzlich zweimal angefragt, einmal als älterer Safari (Version 17), einmal als Chrome. Identischer Accept-Header, das Format wird an den Magic Bytes erkannt, nicht an der Endung.
• UA-Split-Befund: Weicht die Auslieferung relevant ab, gibt es eine eigene Warnung mit beiden Byte-Zahlen pro Bild und dem Hinweis, dass Google-Tools nur die Chrome-Seite sehen. Ein reiner Format-Unterschied bei ähnlicher Größe wird bewusst nicht geflaggt, denn das ist ein CDN, das korrekt arbeitet.
• Endungs-Check: Dateien, die .webp oder .avif heißen, aber PNG oder JPEG enthalten, werden als umbenannt-statt-konvertiert markiert.

Der Regressionstest mit den alten, kaputten URLs findet alle drei präparierten Fälle, inklusive des Klassikers Safari 353 KB gegen Chrome 23 KB. Die gefixte Seite und eine Kontrollseite liefern null Fehlalarme.

Was ihr daraus mitnehmen könnt

Messt wie eure Kundschaft, nicht wie eure Tools. Wenn eure Zielgruppe auf iPhones und Macs sitzt, gehört mindestens eine Messung mit Safari-Headern in jeden Performance-Check. Chrome-basierte Werkzeuge, und dazu zählen auch PageSpeed und CrUX, sehen nur die halbe Realität.

Traut keiner Dateiendung. Ob ein Bild wirklich WebP ist, entscheiden die ersten zwölf Bytes der Datei, nicht der Dateiname. Umbenennen ist keine Konvertierung.

Prüft eure Alpha-Kanäle. Eine unsichtbare Transparenz-Ebene kann aus einem 23-KB-Bild ein 362-KB-PNG machen, sobald ein CDN für ältere Browser zurücktranscodiert.

CDN-Magie ist Browser-Politik. Automatische Formatwahl ist großartig, aber sie folgt Regeln, die ihr nicht seht und die sich ändern können. Die einzige robuste Basis ist eine saubere, korrekt encodierte Quelldatei in vernünftiger Größe.

Lasst eure Messungen challengen. Der wertvollste Moment dieses Abends war nicht die erste Messung, sondern die zweite, die ihr widersprochen hat. Wäre nur ein Werkzeug gelaufen, wäre der Fehler heute noch live.

Wenn ihr wissen wollt, wie eure Seiten in beiden Welten aussehen: Genau solche Audits fahren wir bei ONE COMMERCE für Shopify-Shops regelmäßig, inklusive Fix direkt im Theme. Meldet euch gern.