Caching kleiner Bilder

[Rainer]

Hier im Forum gibt es ja viele Themen die sich mit dem Deaktivieren des Browser-Caches beschäftigen.

Ich würde gerne wissen, ob man es auch umgekehrt beeinflussen kann, also dem Browser das Cachen von Bildern "empfehlen" kann.

Hintergrund: ich nutze Amazons S3 Service um Bilder nebst kleinen Vorschaubildern zu hosten.
Zumindest wenn ich mir den Cache meines Firefoxes (mit Standardeinstellungen) anschaue, entdecke ich im Cache aber immer nur die normalen, großen Bilder, nie aber die kleinen Vorschaubilder. Daher frage ich mich, ob die Standardbrowser in Standardeinstellungen Bilder unterhalb einer bestimmten Größe i.d.R. gar nicht erst cachen?

Diese Vorschaubilder werden nämlich sehr oft aufgerufen und fast die gesamten Kosten des S3 Services entstehen nicht durch das Speicher- oder Trafficvolumen, sondern durch die vielen Abfragen.

Daher stellt sich zunächst mal die Frage, ob es tatsächlich so eine Caching-Grenze gibt und bei wieviel KB die in Firefox und IE liegt?

Und gäbe es eine einfache Möglichkeit (Meta-Tags, Javascript, Header der Website [nicht Header beim Bildabruf]), über die Website das Caching für die darin befindlichen Bilder auch bei kleinen Bildern zu beeinflussen?

Eine Alternative wäre es vielleicht auch, die Vorschaubilder in besserer Qualität zu speichern, dies könnte Kosten sparen, sofern die Browser die Bilder dann eben wegen "ausreichender" Größe (meistens) cachen.

[bleicher]

Grüße,
afaik ist cahsen benutzer/browserabhängig und nur bedingt beinflusst werden kann (evtl kann cashauffrischung empfohlen werden))
MFG
bleicher

[Rainer]

afaik ist cahsen benutzer/browserabhängig und nur bedingt beinflusst werden kann

würd ich auch denken. klar, wenn ein paar browser auf irgendein meta-tag oder sonstwas reagieren würden, würde das natürlich auch schon ein bisschen sparen. allerdings müsste dann auch wirklich nur das verhalten in bezug auf die bilder beeinflussbar sein, das caching der übrigen website sollte davon nicht beeinflusst werden.

Zunächst mal wärs halt gut zu wissen ob es in Firefox und IE überhaupt tatsächlich Dateigrößen-Grenzen in Bezug auf Caching gibt... bevor ich versuch das empirisch rauszufinden, weiß jemand zufällig ob es die gibt und wo die standardmäßig liegen?

[Sven Rautenberg]

Moin!

afaik ist cahsen benutzer/browserabhängig und nur bedingt beinflusst werden kann

würd ich auch denken. klar, wenn ein paar browser auf irgendein meta-tag oder sonstwas reagieren würden, würde das natürlich auch schon ein bisschen sparen. allerdings müsste dann auch wirklich nur das verhalten in bezug auf die bilder beeinflussbar sein, das caching der übrigen website sollte davon nicht beeinflusst werden.

Browser verhalten sich im Allgemeinen deutlich gutmütiger und vorhersagbarer, als hier behauptet wird. Denn sie sind HTTP-Clients, die sich selbstverständlich an den HTTP-Standard zu halten haben.

Gewiß, ein Benutzer kann das grundsätzliche Caching-Verhalten seines Browsers einstellen - aber der Standard ist, dass Browser grundsätzlich cachen, sofern der Server das erlaubt bzw. nicht verbietet.

Zunächst mal wärs halt gut zu wissen ob es in Firefox und IE überhaupt tatsächlich Dateigrößen-Grenzen in Bezug auf Caching gibt... bevor ich versuch das empirisch rauszufinden, weiß jemand zufällig ob es die gibt und wo die standardmäßig liegen?

Vielleicht solltest du zuerst mal herausfinden, ob der Server das Caching nicht verbietet - dann mußt du deine Suche nach dieser ominösen Dateigrößengrenze nicht weiter betreiben.

- Sven Rautenberg

[Rainer]

