Welches Bildformat der Browser erhält: Formatauswahl und Cache-Regeln prüfen

Ein Server kann unter derselben Bildadresse unterschiedliche Formate liefern. Der Anfrageheader Accept nennt bevorzugte Medientypen; der Antwortheader Vary hilft Zwischenspeichern bei der Auswahl einer passenden gespeicherten Antwort. Ein anderer Inhaltstyp oder ein fehlender Header beweist allerdings noch keine fehlerhafte Bildanzeige.

Eine historische Prüfung von zwanzig Startseiten am 6. September 2026 erfasste 1.345 Bildeinträge und untersuchte 76 Bildadressen. Die gespeicherten Ergebnisse bleiben nützlich, doch die ursprüngliche Auswertung überschätzte das Verfahren: Die Implementierung verglich eine GET- mit einer HEAD-Anfrage, keine zwei ansonsten gleichen GET-Anfragen. GET fordert neben den Headern auch den Antwortinhalt an; HEAD fordert die Header ohne Antwortinhalt an. Deshalb werden gespeicherte Werte und Aussagen, die einen neuen kontrollierten Test erfordern, hier getrennt.

Was die historische Stichprobe tatsächlich erfasste

Bei vierzehn der 76 Paare unterschieden sich die deklarierten Medientypen. Sechs Proben der New York Times meldeten WebP gegenüber JPEG mit Vary: Accept. Sechs Zeit-Proben meldeten WebP gegenüber JPEG ohne gespeicherten Vary-Wert; zwei Onet-Proben AVIF gegenüber PNG ebenfalls ohne diesen Wert. Bei den übrigen 62 Paaren war der deklarierte Medientyp gleich. Identische Dateiinhalte sind damit nicht nachgewiesen.

