Asset caching

Wenn wir jetzt schon mal dabei sind Cache-Fragen zu klären ... Eine meiner Kundenwebsites benutzt auf fast allen Unterseiten ein und das selbe statische Hintergrundbild, das per CSS gesetzt wird. Ich würde das gern aus dem Cache geladen haben, aber es liegt in /files und kommt also nicht aus /assets oder /bundles, wofür ja in der .htaccess die Cachezeit auf 1 Jahr gesetzt wird.

Was wäre hier best practice, wenn ich dieses Bild - oder auch andere Bilder, die direkt aus /files/... geladen werden, meinetwegen für 1 Tag oder 1 Monat im Browser cachen lassen will? Früher/tm), zu Contao 3 Zeiten gab es hierzu einen Abschnitt in der .htaccess, der das für die verschiedensten Dateitypen festgelegt hat. Es fallen mir zwar diverse Methoden ein, wie ich das wohl hinbekommen könnte, aber was ist die empfohlene Vorgehensweise? Analog zu /assets und /bundles in der .htaccess angeben (oder meinetwegen direkt im vHost)? Global vom Server für unterschiedliche Dateitypen im Response-Header ausgeben lassen? ...?

Zitat:

---

Zitat von tab

Was wäre hier best practice, wenn ich dieses Bild - oder auch andere Bilder, die direkt aus /files/... geladen werden, meinetwegen für 1 Tag oder 1 Monat im Browser cachen lassen will?

---

Das machst du immer noch über die htaccess

Sofern mod_expires existiert, kannst du sowas wie hier nutzen

PHP-Code:

---

<IfModule mod_expires.c>
    ExpiresActive On
    ExpiresByType image/webp "access plus 30 days"
    ExpiresByType image/gif "access plus 30 days"
    ExpiresByType image/ico "access plus 30 days"
    ExpiresByType image/jpeg "access plus 30 days"
    ExpiresByType image/jpg "access plus 30 days"
    ExpiresByType image/png "access plus 30 days"
   ...
</IfModule> 


---

Je nach Anwendungsfall natürlich. Contao kann deinen Server nicht kontrollieren

Dann aber vermutlich nicht mehr wie damals mit Expires-Headern oder würde das dann nicht mit den Assets (aus /assets) Probleme machen?

In wie fern sollte das Probleme machen? Welchen Unterschied siehst du hier überhaupt zwischen assets/ und files/? Da gibt es nämlich keinen (sobald die Datei in assets/ existiert).

Zitat:

---

Zitat von Spooky

In wie fern sollte das Probleme machen? Welchen Unterschied siehst du hier überhaupt zwischen assets/ und files/? Da gibt es nämlich keinen (sobald die Datei in assets/ existiert).

---

Sie existiert halt nicht in assets/, ich könnte sie natürlich einfach da reinschieben, damit wäre dieses spezifische Problem wahrscheinlich schon gelöst. Zumindest wenn mir die Systemwartung sie mir nicht wieder rauskickt. Andererseits will man ja in anderen Fällen eventuell nicht gleich auf 1 Jahr gehen, weil diese Dateien eben kein Hash im Dateinamen haben und auch nicht mit ?version aufgerufen werden. Wäre im CSS auch etwas unpraktisch. Wobei man das Hintergrundbild hier sicher nicht jeden Monat ändern wird.

Die aktuelle .htaccess enthält ja das hier:

Code:

---

<IfModule mod_headers.c>
        # Assets in /assets and /bundles either contain a hash in their filename
        # or are called with a ?version suffix, therefore cache them for 1 year.
        RewriteRule ^(assets|bundles)/ - [ENV=CONTAO_ASSETS:true]
        Header set Cache-Control "max-age=31536000" env=CONTAO_ASSETS

        # Allow CORS on the Contao TinyMCE skin.
        RewriteRule ^assets/tinymce4/js/skins/contao/fonts/ - [ENV=CONTAO_TINYMCE_SKIN:true]
        Header set Access-Control-Allow-Origin "*" env=CONTAO_TINYMCE_SKIN
    </IfModule>

---