Ein Browserprogrammierer könnte natürlich auf die Idee kommen, kleine Ressourcen aus irgendeinem Grund anders zu behandeln, als große Ressourcen - aber wenn, dann würde ich eher erwarten, dass diese kleinen Ressourcen nicht als Einzeldatei gespeichert werden, sondern in irgendeiner zusammenfassenden Datei, falls man damit mehr Performance gewinnen könnte.

Tatsächlich, gerade sind mir solche Dateien im Cache des Firefox aufgefallen, die Stylesheets, Scripte und auch Bilder zusammenfassen und die aktualisieren sich auch beim Laden neuer Vorschaubilder, also werden die Bilder wohl doch standardmäßig gecachet (im IE wirds wohl genauso laufen...)

Und der S3 Server sendet auch keine Header die das Caching beeinflussen.

...ich hab wohl einfach diese zusammenfassenden Caching-Dateien übersehen...

[Sven Rautenberg]

Moin!

Daher stellt sich zunächst mal die Frage, ob es tatsächlich so eine Caching-Grenze gibt und bei wieviel KB die in Firefox und IE liegt?

Ein Browserprogrammierer könnte natürlich auf die Idee kommen, kleine Ressourcen aus irgendeinem Grund anders zu behandeln, als große Ressourcen - aber wenn, dann würde ich eher erwarten, dass diese kleinen Ressourcen nicht als Einzeldatei gespeichert werden, sondern in irgendeiner zusammenfassenden Datei, falls man damit mehr Performance gewinnen könnte.

Tatsächlich ist mir noch nie etwas derartiges zu Ohren gekommen - also vermute ich, dass es nicht stattfindet.

Und gäbe es eine einfache Möglichkeit (Meta-Tags, Javascript, Header der Website [nicht Header beim Bildabruf]), über die Website das Caching für die darin befindlichen Bilder auch bei kleinen Bildern zu beeinflussen?

Nein, NUR über die HTTP-Header des Bildrequests kann man das Caching beeinflussen. Wenn Amazon sich überlegt hat, dass die kleinen Bilder nicht gecacht werden müssen/sollen/dürfen (warum auch immer), und du den Server nicht konfigurieren kannst, mußt du damit leben, wie es ist.

Eine Alternative wäre es vielleicht auch, die Vorschaubilder in besserer Qualität zu speichern, dies könnte Kosten sparen, sofern die Browser die Bilder dann eben wegen "ausreichender" Größe (meistens) cachen.

Da deine Grundannahme falsch ist, ist die Überlegung eines Lösungsansatzes logischerweise irreführend.

- Sven Rautenberg

[Tim Tepaße]

Hallo Rainer,

Ich würde gerne wissen, ob man es auch umgekehrt beeinflussen kann, also dem Browser das Cachen von Bildern "empfehlen" kann.

Empfehlungen zum Cachen sind ja in HTTP eingebaut und Browser berücksichtigen diese Empfehlungen auch. Einen guten Überblick, wie das auf der technischen Ebene genau funktioniert bietet Mark Nottinghams Caching Tutorial. Ich fasse mal zusammen: Für Ressourcen, die sich eh nie ändern, sollte man entweder einen Expires-Header mit einem Datum weit in der Zukunft setzen (der HTTP-Standard empfiehlt ein Jahr) oder aber noch besser den Cache-Control-Header mit einer möglichst langen Ablaufzeit (spezifiziert in Sekunden) zu setzen. Der Cache-Control-Header ist besser für Amazon (und prinzipiell besser); man muß einfach nicht einen neuen Expires-Header-spezifizieren, wenn der Termin in der Zukunft abgelaufen ist.

Noch kürzer: Du mußt diesen Header in die Antworten auf HTTP GET von Amazon S3 reinkriegen:

Cache-Control: max-age=2678400

2678400 Sekunden sind so ungefähr ein Monat; eine schon recht lange Zeitangabe finde ich.

Hintergrund: ich nutze Amazons S3 Service um Bilder nebst kleinen Vorschaubildern zu hosten. (...)
Diese Vorschaubilder werden nämlich sehr oft aufgerufen und fast die gesamten Kosten des S3 Services entstehen nicht durch das Speicher- oder Trafficvolumen, sondern durch die vielen Abfragen.

