Page Speed für Firebug

[catcat]

Ich hab da beim PageSpeed Test diese Meldung aus der ich nicht schlau werde:

Code: Alles auswählen

Leverage browser caching
The following resources are missing a cache expiration. Resources that do not specify an expiration may not be cached by browsers. Specify an expiration at least one month in the future for resources that should be cached, and an expiration in the past for resources that should not be cached:

Wo kann ich eigentlich die "cache expiration"-Zeit eintragen?
In die .htaccess?
In jede der php-Dateien, die beanstandet werden?
In die php.ini?
In den header?

Baum.

[Synonym]

Also dabei geht es um Angaben wie "Expires: Sat, 23 Jan 2010 08:28:43 GMT" in Verbindung mit "Cache-Control"

Per Apache kannst Du das mit dem mod_expires erreichen, ist allerdings nur für statische Objekte sinnvoll (meine Meinung). Für PHP Geschichten finde ich persönlich eine Lösung über Etag besser.

Ansonsten, ja, in der php.ini geht das, in der .htaccess auch oder eben über PHP mit header().

Nachtrag: PageSpeed finde ich da auch etwas doof, denn der bemängelt immer wenn ein Expires fehlt. YSlow ist da besser, dem reicht auch ein vorhandenen Etag, bzw. bemängelt es sogar wenn beides vorhanden ist.

Nachtrag 2: https://code.google.com/speed/page-spee ... serCaching
https://developer.yahoo.com/performance ... ml#expires

[Mork vom Ork]

Also dabei geht es um Angaben wie "Expires: Sat, 23 Jan 2010 08:28:43 GMT" in Verbindung mit "Cache-Control"

Nein, Cache-Control ersetzt Expires. Expires impliziert eine Speicherbarkeit, ansonsten würde ein Verfallsdatum keinen Sinn machen. Cache-Control erlaubt lediglich eine feinere Steuerung der Caches.

Für PHP-Geschichten finde ich persönlich eine Lösung über Etag besser.

Das sind zwei paar Schuhe. Expires setzt ein Verfallsdatum, d.h. bis zu diesem Datum brauchen die Daten nicht mehr abgerufen werden. ETag bzw. Last-Modified bieten hingegen eine Möglichkeit, eine Cache-Kopie mit dem Original abzugleichen, ohne die Daten komplett runterladen zu müssen. Das eine ist kein Ersatz für das andere und insbesondere ist ETag/Last-Modified alleine nutzlos, es müssen auch bedingte Anfragen verarbeitet, d.h. mit einem Not Modified beantwortet werden können.

Oder, kurz und bündig auf Englisch:

Nachtrag 2: https://code.google.com/speed/page-spee ... serCaching

„It is important to specify one of Expires or Cache-Control max-age, and one of Last-Modified or ETag, for all cacheable resources. It is redundant to specify both Expires and Cache-Control: max-age, or to specify both Last-Modified and ETag.“

Wo kann ich eigentlich die "cache expiration"-Zeit eintragen?

Das hängt davon ab, was du willst. Am sinnvollsten ist es, wenn du erstmal den ganzen Kram, den man sowieso nur einmal runterladen muss, mit einem Expires versiehst, Bilder, CSS- und Javascript-Dateien, alles was statisch ist. Dafür brauchst du mod_expires und dieses steuert man, wie den gesamten Server, über die .htaccess und die anderen Konfigurationsdateien.

Wie du mit PHP-Skripten umgehst, kommt auf deren Funktion an. Es gibt Skripte, die liefern bei jedem Aufruf geänderte Daten, bei anderen ist eine Cache-Zeit zu verschmerzen (Expires; ich habe meine HTML-Daten beinahe ausnahmslos mit einer Stunde Verfallszeit).

ETag oder Last-Modified last but not least bringt dir wie oben schon geschrieben nur etwas, wenn deine Skripte auch bedingte Anfragen verarbeiten können.

[catcat]

Wenn ich also Browsern bei bestimmten Dateien sagen will: "Die kann 30 Tage im cache bleiben", dann nehm ich cache-control?

[Mork vom Ork]

Wenn ich also Browsern bei bestimmten Dateien sagen will: "Die kann 30 Tage im cache bleiben", dann nehm ich cache-control?

Cache-Control: max-age oder einfach Expires, ja.

[Synonym]

Nein, Cache-Control ersetzt Expires

Warum?

This module controls the setting of the Expires HTTP header and the max-age directive of the Cache-Control HTTP header in server responses

Wenn mod_expires verwendet wird, dann wird neben dem Expires auch das Cache-Control automatisch gesetzt inkl. max-age.

[catcat]

Na witzig^^
Bei mit steht im Antwort-Header:

Date: Sat, 23 Jan 2010 11:37:44 GMT
Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8i DAV/2 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
X-Powered-By: PHP/5.2.9
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Encoding: gzip
Vary: Accept-Encoding
blablabla...

[Mork vom Ork]

Nein, Cache-Control ersetzt Expires

Warum?

Weil das so ist, lies es nach:
„If a response includes both an Expires header and a max-age directive, the max-age directive overrides the Expires header“
https://www.w3.org/Protocols/rfc2616/rf ... #sec14.9.3

Expires zusammen mit einem das Caching verbietenden Cache-Control-Wert (no-cache, no-store, must-revalidate) macht keinen Sinn, weil Expires das Caching impliziert:
„The presence of an Expires header field with a date value of some time in the future […] indicates that the response is cacheable“
https://www.w3.org/Protocols/rfc2616/rf ... l#sec14.21

Wenn mod_expires verwendet wird, dann wird neben dem Expires auch das Cache-Control automatisch gesetzt inkl. max-age.

Weil es Browser geben könnte, die nur HTTP 1.0 können, Cache-Control gibt es erst seit HTTP 1.1 - als besser steuerbarer Ersatz für Expires: und Pragma:no-cache.

[FloM]

Ich bin echt schockiert, seit ich weiß, dass unsere sämtlichen Bilder anscheinend nicht gecached werden. Ich dachte dabei würde einfach dem Browser/Proxy übermittelt, wie alt das Bild ist, damit dieser selbst entscheiden kann, ob er es neu laden muss oder nicht? Wozu das ganze Spektakel mit der manuellen Festlegung? Oder verstehe ich hier was falsch?

[Mork vom Ork]

Ich dachte dabei würde einfach dem Browser/Proxy übermittelt, wie alt das Bild ist, damit dieser selbst entscheiden kann, ob er es neu laden muss oder nicht?

Das ist so bei statischen Dateien, mit Bildern per se hat das nichts zu tun. Bei statischen Dateien kann der Webserver das letzte Änderungsdatum einfach ermitteln (verwaltet das Betriebssystem in den Dateiattributen), sendet es entsprechend per Last-Modified an den Browser und kümmert sich auch um daran anschließende bedingte Anfragen, d.h. jene, bei denen der Browser sagt, er möchte die Daten nur haben, wenn sie seit seiner letzten Anfrage geändert wurden.

Wozu das ganze Spektakel mit der manuellen Festlegung? Oder verstehe ich hier was falsch?

Hier geht's um zwei Dinge:

1. Die letzte Änderung (Last-Modified, If-Modified-Since). Bei statischen Dateien macht das, wie beschrieben, komplett der Webserver, bei Skripten musst du dich jedoch selbst darum kümmern, denn was in der Skriptdatei drinsteht (sieht der Browser nie) und was es an den Browser ausgibt (relevant für des Browsers Cache), sind natürlich zwei Paar Schuhe.

2. Das Verfallsdatum (Expires). Das Verfallsdatum bestimmt, bis wann der Browser überhaupt nicht mehr beim Server anfragen muss, d.h. selbst wenn eine Datei inzwischen geändert wurde, bekommt der Browser das (je nach Browser-Einstellung) nicht mit, solange er die Daten noch im Cache hat und der Verfall nicht erreicht ist. Bei Punkt 1 sind hingegen immer noch kurze Prüfanfragen an den Server vorgesehen.
Der Webserver kann nicht wissen, für wie lange deine Daten brauchbar sind, daher musst du diese Angabe in jedem Falle selbst erledigen.

Ich bin echt schockiert, seit ich weiß, dass unsere sämtlichen Bilder anscheinend nicht gecached werden.

Nun, da müsste zuerst geprüft werden, ob es nur anscheinend so ist oder tatsächlich.

[FloM]

Ich bin echt schockiert, seit ich weiß, dass unsere sämtlichen Bilder anscheinend nicht gecached werden.

Nun, da müsste zuerst geprüft werden, ob es nur anscheinend so ist oder tatsächlich.

Wie kann ich das prüfen? Ich bin stutzig geworden, weil mir firebug mit rotem Ausrufezeichen anzeigt, dass einige Bilder und js-Dateien keine cache expiration haben.

Für mich ergeben diese Meldungen unter den neuen Erkenntnissen eigentlich keinen Sinn. Auch folgende nicht:

The following cacheable resources have a short freshness lifetime. Specify an expiration at least one month in the future for the following resources:

* https://www.google-analytics.com/ga.js

Favicons should have an expiration at least one month in the future:

[Nullpointer]

Bei JavaScript und oder CSS Dateien haben sich Versionsnummern bezahlt gemacht.
Die Datei kann beliebig lange gecached werden. Ich muss im Deployment halt dafür sorgen, dass die Versionsnummer geändert wird. Kann man natürlich auch bei Grafiken und anderen statischen Dateien so machen.