Hat sich jetzt mit @zoglo überschnitten wie ich sehe. Genau so war das damals mit mod_expires drin. Die Frage wäre eben, ob sich das dann mit dem vorstehenden Teil der aktuellen .htaccess beisst, die ja für die möglicherweise selben Dateitypen in /assets Cache-Control Header erzeugt. Wenn dabei die zusätzlichen Expires-Header keinen Schaden anrichten, dann werde ich das wohl so machen, weil die Cachezeit abhängig vom Zugriff m.E. in dem Fall sowieso praktischer wäre. So hoch wie damals(tm) würde ich die Zeit aber auch gar nicht setzen wollen, eine Stunde oder zwei würde wohl schon was bringen. Will ja schliesslich nur bei Lighthouse die Performance gelegentlich von 100 auf 200 bringen :D;). Die Seite ist schon sehr schnell, weil insgesamt minimalistisch. Die 100KB Hintergrunddatei macht einen Großteil der Gesamtdaten aus, mehr als die Hälfte. Es stört mich halt, dass die Datei bei jeder neu geladenen Seite wieder geladen wird.

Zitat:

---

Zitat von tab

Die 100KB Hintergrunddatei macht einen Großteil der Gesamtdaten aus, mehr als die Hälfte. Es stört mich halt, dass die Datei bei jeder neu geladenen Seite wieder geladen wird.

---

Dann hast du Lighthouse nicht verstanden und solltest hier nicht "min-maxen". Die letzten Kratzer der Seite liegen hier an deinem "falschen" CSS, nicht an irgendeinem Cache.

Nutze keine background-images, lösche alle Bilder, nutze keine Slider, nutze kein JavaScript, nutze keine externen Dateien, nutze reines HTML -> 100/100 - et voila.
Wenn es dieses Thema ist, dann sollten wir dies in OffTopic verschieben und in Google Lighthouse for "Experts (or dummies)" umbenennen.

Zitat:

---

Zitat von zoglo

Dann hast du Lighthouse nicht verstanden und solltest hier nicht "min-maxen". Die letzten Kratzer der Seite liegen hier an deinem "falschen" CSS, nicht an irgendeinem Cache.

---

Also Lighthouse habe ich durchaus verstanden, ich weiss, dass da natürlich ganz sicher kein Browser-Caching verwendet wird beim Messen der Ladezeit. Das wäre ja wirklich mehr als nur sinnfrei. Und natürlich kann man mehr als 100 Punkte sowieso nicht bekommen. Sollte ich deswegen auf mögliche, weitere Optimierungen verzichten? Dann hättest du Lighthouse falsch verstanden.

Ich halte es für angebracht, als Ersteller einer Website das Browser-Caching zu nutzen, wo es sinnvoll genutzt werden kann. Und wenn es nur wäre, um den Website-Besuchern Zeit und Kosten zu sparen. Bei einer statischen Datei, die sich seit Jahren nicht geändert hat und die größere Hälfte der zu ladenden Daten ausmacht, bietet es sich eben an. Das hat mit Lighthouse erst mal nichts zu tun.

Zitat:

---

Zitat von tab

Und natürlich kann man mehr als 100 Punkte sowieso nicht bekommen. Sollte ich deswegen auf mögliche, weitere Optimierungen verzichten? Dann hättest du Lighthouse falsch verstanden.

---

Die Aussage "Die 100KB Hintergrunddatei..." sagt nur aus, dass du hier eher optimieren solltest.

Wie schon vorher erwähnt, dies ist dies der falsche Thread dafür. Fragen und Antworten über solche Optimierungen sollte man in einem neuen Thread erstellen, damit die Nachwelt auch was davon hat.
Auch gerne als Riesen-Sammel-Thread - Dann kann jeder darüber diskutieren was sinnvoll ist und alle haben was davon.

Zitat:

---

Zitat von zoglo

Die Aussage "Die 100KB Hintergrunddatei..." sagt nur aus, dass du hier eher optimieren solltest.

---

Also im Zweifel weglassen, oder ein anderes Bild (Motiv) verwenden, bliebe mir nicht viel anderes übrig. Ist so schon qualitativ relativ grenzwertig. Oder mit dem Bild und seinen Daten leben, was ich dann wohl einfach tun würde. Wäre auch nicht schlimm, die Ladezeit ist insgesamt ok.

Zitat:

---

Zitat von zoglo