Die Anfragen unterschieden sich sowohl in der Methode als auch in Accept. Zudem verwendete die alternative Anfrage Accept: image/*. Dieser Platzhalter erlaubt auch AVIF und WebP und bildet deshalb keinen Browser ohne diese Formate ab. Die vierzehn Unterschiede liefern Anhaltspunkte für eine Nachprüfung, aber keinen isolierten Nachweis einer Accept-basierten Aushandlung. Der Datensatz enthält Zusammenfassungen, keine beiden Antwortdateien samt vollständigen Rohheadern.

Ein aussagekräftigerer Vergleich

Ein kontrollierter Vergleich verwendet zweimal GET, dieselbe Adresse und bis auf Accept dieselben Optionen. Eine Basisanfrage kann AVIF und WebP mit q=0 ausdrücklich ausschließen; image/* schließt keines dieser Formate aus. Accept bleibt eine Anforderung an die Antwort. Ob die tatsächlich gelieferte Datei dazu passt, muss geprüft werden.

Zur Auswertung gehören endgültige URL, Status, deklarierter Medientyp, tatsächliches Dateiformat, Bytezahl, Hashwert des Inhalts und vollständige Antwortheader. Gleicher Typ und gleiche Länge beweisen keine gleichen Bytes. Abweichende Bytes können auch durch ein verändertes Motiv, CDN-Verhalten oder unterschiedliche Abrufzeitpunkte entstehen. Wiederholungen und gegebenenfalls die Serverkonfiguration liefern belastbarere Hinweise auf die Ursache.

Vary steuert die Wiederverwendung

Wird eine zwischenspeicherbare Antwort anhand von Accept ausgewählt, teilt Vary: Accept normalerweise dieses Auswahlkriterium mit. Ein Cache darf die gespeicherte Antwort nicht einfach für eine Anfrage mit unpassendem Accept-Wert wiederverwenden. HTTP erlaubt beim Vergleich eine Normalisierung; eine eigene Kopie für jede unterschiedliche Schreibweise ist keine unvermeidliche Vorgabe.

Ob Speicherung und Wiederverwendung zulässig sind, hängt zusätzlich von Cache-Vorgaben, Aktualität und Konfiguration ab. Fehlendes Vary kann eine falsche Wiederverwendung begünstigen. Ein tatsächlich fehlerhafter CDN-Abruf wurde mit der historischen Probe jedoch nicht nachgewiesen. Vorgaben wie no-store und ein bewusst konfigurierter Cache-Schlüssel verändern die Bewertung. Vary: * verhindert eine unmittelbare Wiederverwendung ohne Validierung.

Die Prüfung muss vollständige Headernamen vergleichen. Vary: Accept-Encoding betrifft die Inhaltskodierung und bedeutet etwas anderes als Vary: Accept. Eine bloße Suche nach der Zeichenfolge accept kann beide Fälle verwechseln.

Eine belegbare Lehre aus dem Prüfer

Eine ältere lokale Implementierung übergab den gewünschten Header als Option accept. Die gemeinsame Abrufbibliothek erwartet dafür kopfzeilen. Der Vergleich dieser Quelldateien bestätigt die Schnittstellenverwechslung: Über die falsche Option wurde der gewünschte Header nicht weitergereicht. Ein Test muss deshalb neben simulierten Antworten auch die ausgehende Anfrage untersuchen. Gleiche Antworten allein schließen Aushandlung nicht aus.

Maße, Ladeverhalten und Alternativtexte

Die gespeicherte Markup-Auswertung zählt 783 von 1.345 Bildeinträgen, bei denen mindestens eine gültige numerische Maßangabe fehlt. Das bedeutet nicht, dass jeweils beide Attribute fehlen. Sechs untersuchte Seiten enthielten für jedes erkannte Bild gültige Maße. Bei Heise fehlte bei 423 von 426 Einträgen ein vollständiges gültiges Maßpaar.

Passende Werte für width und height helfen, das Seitenverhältnis vor dem Laden zu reservieren. Auch CSS kann geeigneten Platz freihalten. Fehlende Attribute sind daher ein Prüfhinweis und keine gemessene Layoutverschiebung. Cumulative Layout Shift misst, wie stark sich sichtbare Inhalte unerwartet auf der Seite verschieben. Dafür ist die tatsächlich dargestellte Seite zu beobachten.

Auch die Zahl 762 beruht auf einer Näherung: Diese Einträge stehen im Quelltext hinter den ersten drei Bildern und tragen kein loading="lazy". Sichtfeld und CSS-Layout wurden nicht gemessen. Die Quelltextreihenfolge beweist keine Unsichtbarkeit; ein wichtiges anfangs sichtbares Bild sollte nicht allein wegen der vierten Position im HTML verzögert laden.

Bei 27 Einträgen fehlt das alt-Attribut. Ein leeres alt="" kann bei rein dekorativen Bildern oder bereits daneben vermittelten Bildinformationen angemessen sein. Entscheidend ist der Zweck im Kontext. Informative und funktionale Bilder benötigen eine passende zugängliche Alternative.

Die Grenzen der Stichprobe

Der Prüfer wählte je Seite höchstens sechs unterschiedliche Bildadressen aus erkanntem Markup. CSS-Hintergründe, per Skript erzeugte Bilder und tatsächlich vom Browser ausgewählte responsive Varianten wurden damit nicht vollständig erfasst. Sechs Proben belegen auch nicht das Verhalten eines gesamten Auslieferdienstes.

Drei Datensätze enthalten keine erkannten Bilder: Stack Overflow antwortete mit 429, Allegro mit 403, und die gespeicherte Bund-Antwort lieferte keine Bildeinträge. Daraus folgt weder eine generell bildlose Seite noch ein Nachweis, dass zwei Seiten JavaScript benötigen. Ein verweigerter oder begrenzter Abruf beschreibt diesen Zugriffsversuch und keinen vollständigen Browserbesuch.

Eine Bildadresse begrenzt vergleichen

Das folgende Bash-Beispiel benötigt curl ab Version 8.4, file und GNU coreutils. Die Beispieladresse ist ein Platzhalter. Beide Anfragen verwenden GET, Weiterleitungen bleiben bei HTTPS, und jeder Download ist auf 10 MiB und 30 Sekunden begrenzt. Die Ergebnisse bleiben zur Auswertung in einem neu angelegten temporären Verzeichnis.

#!/usr/bin/env bash
set -euo pipefail
url='https://example.com/image.png'
out=$(mktemp -d)
printf 'Output: %s\n' "$out"
for variant in modern baseline; do
  if [ "$variant" = modern ]; then
    accept='image/avif,image/webp,image/jpeg,image/png;q=0.8,*/*;q=0'
  else
    accept='image/jpeg,image/png,image/avif;q=0,image/webp;q=0,*/*;q=0'
  fi
  curl --silent --show-error --fail --location \
    --proto '=https' --proto-redir '=https' --max-redirs 3 \
    --connect-timeout 10 --max-time 30 --max-filesize 10485760 \
    -H "Accept: $accept" -D "$out/$variant.headers" \
    -o "$out/$variant.body" \
    -w "$variant status=%{http_code} type=%{content_type} url=%{url_effective}\n" \
    "$url"
  file --mime-type "$out/$variant.body"
  wc -c < "$out/$variant.body"
  sha256sum "$out/$variant.body"
done
printf 'Full response headers: %s/*.headers\n' "$out"

Die Headerdateien enthalten auch Weiterleitungsantworten. Maßgeblich sind Vary, Cache-Control und gegebenenfalls ETag der letzten Antwort sowie der ausgegebene Status und die endgültige URL. file hilft bei der Formaterkennung, ersetzt aber keinen vollständigen Bilddekodiertest. Bevor ein Unterschied allein Accept zugeschrieben wird, sind Wiederholungen erforderlich.

Der Bild-Auslieferungs- und Formataushandlungs-Prüfer bietet einen Einstieg für ganze Seiten. Die für diesen Artikel geprüfte Implementierung verwendet weiterhin den beschriebenen GET/HEAD-Vergleich und die Näherung anhand der Quelltextreihenfolge. Das Ergebnis entspricht deshalb nicht dem Zwei-GET-Beispiel. Die Vary-Prüfung sucht zudem nach einer Teilzeichenfolge und kann Accept-Encoding falsch einordnen. Vor einer bestätigten Aussage zu Aushandlung oder Cache-Fehlern sind diese Grenzen zu berücksichtigen.