Mal neugierig gefragt: Lohnt sich das denn wirklich? Ich meinte seit der Preisänderungen damals, dass S3 sich eher mehr für größere Dateien lohnt denn für viele kleine Ressourcen. In diesem Thread im S3 Forum scheint man derselben Meinung zu sein.

Und gäbe es eine einfache Möglichkeit (Meta-Tags, Javascript, Header der Website [nicht Header beim Bildabruf]), über die Website das Caching für die darin befindlichen Bilder auch bei kleinen Bildern zu beeinflussen?

Header beziehen sich im Prinzip immer nur auf die Ressource, mit der sie ausgeliefert werden, insofern ist es viel geschickte wie oben schon gesagt einen zusätzlichen Header zu den Thumbnail-Antworten von S3 hinzuzufügen. Bei Webservern wie Apache, die meist einfach das Dateisystem abbilden, setzt man solche Metadaten wie Header in Konfigurationsdateien wie .htaccess (und z.B. der Direktive Header). Bei Amazon S3 geschieht das Speichern der Daten nicht über eine Dateisystemschnittstelle sondern über HTTP – und dort muss man die Metadaten mitschicken.

S3 hat ja eine auf dem Prinzip REST basierende Schnittstelle; das in diesem Kontext soviel bedeutet wie »die Möglichkeiten von HTTP voll ausnutzen«. Speichert man eine Textdatei, sieht der HTTP Request ungefähr so aus:

PUT /dingsbums HTTP/1.1
  Content-Length: 12
  Host: beispielbucket.s3.amazonaws.com
  Date: Thu, 06 Dec 2007 06:00:00 GMT
  Authorization: AWS Zugangsschluessel:Signatur
  Content-Type: text/plain
  Expect: 100-continue

Beispieltext

Die Methode PUT ist in HTTP so spezifiziert, dass der Server diverse Header im Request auch als mögliche Header in der Response des zu erstellenden, updatenden Ressource nutzen kann. S3 nutzt diese Möglichkeit z.B. für die beliebigen nutzerspezifischen Metadaten, mit denen man die gespeicherten Objekte ausstatten kann. Aber laut dem Abschnitt zu PUT im Developer-Guide gilt dies auch für diverse generelle HTTP-Header, u.a. auch Cache-Control. Ein Beispiel-PUT mit eingebautem zeitlosen Caching sähe also so aus:

PUT /hurz HTTP/1.1
  Host: beispielbucket.s3.amazonaws.com
  Date: Thu, 06 Dec 2007 06:00:00 GMT
  Authorization: AWS Zugangsschluessel:Signatur
  Content-Type: text/plain
  Content-Length: 5
  Expect: 100-continue
▶ Cache-Control: max-age=2678400
  x-amz-meta-author: Hape Kerkeling
  x-amz-meta-kategorie: Dichtkunst

Hurz!

Also: Einfach nur den passenden Cache-Control-Header im speichernden HTTP-Request unterbringen. Meine ich. Ich hab's jetzt mangels S3-Zugang nicht ausprobiert. Hatten die nicht mal eine Sandbox, in der man das ausprobieren konnte, ohne gleich Kreditkartendetails rüberzurücken oder irre ich mich da?

Solltest Du eine Bibliothek nutzen: Beim nicht sehr intensiven Drüberschauen scheinen die meisten wohl eine Möglichkeit zu haben, Header bzw. Metadaten zu setzen. Ich würde sie aber trotzdem erstmal ausprobieren. Die Header für die nutzerspezifischen Metadaten werden ja mit dem Präfix "x-amz-meta-" ausgestattet; ein schlampiger Programmierer könnte das einfach generell machen, ohne eine Ausnahme für die spezifischen nicht bepräfixten HTTP-Header zu machen.

Solltest Du eine Bibliothek nutzen, die die SOAP-API nutzt: Laut Dokumentation gibt es dort das Element <Metadata> in der PutObject Operation und laut Beispielen wird es auch für HTTP-Header wie Content-Type genutzt, könnte also wie bei den Headern der REST API funktionieren. Allerdings wird hier im S3 Forum gesagt, dass es bei SOAP nicht funktioniert. Vielleicht ist das wieder implementierungsabhängig → einfach ausprobieren.

Tim