Wie schon vorher erwähnt, dies ist dies der falsche Thread dafür. Fragen und Antworten über solche Optimierungen sollte man in einem neuen Thread erstellen, damit die Nachwelt auch was davon hat.
Auch gerne als Riesen-Sammel-Thread - Dann kann jeder darüber diskutieren was sinnvoll ist und alle haben was davon.

---

Hier gebe ich dir völlig Recht. Es gibt ja sogar schon einen passenden Thread, zumindest vom Titel her, wie mir gerade wieder eingefallen ist. Muss ihn nur erst wieder finden. Und dann auch erst noch so einiges testen.

Moderation: Beiträge in einen eigenen Thread verschoben, da es nichts mit dem HTTP Cache zu tun hat.

Danke für die Abtrennung vom anderen Thread. Der jetzige Titel trifft das Problem(?) um das es mir hier geht, schon recht gut.
Die meisten Assets sind ja beim Thema Caching im Browsercache, durch den weiter oben erwähnten Abschnitt der von Contao bei der Installation mitgelieferten .htaccess im public-Verzeichnis bestens versorgt. Nicht versorgt sind durch diesen Abschnitt aber Dateien unter files/, die z.B. von CSS benutzt werden (wie eben mein Hintergrundbild). Aber auch bei Bildern mit Bildgrößen bei Verwendung von srcset, wo eines der Bilder Originalgröße hat, wird dieses Bild in Originalgröße (=Originalbild) direkt aus files/ geholt.

Eine mögliche Lösung könnte sein, einen weiteren Abschnitt anzulegen, der dafür sorgt, dass Dateien aus files/ - entweder generell (eventuell problematisch) oder beschränkt auf spezelle Unterverzeichnisse oder gar einzelne Dateien - ebenfalls für 1 Jahr (oder welcher Zeitraum auch immer im Einzelfall sinnvoll sein mag) im Browsercache gespeichert werden.

Ich kann mich zwar dunkel daran erinnern, vor einigen Jahren schon einmal erfolglos versucht zu haben, mod_expires zu verwenden, wogegen Contao sich dann etwas gewehrt hat. Das betraf aber, wenn ich mich recht erinnere, von Contao erzeugte Seiten und nicht Assets. Auch das werde ich nochmal mit Assets aus files/ testen.
Ich werde mir für diese Tests jetzt erst einmal eine kleine Contao 5.3 Website einrichten.

Bin aber auch für andere funktionierende Workarounds natürlich jederzeit offen. Wenn es also z.B. eine praxistaugliche Möglichkeit gibt, diese Assets (automatisch?) nach assets/ zu verschieben (wohin sie eigentlich sowieso gehören, wie der Name schon sagt), dauerhaft und mit einem festen Pfad und Dateinamen, den ich dann z.B. im CSS verwenden kann, immer gerne her damit! Spart mir dann einiges an Testerei und auch das Studium von weiterführenden Dokus jenseits der Contao-Doku - einschliesslich des zum Verständnis dieser Dokus wiederum notwendigen Wissens. Da ist man schnell mal einige Tage oder gar Wochen unterwegs, im Endeffekt meist interessant und lohnend, aber die zur Verfügung stehende Zeit ist eben endlich. Und mein Ziel ist es ja nicht der größte, lebende Experte in Sachen Caching zu werden, sondern nur, unnötige Zugriffe auf den Webserver weitestgehend zu vermeiden. Was ja kein besonders exotisches Ziel sein sollte.

Die Standard .htaccess ist bare bones. Du könntest dir für eine produktive Umgebung Dinge aus den Server Configs des HTML5 Boiler Plate Projektes nehmen.

https://github.com/h5bp/server-configs-apache

Ich glaube @tab hat eher Bedenken, dass er mit zusätzlichem caching für z.B. jpg das caching von contao "aushebelt".

@tab Ich habe in mehreren Installationen einen Block

Code:

---

<IfModule mod_expires.c>
        ExpiresActive on
        ExpiresByType image/jpg "access plus 1 year"
        ExpiresByType image/svg "access plus 1 year"
        ...
</IfModule>

---

für Ressourcen drin, die nicht über Contao prozessiert werden können.
Ich habe dabei keine negativen Einflüsse auf das Caching von Contao bemerkt.
Wenn ich Dich richtig verstanden habe geht es Dir doch genau darum.

Danke für den Link. Nachdem ich die ETags aus den Headern rausgenommen habe scheint es in Firefox zu funktionieren. Chrome bleibt hartnäckig, da steht schon in den Anfrageheadern

Code:

---

Cache-Control: no-cache
Pragma: no-cache

---

Dazu habe ich gefunden, dass Chrome wohl grundsätzlich beim Server anfragt um festzustellen, ob die Ressource unverändert ist. Die Fundstelle ist aber schon was älter und das scheint mir auf Anhieb auch kein besonders sinniges Konzept zu sein. Aber gut, Google sollte sich hoffentlich was dabei gedacht haben. Ok, wenn Chrome dann zumindest nach dem Check die Datei nicht neu runterlädt ist es wenigstens ein Fortschritt. Trotzdem, nicht checken ist noch schneller und erspart dem Server eine Anfrage.

Jedenfalls meckert Lighthouse jetzt nicht mehr darüber. Ich hatte zunächst eine Cachezeit von 2 Monaten angegeben, das war ihm wohl zu kurz und er hat weiterhin darauf hingewiesen, bei 1 Jahr ist er jetzt zufrieden.

Zitat:

---

Zitat von mlweb

Ich glaube @tab hat eher Bedenken, dass er mit zusätzlichem caching für z.B. jpg das caching von contao "aushebelt".

@tab Ich habe in mehreren Installationen einen Block

Code:

---

<IfModule mod_expires.c>
        ExpiresActive on
        ExpiresByType image/jpg "access plus 1 year"
        ExpiresByType image/svg "access plus 1 year"
        ...
</IfModule>

---

für Ressourcen drin, die nicht über Contao prozessiert werden können.
Ich habe dabei keine negativen Einflüsse auf das Caching von Contao bemerkt.
Wenn ich Dich richtig verstanden habe geht es Dir doch genau darum.

---

Genau, das waren u.a. meine grundsätzlichen Bedenken. Weiterhin auch das deaktivieren der ETags, was ja in der von @Spooky verlinkten Boiler Plate drinsteht und auch früher(tm) dort schon empfohlen wurde. Das habe ich zu Contao 3 Zeiten wie empfohlen deaktiviert und jetzt in einer Kopie der Website auch. Sieht dort jetzt auch nicht so aus, als ob der von Contao verwaltete Cache sich daran stören würde.

Eventuell ist dir sogar beholfen, wenn du die Artikel dementsprechend stylen kannst, sodass richtige Bilder anstatt background-image genutzt werden - Würde mit position absolute und object-fit: cover auch gehen (Dann geht auch lazyloading und der Kunde kann es einstellen :))
Wäre aber wieder ein anderer Thread <3

Zitat:

---

Zitat von tab

Chrome bleibt hartnäckig, da steht schon in den Anfrageheadern

Code:

---

Cache-Control: no-cache
Pragma: no-cache

---

---

Vermutlich hattest du die Dev Tools offen und das dort so eingestellt (ist Default).

Wenn das Default ist, dann muss ich die Einstellung kontrollieren und ggf ändern. Kann mich jedenfalls nicht erinnern, dazu mal was eingestellt zu haben. Gerade mal erledigt. Peinlich, das wird ja direkt im Fenster der Dev Tools eingestellt und angezeigt. Kästchen "Cache deaktivieren" und natürlich ist der Haken drin. Keine Ahnung, wie man so etwas übersehen kann. :rolleyes:. Kaum umgestellt, schon steht da bei der Größe "Speicher-Cache", wie es sich gehört. Anyway, die Funktion an sich hat dann ja schon davor auch in Chrome richtig funktioniert.

Bliebe noch die Frage, ob das deaktivieren der ETags Contao und seinen Cache in irgendeiner Form tangiert, also in der .htaccess wie in der Boilerplate

Code:

---

<IfModule mod_headers.c>
    Header unset ETag
</IfModule>
FileETag None

<IfModule mod_expires.c>
  ExpiresActive on
  ...

---

Ich gehe aber mal daon aus, dass Contao das entweder nicht benutzt oder ansonsten die Header sowieso selbst setzt. Negativ aufgefallen ist mir jedenfalls bisher nichts. Wenn das so bleibt, dann kann ich hier demnächst einen Haken dranmachen und das bei anderen produktiven Installationen nachziehen.