4.9.x Fragen zum privaten Cache (Browsercache)

Fragen zum privaten Cache (Browsercache)

Ich habe heute mal wieder eine 4.8 Installation auf 4.9.2 angehoben. Hat auch soweit funktioniert. Allerdings verstehe ich das Verhalten des Browsers in Bezug auf den Browsercache nicht. Ich habe den shared Cache auf 1 Jahr gestellt, soll ja trotzdem bei Änderungen der Seite automatisch neu generiert werden. Den ~~public~~ private Cache habe ich auf 1 Stunde eingestellt, muss ja nicht immer alles vom Server geladen werden, wenn da einer die Seiten hin- und her klickt. Nach meinem Verständnis sollten jetzt die Seiten beim ersten Zugriff vom Server geladen werden, bei weiteren Zugriff innerhalb einer Stunde sollte die Seite aus dem Browsercache genommen werden. Das funktioniert scheinbar auch. Aber ... warte ich jetzt länger als eine Stunde und greife dann nochmal zu, sollte wieder zuerst vom Server aus dem shared Cache geladen werden. Das funktioniert auch. Allerdings beim nächsten Zugriff auf die Seite lädt er diese wieder aus dem shared Cache anstatt aus dem Browsercache. Sollte er aber doch eigentlich, schliesslich hat der Browser die Seite erst vor wenigen Sekunden vom Server geladen. Jetzt lädt er sie forwährend immer wieder vom Server, das macht aus meiner Sicht keinen Sinn :confused:. Es klappt offenbar nur, wenn im Response-Header Age < 3600 ist. Age ist dabei offenbar das "Alter" der Seite im shared Cache.

Brauche ich da Expires Header wie bei Contao 3 oder wie kann ich das gewünschte Verhalten hinbekommen? Das gewünschte Verhalten wäre, dass immer nach Herunterladen einer Seite vom Server (oder shared Cache) die Seite danach 1 Stunde lang aus dem Browsercache genommen wird. Danach wird wieder einmal vom Server geladen und dann wieder für eine Stunde aus dem Browsercache.

Contao sollte die korrekten Header bereits setzen. Es kann aber sein, dass deine Serverkonfiguration (bspw. .htaccess) diese Header noch zusätzlich ändert.

Oh, ich sehe gerade, dass das wohl noch die .htaccess von 4.8.7 ist. Muss ich auf jeden Fall noch nachziehen. Ist ein Kundenaccount bei Webgo. Zum Thema Headers steht in der momentanen .htaccess aber auch nur drin

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_TINYM$ Header set Access-Control-Allow-Origin "*" env=CONTAO_TINYMCE_SKIN </IfModule>

So, alles nachgezogen, steht bei den Headers in der neuen .htaccess aber auch nichts anderes drin. Sämtliche Caches habe ich jedenfalls geleert, verhält sich bisher genauso wie zuvor, also in der ersten Stunde jedenfalls korrekt. Spannend wird es dann erst wieder in einer Stunde.

Tja, das mag so gedacht sein, macht aber so keinen Sinn. Da kann ich auch gleich auf den Browsercache verzichten. Nach gut einer Stunde habe ich die Seiten nochmal aufgerufen über die Navigation, also nicht mit reload oder sowas. Was funktioniert hat wie erhofft: Die Seiten wurden aus dem shared Cache geladen. Was nicht so funktioniert hat: Auch nach mehrmaligem hin- und her navigieren wird die Seite nicht mehr aus dem Browsercache geladen, sondern eben immer aus dem shared Cache. Das kann es also wohl nicht sein, Sinn macht es jedenfalls so keinen.

Edit: Hmm, vielleicht ist es ja auch ein Browserding, muss ich morgen noch mit anderen Browsern außer Firefox probieren.

Überprüfe die Response Header bspw. mit cURL.

Also in Google Chrome ist es das selbe Spiel. Dann kann ich ja mit Firefox weitermachen.

Antwortkopfzeilen (Firefox)

Code:

HTTP/1.1 200 OK Server: nginx Date: Mon, 11 May 2020 07:06:38 GMT Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Connection: keep-alive Vary: Accept-Encoding contao-merge-cache-control: 1 Cache-Control: max-age=3600, public, s-maxage=31536000 vary: Cookie x-content-type-options: nosniff referrer-policy: no-referrer-when-downgrade, strict-origin-when-cross-origin x-frame-options: SAMEORIGIN x-xss-protection: 1; mode=block x-content-digest: en5c7abc2ba866bbef450eae04841fce1dcad6150d0e67cac3a9568b375e469e98 Age: 28820 Contao-Cache: fresh Content-Encoding: gzip

Anfragekopfzeilen (Firefox)

Code:

Host: www.example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:76.0) Gecko/20100101 Firefox/76.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Language: de,en;q=0.5 Accept-Encoding: gzip, deflate, br Referer: https://www.example.com/page1.html DNT: 1 Connection: keep-alive Upgrade-Insecure-Requests: 1

Edit: Kann das mit der speziellen Konfiguration bei Webgo zusammenhängen? Dann probiere ich es bei anderen Hostern.

Die Header sind korrekt. Die Browser sollten die Seite für 3600 Sekunden nach dem ersten non-cached Request aus dem Browser Cache laden.

Das tun sie auch. Aber nur nach dem ersten Laden, genau eine Stunde lang. Dann wird wieder vom Server aus dem shared Cache geladen. Das führt dann aber nicht dazu, dass die Seite für eine weitere Stunde aus dem Browser Cache geladen wird, sondern es wird nur noch vom Server geladen. Mein Eindruck ist, dass es am Age Header liegt. Wenn das Alter größer ist als 3600, dann sehen die Browser die Seite offenbar als nicht mehr "frisch" an und laden sie dann eben jedes Mal wieder vom Server. Deswegen meine Frage wegen Expires-Header.

Der Age Header ist nur für Proxies relevant, nicht für den Browser. Ein etwaiger Expires Header wird durch den Cache-Control Header überschrieben. Hier ist das gut erklärt: https://developer.mozilla.org/en-US/.../Cache-Control

Cache-Control: max-age=3600, public, s-maxage=31536000 bedeutet also:

max-age=3600: Private Caches können den Response 3600 Sekunden nach dem initialen Request aus dem eigenen Cache laden.
public: Der Response kann von Private & Public Caches gespeichert werden.
s-maxage=31536000: Der Response kann von Public Caches für 31536000 Sekunden nach dem ersten Speichern aus dem eigenen Cache geladen werden.

Habe ich schon Dutzende Male gelesen und versucht, das was ich dort lese mit den praktischen Erfahrungen in Einklang zu bringen. Das gelingt mir offenbar nicht, denn mittlerweile kann ich die heute Nacht erzeugten Seiten nicht mehr aus dem shared Cache laden, so dass der Browser sie in seinem Cache speichert und auch daraus nimmt für darauffolgende Requests. So oft ich es auch lese komme ich zu dem Schluss, dass es eigentlich funktionieren sollte wie gewünscht. Aber das tut es eben nicht. Deswegen machen es entweder alle Browser falsch oder ich verstehe es falsch. Und da gehe ich eben zunächst mal vom Letzteren aus.

Zitat:

max-age=3600: Private Caches können den Response 3600 Sekunden nach dem initialen Request aus dem eigenen Cache laden.

Da stellt sich mir z.B. die Frage, was ist der "initiale Request"? Ist der erste Request, nachdem der Browser Cache zu alt ist, wieder ein initialer Request oder sagt der Browser: "Jetzt habe ich die Seite neu runtergeladen, aber nichts Anderes bekommen als ich schon hatte, also lade ich es jetzt solange neu runter, bis sich was ändert (sei es im Inhalt oder in den Response Headern)". Sinnvoll wäre das nicht, jedenfalls verstünde ich den Sinn dahinter nicht. Aber offenbar passiert irgendwas in der Art.

Gemeint ist einfach der letzte Request and den Server. Wenn der Browser den Inhalt aus dem Private Cache lädt, wird ja kein Request an den Server gesendet. Nach Ablauf von max-age relativ zum letzten Request muss der Browser wieder einen neuen Request an den Server senden.

Das heißt dann, dass es eigentlich funktionieren sollte, was es aber nicht tut. Weder mit Firefox noch mit Google Chrome. Die cachen doch sonst alles was ihnen in die Finger kommt. CSS, JS, Bilder, kein Problem. Klar, ich weiss, dass das von Contao anders gehandlet wird als das dynamisch erzeugte HTML. Ich frage mich halt, warum die trotz der Response Header hier offenbar entweder nicht cachen wollen/können oder den Cache danach nicht mehr als frisch betrachten.

Du bist aber nicht gleichzeitig im Backend eingeloggt?

Wie testest du überhaupt, ob der Browser einen Request sendet oder nicht? Idealerweise benutzt du dafür ein Private Browsing Window und analysierst die Access Logs des Web Servers.

Zitat:

Zitat von mlweb

Du bist aber nicht gleichzeitig im Backend eingeloggt?

Nein, und ich lösche auch grundsätzlich alle Cookies und Caches und mache alle Browserfenster zu, bevor ich den Test starte. Vielleicht habe ich ja irgendwelche verqueren Browser-Einstellungen, Adblock Plus habe ich schon deaktiviert, aber es ist unwahrscheinlich, weil es mit neu erzeugtem Shared Cache eine Stunde lang funktioniert. Ich probiere es aber mal mit dem Notebook, das hat die Seite vorher noch nie geladen.

Zitat:

Zitat von tab

Ich probiere es aber mal mit dem Notebook, das hat die Seite vorher noch nie geladen.

So, das Notebook lädt die Seiten gleich von Anfang an nicht aus dem Browsercache, sondern grundsätzlich nur aus dem Shared Cache. Wenn ich jetzt den Shared Cache leere, dann wird es wieder funktionieren, aber nur für eine Stunde und dann nie wieder. Ok, vielleicht nach einem Jahr wieder, wenn der Shared Cache erneuert wird. :);)

Hmm, hat mir jemand eine URL zur Hand, wo Shared und Private Cache aktiviert sind, damit ich mir mal anschauen kann, ob das mit meinen Browsern da besser aussieht? Ist ja eine tückische Sache, weil es anfangs funktioniert wie erwartet und man es deshalb nicht unbedingt gleich merkt. Ich dachte anfangs auch alles ist ok :rolleyes:. Ist in meinem aktuellen Fall jetzt nicht so dramatisch, die Seite kann auch bequem ohne Browsercache betrieben werden, so groß sind da die Besucherzahlen nicht.:D Die liegen monatlich eher im niedrigen dreistelligen Bereich.

Zitat:

Zitat von tab

Ich habe den shared Cache auf 1 Jahr gestellt, soll ja trotzdem bei Änderungen der Seite automatisch neu generiert werden. Den public Cache habe ich auf 1 Stunde eingestellt, muss ja nicht immer alles vom Server geladen werden, wenn da einer die Seiten hin- und her klickt.

Könntest du das ggf. noch korrigieren, um die Verwirrung nicht größer als notwendig werden zu lassen :confused:

Zitat:

Zitat von tab

Hmm, hat mir jemand eine URL zur Hand, wo Shared und Private Cache aktiviert sind, damit ich mir mal anschauen kann, ob das mit meinen Browsern da besser aussieht?

Ich habe auf meiner Seite "derastronaut . de" beide Cache-Varianten aktiviert.

Shared: 30 Tage
Private: 60 Minuten

Hmm. Die 30 Tage sehe ich im Response-Header nicht. Ich bekommen die Seiten auch nicht aus dem Cache, weder shared noch private.

Code:

HTTP/2 200 OK date: Wed, 20 May 2020 09:29:24 GMT server: Apache contao-merge-cache-control: 1 cache-control: max-age=3600, private vary: Cookie,Accept-Encoding,User-Agent x-content-type-options: nosniff referrer-policy: no-referrer-when-downgrade, strict-origin-when-cross-origin x-frame-options: SAMEORIGIN x-xss-protection: 1; mode=block contao-cache: miss age: 0 strict-transport-security: max-age=31536000 cache-control: max-age=0 expires: Wed, 20 May 2020 09:29:24 GMT content-encoding: br content-type: text/html; charset=utf-8 X-Firefox-Spdy: h2

Das ist mein Ergebnis aus dem Tool vom Firefox. Im Backend war ich nicht eingeloggt. Sieht deinem Ergebnis ziemlich ähnlich. Contao ist mit Version 4.9.3 aktuell.

Code:

HTTP/2 200 OK date: Wed, 20 May 2020 09:59:29 GMT server: Apache contao-merge-cache-control: 1 cache-control: max-age=3600, private vary: Cookie,Accept-Encoding,User-Agent x-content-type-options: nosniff referrer-policy: no-referrer-when-downgrade, strict-origin-when-cross-origin x-frame-options: SAMEORIGIN x-xss-protection: 1; mode=block contao-cache: miss age: 0 strict-transport-security: max-age=31536000 cache-control: max-age=0 expires: Wed, 20 May 2020 09:59:29 GMT content-encoding: br content-type: text/html; charset=utf-8 X-Firefox-Spdy: h2

Woran erkennst du denn, ob was aus dem Cache kommt und was nicht? "cache-control: max-age=3600, private" sieht für mich nach den 60 Minuten Private-Cache aus. Weiter unten ist noch "cache-control: max-age=0". Soll das der Server-Cache sein? Sorry, habe nicht wirklich Ahnung von dem Thema, bin aber mit Interesse dabei ;)

Kann die htaccess vielleicht etwas damit zu tun haben? Habe aus älterer htaccess ein paar Sachen übernommen und vor kurzem auf raten von Google Pagespeed, GTmetrix und Konsorten noch etwas an den "ExpiresByType"-Werten gefeilt. Nicht, dass etwas dazwischen funkt oder eine Fehlkonfiguration irgendwo anders besteht.

Code:

## # Configs Server ## #AddHandler php56-cgi .php php_value memory_limit 512M php_value max_execution_time 600 AddDefaultCharset UTF-8 php_value session.save_path /www/htdocs/w012345/tmp/ ### <IfModule mod_headers.c> # Allow access from all domains for webfonts (see contao/core-bundle#528) <FilesMatch "\.(ttf|ttc|otf|eot|woff2?|font\.css)$"> Header set Access-Control-Allow-Origin "*" </FilesMatch> </IfModule> ## # Disable ETags # @see http://developer.yahoo.com/performance/rules.html#etags ## FileETag None <IfModule mod_headers.c> Header unset ETag </IfModule> ## # Set the proper MIME types # @see https://github.com/h5bp/html5-boilerplate ## <IfModule mod_mime.c> AddType application/javascript js jsonp AddType application/json json AddType audio/ogg oga ogg AddType audio/mp4 m4a f4a f4b AddType video/ogg ogv AddType video/mp4 mp4 m4v f4v f4p AddType video/webm webm AddType video/x-flv flv AddType image/svg+xml svg svgz AddEncoding gzip svgz AddType application/vnd.ms-fontobject eot AddType application/x-font-ttf ttf ttc AddType font/opentype otf AddType application/x-font-woff woff woff2 AddType image/x-icon ico AddType image/webp webp AddType text/cache-manifest appcache manifest AddType text/x-component htc AddType application/xml rss atom xml rdf AddType application/x-web-app-manifest+json webapp AddType text/x-vcard vcf AddType application/x-shockwave-flash swf </IfModule> ## # Gzip compression # @see https://github.com/h5bp/html5-boilerplate ## <IfModule mod_deflate.c> <IfModule mod_filter.c> AddOutputFilterByType DEFLATE text/html text/plain text/css application/json AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE text/xml application/xml text/x-component AddOutputFilterByType DEFLATE application/xhtml+xml application/rss+xml application/atom+xml AddOutputFilterByType DEFLATE image/x-icon image/svg+xml application/vnd.ms-fontobject application/x-font-ttf font/opentype </IfModule> </IfModule> ## # Expires headers (for better cache control) # @see https://github.com/h5bp/html5-boilerplate ## <IfModule mod_expires.c> ExpiresActive on ## # Productional website ## ExpiresByType text/cache-manifest "access plus 0 seconds" ExpiresByType text/html "access plus 0 seconds" ExpiresByType text/xml "access plus 0 seconds" ExpiresByType application/xml "access plus 0 seconds" ExpiresByType application/json "access plus 0 seconds" ExpiresByType application/rss+xml "access plus 1 hour" ExpiresByType application/atom+xml "access plus 1 hour" ExpiresByType image/gif "access plus 1 month" ExpiresByType image/png "access plus 1 month" ExpiresByType image/jpg "access plus 1 month" ExpiresByType image/jpeg "access plus 1 month" ExpiresByType image/x-icon "access plus 1 month" ExpiresByType video/ogg "access plus 1 month" ExpiresByType audio/ogg "access plus 1 month" ExpiresByType video/mp4 "access plus 1 month" ExpiresByType video/webm "access plus 1 month" ExpiresByType text/x-component "access plus 1 month" ExpiresByType application/x-font-ttf "access plus 1 month" ExpiresByType font/opentype "access plus 1 month" ExpiresByType application/x-font-woff "access plus 1 month" ExpiresByType image/svg+xml "access plus 1 month" ExpiresByType application/vnd.ms-fontobject "access plus 1 month" ExpiresByType text/css "access plus 1 month" ExpiresByType application/javascript "access plus 1 month" #ExpiresByType text/css "access plus 1 year" #ExpiresByType application/javascript "access plus 1 year" ## # Disable caching during development # @see https://github.com/contao/core/issues/4364 ## #ExpiresByType text/cache-manifest "access" #ExpiresByType text/html "access" #ExpiresByType text/xml "access" #ExpiresByType application/xml "access" #ExpiresByType application/json "access" #ExpiresByType application/rss+xml "access" #ExpiresByType application/atom+xml "access" #ExpiresByType image/gif "access" #ExpiresByType image/png "access" #ExpiresByType image/jpeg "access" #ExpiresByType image/x-icon "access" #ExpiresByType video/ogg "access" #ExpiresByType audio/ogg "access" #ExpiresByType video/mp4 "access" #ExpiresByType video/webm "access" #ExpiresByType text/x-component "access" #ExpiresByType application/x-font-ttf "access" #ExpiresByType font/opentype "access" #ExpiresByType application/x-font-woff "access" #ExpiresByType image/svg+xml "access" #ExpiresByType application/vnd.ms-fontobject "access" #ExpiresByType text/css "access" #ExpiresByType application/javascript "access" </IfModule> ## # Header adjustments ## <IfModule mod_headers.c> ## # Disable caching during development # @see https://github.com/contao/core/issues/4364 ## #Header unset Cache-Control #Header append Cache-Control must-revalidate ## # Do not cache the cron.txt file # @see https://github.com/contao/core/issues/5105 ## <FilesMatch "cron\.txt$"> Header set Cache-Control "no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, no-transform" </FilesMatch> ## # Add a Vary Accept-Encoding header for the compressed resources. If you # modify the file types above, make sure to change them here accordingly. # @see http://developer.yahoo.com/performance/rules.html#gzip # # Note: If you are using a case-sensitive file system like HFS+ or ext4, you # have to change the <FilesMatch> directive as follows: # # <FilesMatch "\.(?i:js|css|xml|gz|svgz)$"> # # For more information see: https://github.com/contao/core/issues/4364 ## <FilesMatch "\.(js|css|xml|gz|svgz)$"> Header append Vary Accept-Encoding </FilesMatch> ## # Do not cache source map files # @see https://github.com/contao/core/issues/8532 ## <FilesMatch "\.map$"> Header set Expires "0" Header set Cache-Control "no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, no-transform" </FilesMatch> </IfModule> ## # Disable MultiViews if you are having issues with requests returning the wrong # page. Requires AllowOverride Options=All,MultiViews to be set here. # @see https://github.com/contao/core/issues/3521 ## #Options -MultiViews <IfModule mod_rewrite.c> RewriteEngine On # Determine the RewriteBase automatically and set it as environment variable. # If you are using Apache aliases to do mass virtual hosting or installed the # project in a subdirectory, the base path will be prepended to allow proper # resolution of the app.php file and to redirect to the correct URI. It will # work in environments without path prefix as well, providing a safe, one-size # fits all solution. But as you do not need it in this case, you can comment # the following 2 lines to eliminate the overhead. RewriteCond %{REQUEST_URI}::$1 ^(/.+)/(.*)::\2$ RewriteRule ^(.*) - [E=BASE:%1] # Sets the HTTP_AUTHORIZATION header removed by Apache RewriteCond %{HTTP:Authorization} . RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] ## # Uncomment the following lines to add "www." to the domain: # # RewriteCond %{HTTP_HOST} ^example\.com$ [NC] # RewriteRule (.*) http://www.example.com/$1 [R=301,L] # # Uncomment the following lines to remove "www." from the domain: # RewriteCond %{HTTP_HOST} ^www\.example\.de$ [NC] RewriteRule (.*) http://example.de/$1 [R=301,L] # # Make sure to replace "example.com" with your domain name. ## ## # If you cannot use mod_deflate, uncomment the following lines to load a # compressed .gz version of the aggregated Contao JavaScript and CSS files. ## #AddEncoding gzip .gz #<FilesMatch "\.js\.gz$"> # AddType "application/javascript" .gz #</FilesMatch> #<FilesMatch "\.css\.gz$"> # AddType "text/css" .gz #</FilesMatch> #RewriteCond %{HTTP:Accept-encoding} gzip #RewriteCond %{REQUEST_FILENAME} \.(js|css)$ #RewriteCond %{REQUEST_FILENAME}.gz -f #RewriteRule ^(.*)$ $1.gz [QSA,L] # Redirect to URI without front controller to prevent duplicate content # (with and without `/app.php`). Only do this redirect on the initial # rewrite by Apache and not on subsequent cycles. Otherwise we would get an # endless redirect loop (request -> rewrite to front controller -> # redirect -> request -> ...). # So in case you get a "too many redirects" error or you always get redirected # to the start page because your Apache does not expose the REDIRECT_STATUS # environment variable, you have 2 choices: # - disable this feature by commenting the following 2 lines or # - use Apache >= 2.3.9 and replace all L flags by END flags and remove the # following RewriteCond (best solution) RewriteCond %{ENV:REDIRECT_STATUS} ^$ RewriteRule ^app\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L] # If the requested filename exists, simply serve it. # We only want to let Apache serve files and not directories. RewriteCond %{REQUEST_FILENAME} -f RewriteRule ^ - [L] # Rewrite all other queries to the front controller. RewriteRule ^ %{ENV:BASE}/app.php [L] </IfModule> <IfModule !mod_rewrite.c> <IfModule mod_alias.c> # When mod_rewrite is not available, we instruct a temporary redirect of # the start page to the front controller explicitly so that the website # and the generated links can still be used. RedirectMatch 302 ^/$ /app.php/ # RedirectTemp cannot be used instead </IfModule> </IfModule>

Das mit den Expires-Headern frage ich mich ja auch. Scheint letztlich (leider!) der einzige Weg zu sein, den private Cache sinnvoll zu nutzen, passt aber wohl mit Contao nicht mehr zusammen. Laut @Spooky und der von ihm verlinkten Dokumentation wird der Expires-Header vom Cache-Control Header überschrieben. Wobei alles was ich bisher zum Thema gefunden habe aussagt, dass es bei mir mit den zurückgeschickten Response-Headern eigentlich funktionieren sollte wie gewünscht. Tut es aber halt nicht. Und das ist unschön, weil ich der Meinung bin, dass der beste Request der ist, der gar nicht erst beim Server aufschlägt und somit auch keine Last erzeugt.

Zitat:

Zitat von Spooky

Wie testest du überhaupt, ob der Browser einen Request sendet oder nicht? Idealerweise benutzt du dafür ein Private Browsing Window und analysierst die Access Logs des Web Servers.

Das hatte ich bisher überlesen. Werde ich aber mal machen. Bisher habe ich das ganz einfach getestet. Wenn mir Firefox in der Netzwerkanalyse (Spalte "Übertragen") sagt, dass das HTML "Aus Cache" kommt, gehe ich davon aus, dass er es aus dem Browser-Cache nimmt. Das steht da auch so in der ersten Stunde nach Neuaufbau des shared Cache. Steht dagegen z.B. in dieser Spalte "7,11 KB", dann gehe ich davon aus, dass 7,11 KB vom Server geladen wurden und nicht aus dem Browser-Cache. Das sollte ohne gesendeten Request dann auch nicht möglich sein. Ich schaue aber im Lauf des Tages mal in die Logs, ob da wirklich ein Request kommt.

Also der Request kommt und wird erfolgreich bearbeitet (Status 200). Jedenfalls dann, wenn da nicht "Aus Cache" steht.

Zitat:

Zitat von Der Astronaut

Woran erkennst du denn, ob was aus dem Cache kommt und was nicht?

Ob die Seite aus dem Shared-Cache stammt, ist insbesondere am "contao-cache" Header erkennbar.

"miss" bedeutet, dass die Seite nicht aus dem Shared-Cache stammt und nach dem Seitenaufruf auch nicht im Shared-Cache gespeichert wurde.

Grund hierfür kann sein, dass der Shared-Cache für die Seite nicht aktiviert ist oder bei dem Seitenaufruf Anhaltspunkte für eine Nutzerauthentifizierung vorliegen (siehe https://github.com/contao/contao/blo...er.php#L35-L41).

Liste der Anhänge anzeigen (Anzahl: 1)

Hmm, der Shared-Cache ist aber (im Startpunkt) aktiviert:

Anhang 23523

Auch hatte ich ein paar Dienste im Netz benutzt, damit ich als Fehlerquelle ausscheide, falls ich die Funktion im Firefox falsch bedienen sollte. Überall die gleichen Ergebnisse.

@Der Astronaut: welche Contao Version?

Zitat:

Zitat von Spooky

@Der Astronaut: welche Contao Version?

4.9.3

Zitat:

Zitat von Der Astronaut

Hmm, der Shared-Cache ist aber (im Startpunkt) aktiviert

Und wie sehen die Cache-Einstellungen der Seite selbst aus?

Ist dort evtl. "Cachezeiten festlegen" aktiviert, sodass die Cache-Einstellungen des Startpunkts überschrieben werden, aber keine Cachezeit für den Shared-Cache festgelegt?

Zitat:

Zitat von Mynyx

Und wie sehen die Cache-Einstellungen der Seite selbst aus?

Ist dort evtl. "Cachezeiten festlegen" aktiviert, sodass die Cache-Einstellungen des Startpunkts überschrieben werden, aber keine Cachezeit für den Shared-Cache festgelegt?

Nein, ist nicht aktiviert, so dass die Einstellungen aus dem Startpunkt vererbt werden. Ich hatte das eben aber auch schon mit einem eigenen Wert einer Unterseite versucht. Kommt trotzdem "miss" als Ergebnis raus.

Zitat:

Zitat von Der Astronaut

4.9.3

Es liegt an deinen Server Einstellungen. Siehe der Response vom Server:

Code:

$ curl -I https://derastronaut.de/ HTTP/2 200 date: Thu, 21 May 2020 11:31:41 GMT server: Apache contao-merge-cache-control: 1 cache-control: max-age=3600, private vary: Cookie,Accept-Encoding,User-Agent x-content-type-options: nosniff referrer-policy: no-referrer-when-downgrade, strict-origin-when-cross-origin x-frame-options: SAMEORIGIN x-xss-protection: 1; mode=block contao-cache: miss age: 0 strict-transport-security: max-age=31536000 content-length: 35257 cache-control: max-age=0 expires: Thu, 21 May 2020 11:31:41 GMT content-type: text/html; charset=utf-8

Dein Server Antwortet mit

Code:

vary: Cookie,Accept-Encoding,User-Agent

Contao würde aber nur mit

Code:

var: Cookie

antworten. Außerdem ist der cache-control Header doppelt, vermutlich kommt einer von Contao und der andere von anderswo in der Pipeline des Servers. Und es wird auch noch ein expires Header gesetzt, den Contao eigentlich nicht setzen würde.

Könnte das etwas mit der htaccess zu tun haben?

Zitat:

Zitat von Der Astronaut

Könnte das etwas mit der htaccess zu tun haben?

Ja, du hast dort jegliches Caching für HTML Seiten deaktiviert:

Code:

ExpiresByType text/html "access plus 0 seconds"

Generell hat deine .htaccess teilweise veraltete Anweisungen drin. Ich würde empfehlen deine aktuelle .htaccess zu löschen, composer install ausführen und dann gezielt Dinge in in die .htaccess einfügen (bspw. Caching Anweisungen für alles andere außer text/html).

Ja, mach das mal, ich bin gespannt ob deine Seite von meinen Browsern dann ebenso behandelt wird wie meine :).

Wenn ihr mir noch bitte sagt, wie ich composer install ausführe und welche Sachen ich aus der htaccess übernehmen kann, dann mache ich das gerne ;)

Auf deiner Seite wird übrigens folgendes Cookie gesetzt: cookieconsent_status (wenn man akzeptiert).
Ohne weitere Anpassungen wird dieses Cookie verursachen, dass die Seiten nicht aus dem Shared Cache geladen werden.

Zitat:

Zitat von Spooky

Auf deiner Seite wird übrigens folgendes Cookie gesetzt: cookieconsent_status (wenn man akzeptiert).
Ohne weitere Anpassungen wird dieses Cookie verursachen, dass die Seiten nicht aus dem Shared Cache geladen werden.

Meinst du das hier?

Code:

COOKIE_WHITELIST=PHPSESSID,csrf_https-contao_csrf_token

Ja, wenn du die COOKIE_WHITELIST bereits gesetzt hast, dann passt es :).

Es scheint dennoch nicht zu funktionieren. Ich habe eine .env-Datei in das root-Verzeichnis meiner Contao-Installation mit folgendem Inhalt erstellt:

Code:

COOKIE_WHITELIST=PHPSESSID,csrf_https-contao_csrf_token,cookieconsent_status

Dennoch wird beim Check (curl -I URL) weiterhin "contao-cache: miss" angezeigt.

Auch im Ordner http_cache werden nur komische Unterordner angelegt ohne jeglichen Inhalt.

Außerdem müsste der Shared-Cache doch arbeiten, wenn ich das JS vom Cookie-Consent rausnehme, das Cookie somit gar nicht mehr gesetzt werden kann und dann im Browser checke. Das habe ich zu Testzwecken (auch in anderen Browsern) versucht, aber auch hier immer noch "contao-cache: miss".

P.S.: Interessant ist auch, dass man das trusted_device-Cookie in die .env-Datei packen muss, sonst vertraut Contao einem beim Login ins Backend nicht mehr, wenn man 2FA aktiviert hat :D

Nachdem du cookieconsent_status nun auf die whitelist gesetzt hast, veranlasst du, dass die Seite nie aus dem Cache geladen wird, wenn das Cookie vorhanden ist.

Zitat:

Zitat von Spooky

Nachdem du cookieconsent_status nun auf die whitelist gesetzt hast, veranlasst du nun, dass die Seite nie aus dem Cache geladen wird, wenn das Cookie vorhanden ist.

Ok, von welcher Anpassung sprichst du denn dann?

Von der COOKIE_WHITELIST.

Zitat:

Zitat von Spooky

Von der COOKIE_WHITELIST.

Also darf "cookieconsent_status" gar nicht erst drinnen stehen?

Zitat:

Zitat von Der Astronaut

Also darf "cookieconsent_status" gar nicht erst drinnen stehen?

Genau, denn das Cookie "cookieconsent_status" ist für Contao nicht relevant.

Wobei das schon einen Schritt weiter gedacht ist, denn auch wenn noch keine Cookies vorhanden sind, wird bei deiner Seite "contao-cache: miss" zurückgegeben.

Ja, es funktioniert nur trotzdem nicht...

Hast du dich denn zwischenzeitlich um die veraltete .htaccess gekümmert?

Ja, sieht jetzt so aus:

Code:

## # Configs Server ## #AddHandler php56-cgi .php php_value memory_limit 512M php_value max_execution_time 600 AddDefaultCharset UTF-8 php_value session.save_path /www/htdocs/w012345/tmp/ <IfModule mod_rewrite.c> RewriteEngine On ## # Uncomment the following lines to add "www." to the domain: # # RewriteCond %{HTTP_HOST} ^example\.com$ [NC] # RewriteRule (.*) http://www.example.com/$1 [R=301,L] # # Uncomment the following lines to remove "www." from the domain: # RewriteCond %{HTTP_HOST} ^www\.expample\.de$ [NC] RewriteRule (.*) http://example.de/$1 [R=301,L] # # Make sure to replace "example.com" with your domain name. ## ## # Set the proper MIME types # @see https://github.com/h5bp/html5-boilerplate ## <IfModule mod_mime.c> AddType application/javascript js jsonp AddType application/json json AddType audio/ogg oga ogg AddType audio/mp4 m4a f4a f4b AddType video/ogg ogv AddType video/mp4 mp4 m4v f4v f4p AddType video/webm webm AddType video/x-flv flv AddType image/svg+xml svg svgz AddEncoding gzip svgz AddType application/vnd.ms-fontobject eot AddType application/x-font-ttf ttf ttc AddType font/opentype otf AddType application/x-font-woff woff woff2 AddType image/x-icon ico AddType image/webp webp AddType text/cache-manifest appcache manifest AddType text/x-component htc AddType application/xml rss atom xml rdf AddType application/x-web-app-manifest+json webapp AddType text/x-vcard vcf AddType application/x-shockwave-flash swf </IfModule> ## # Gzip compression # @see https://github.com/h5bp/html5-boilerplate ## <IfModule mod_deflate.c> <IfModule mod_filter.c> AddOutputFilterByType DEFLATE text/html text/plain text/css application/json AddOutputFilterByType DEFLATE application/javascript AddOutputFilterByType DEFLATE text/xml application/xml text/x-component AddOutputFilterByType DEFLATE application/xhtml+xml application/rss+xml application/atom+xml AddOutputFilterByType DEFLATE image/x-icon image/svg+xml application/vnd.ms-fontobject application/x-font-ttf font/opentype </IfModule> </IfModule> ## # Expires headers (for better cache control) # @see https://github.com/h5bp/html5-boilerplate ## <IfModule mod_expires.c> ExpiresActive on ## # Productional website ## ExpiresByType text/cache-manifest "access plus 0 seconds" #ExpiresByType text/html "access plus 0 seconds" ExpiresByType text/xml "access plus 0 seconds" ExpiresByType application/xml "access plus 0 seconds" ExpiresByType application/json "access plus 0 seconds" ExpiresByType application/rss+xml "access plus 1 hour" ExpiresByType application/atom+xml "access plus 1 hour" ExpiresByType image/gif "access plus 1 month" ExpiresByType image/png "access plus 1 month" ExpiresByType image/jpg "access plus 1 month" ExpiresByType image/jpeg "access plus 1 month" ExpiresByType image/x-icon "access plus 1 month" ExpiresByType video/ogg "access plus 1 month" ExpiresByType audio/ogg "access plus 1 month" ExpiresByType video/mp4 "access plus 1 month" ExpiresByType video/webm "access plus 1 month" ExpiresByType text/x-component "access plus 1 month" ExpiresByType application/x-font-ttf "access plus 1 month" ExpiresByType font/opentype "access plus 1 month" ExpiresByType application/x-font-woff "access plus 1 month" ExpiresByType image/svg+xml "access plus 1 month" ExpiresByType application/vnd.ms-fontobject "access plus 1 month" ExpiresByType text/css "access plus 1 month" ExpiresByType application/javascript "access plus 1 month" #ExpiresByType text/css "access plus 1 year" #ExpiresByType application/javascript "access plus 1 year" ## # Disable caching during development # @see https://github.com/contao/core/issues/4364 ## #ExpiresByType text/cache-manifest "access" #ExpiresByType text/html "access" #ExpiresByType text/xml "access" #ExpiresByType application/xml "access" #ExpiresByType application/json "access" #ExpiresByType application/rss+xml "access" #ExpiresByType application/atom+xml "access" #ExpiresByType image/gif "access" #ExpiresByType image/png "access" #ExpiresByType image/jpeg "access" #ExpiresByType image/x-icon "access" #ExpiresByType video/ogg "access" #ExpiresByType audio/ogg "access" #ExpiresByType video/mp4 "access" #ExpiresByType video/webm "access" #ExpiresByType text/x-component "access" #ExpiresByType application/x-font-ttf "access" #ExpiresByType font/opentype "access" #ExpiresByType application/x-font-woff "access" #ExpiresByType image/svg+xml "access" #ExpiresByType application/vnd.ms-fontobject "access" #ExpiresByType text/css "access" #ExpiresByType application/javascript "access" </IfModule> <IfModule mod_headers.c> <FilesMatch "\.(js|css|xml|gz|html)$"> Header append Vary: Accept-Encoding </FilesMatch> </IfModule> <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> # Determine the RewriteBase automatically and set it as environment variable. # If you are using Apache aliases to do mass virtual hosting or installed the # project in a subdirectory, the base path will be prepended to allow proper # resolution of the index.php file and to redirect to the correct URI. It will # work in environments without path prefix as well, providing a safe, one-size # fits all solution. But as you do not need it in this case, you can comment # the following 2 lines to eliminate the overhead. RewriteCond %{REQUEST_URI}::$1 ^(/.+)/(.*)::\2$ RewriteRule ^(.*) - [E=BASE:%1] # Sets the HTTP_AUTHORIZATION header removed by Apache RewriteCond %{HTTP:Authorization} . RewriteRule ^ - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] # Redirect to URI without front controller to prevent duplicate content # (with and without `/index.php`). Only do this redirect on the initial # rewrite by Apache and not on subsequent cycles. Otherwise we would get an # endless redirect loop (request -> rewrite to front controller -> # redirect -> request -> ...). # So in case you get a "too many redirects" error or you always get redirected # to the start page because your Apache does not expose the REDIRECT_STATUS # environment variable, you have 2 choices: # - disable this feature by commenting the following 2 lines or # - use Apache >= 2.3.9 and replace all L flags by END flags and remove the # following RewriteCond (best solution) RewriteCond %{ENV:REDIRECT_STATUS} ^$ RewriteRule ^index\.php(?:/(.*)|$) %{ENV:BASE}/$1 [R=301,L] # If the requested filename exists, simply serve it. # We only want to let Apache serve files and not directories. RewriteCond %{REQUEST_FILENAME} -f RewriteRule ^ - [L] # Rewrite all other queries to the front controller. RewriteRule ^ %{ENV:BASE}/index.php [L] </IfModule> <IfModule !mod_rewrite.c> <IfModule mod_alias.c> # When mod_rewrite is not available, we instruct a temporary redirect of # the start page to the front controller explicitly so that the website # and the generated links can still be used. RedirectMatch 302 ^/$ /index.php/ # RedirectTemp cannot be used instead </IfModule> </IfModule>

Welchen Inhalt hat deine composer.json?

Code:

{ "type": "project", "require": { "contao/calendar-bundle": "4.9.*", "contao/comments-bundle": "4.9.*", "contao/conflicts": "*@dev", "contao/faq-bundle": "4.9.*", "contao/listing-bundle": "4.9.*", "contao/manager-bundle": "4.9.*", "contao/news-bundle": "4.9.*", "contao/newsletter-bundle": "4.9.*", "jrgregory/m17-sticky-backend-footer": "^2.0" }, "extra": { "contao-component-dir": "assets" }, "scripts": { "post-install-cmd": [ "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication" ], "post-update-cmd": [ "Contao\\ManagerBundle\\Composer\\ScriptHandler::initializeApplication" ] } }

Wie sehen deine Cache Einstellungen aus? Im Response deiner Website wird nun nur der Browser Cache benutzt.

Code:

$ curl -I https://derastronaut.de HTTP/2 200 date: Sat, 23 May 2020 09:39:16 GMT server: Apache contao-merge-cache-control: 1 cache-control: max-age=3600, private vary: Cookie,Accept-Encoding,User-Agent x-content-type-options: nosniff referrer-policy: no-referrer-when-downgrade, strict-origin-when-cross-origin x-frame-options: SAMEORIGIN x-xss-protection: 1; mode=block contao-cache: miss age: 0 strict-transport-security: max-age=31536000 content-length: 35257 content-type: text/html; charset=utf-8

Zitat:

Zitat von Der Astronaut

Anhang 23523

Im Startpunkt festgelegt, an alle Unterseiten vererbt.

Tja, das Problem habe ich bis heute noch nicht gelöst. Ist immer noch so, dass durch die lange Cachezeit im Shared/Public Cache eine kürzere Cachezeit für den Browser/Private Cache nur einmal funktioniert. Ist die dafür eingestellte Zeit überschritten, wird wieder vom Server bzw aus dem Shared Cache geladen, was dann aber offenbar nicht mehr mit einer neuen Cachezeit im Browsercache verbunden ist. Es wird fortan immer aus dem Shared Cache abgerufen, also vom Server. Ich habe den Private Cache mittlerweile ausgeschaltet, letztlich wirkt er sich nur noch auf Google Pagespeed aus, weil da wohl nur geprüft wird, ob ein Cachen im Browsercache grundsätzlich für eine angemessene Zeit erlaubt wird, aber in der Realität wird (nach Ablauf der ursprünglichen Browsercache-Zeit) nie mehr aus dem Browsercache geladen. Das merkt Google freilich nicht, so lang geht der Test ja nicht. Ich aktiviere den Browsercache aber nicht um Google zu gefallen (obwohl allein das natürlich schon ein Vorteil wäre aus SEO-Sicht), sondern damit die Zugriffe auf den Server weniger werden.

Ok, ich habs mittlerweile abgehakt und mich damit abgefunden. Es funktioniert halt einfach nicht so, wie ich es erwartet hatte. Was ja nicht heissen muss, dass es falsch funktioniert. So viele Zugriffe habe ich dann auch wieder nicht, dass es wirklich notwendig wäre. Mittlerweile habe ich eine weitere Baustelle entdeckt, wo ich mir wieder nicht ganz sicher bin, ob da was zu tun wäre. Es geht um Bilder und Assets. Bei den von Contao erzeugten Assets und auch Bildern wird ein max-age Response-Header zurückgegeben mit einem Wert von 365 Tagen, was dagegen direkt aus /files/... kommt, hat diesen Response-Header nicht. Muss ich morgen mal schauen, ob es dadurch auch Zugriffe auf den Server gibt für diese Original-Bilder, wenn auch wahrscheinlich nur, um das ETag zu prüfen. Dadurch, dass ETags aktiviert sind, sinkt also nicht die durch Requests erzeugte Serverlast, aber doch wenigstens der Traffic. Zum Glück betrifft das bei mir auf dieser Website auf dem Desktop nur einen relativ kleinen Bruchteil der Bilder und wohl auf den meisten Smartphones gar keine, weil die kleineren Bilder und Vorschaubilder alle von Contao erzeugt werden.

Dass das so ist, kann ich mir auch durchaus erklären. Die von Contao bearbeiteten Bilder und das CSS/JS bekommen einen Hash angehängt, der sich ändert wenn diese Dateien geändert werden. Dadurch können geänderte Dateien sowieso nicht aus dem Browsercache genommen werden und man kann deshalb den max-age Wert im Response Header ruhig auf 365 Tage setzen. Bei den Originalbildern greift die Sache mit dem Hash aber nicht, also kann man das da nicht machen, weil sonst Änderungen der Bilder erst nach 365 Tagen greifen würden. ETags werden ja nicht geprüft, wenn die Datei aus dem Browsercache genommen wird. Muss man also wohl mit leben. Ich würde das halt mittlerweile nötigenfalls mit einem leistungsfähigeren Hosting oder gleich mit einem vServer erschlagen. Oder bei der Bildgröße angeben 0.9999x anstatt 1x. :D;)

Paradoxerweise lobt mich Google Pagespeed mit

Zitat:

Uses efficient cache policy on static assets 11 resources found
A long cache lifetime can speed up repeat visits to your page. Learn more.

Um danach für alle 11 Ressourcen als TTL auszugeben: None
So ganz wissen die da wohl auch nicht immer was sie tun. Beruhigend :D. Oder halt auch nicht, wenn man bedenkt, welche Macht Google ausübt. Immerhin wird das wohl nicht ins Ranking eingehen. Denn das läuft ja alles unter der Überschrift

Zitat:

Diagnostics
More information about the performance of your application. These numbers don't directly affect the Performance score.

Wenngleich "these numbers" ;) natürlich indirekt schon durchaus den Performance Score beeinflussen können und werden.

Ja, habe das nun nochmals getestet. Sobald der Age Response Header größer als max-age ist, legt der Browser nichts in den eigenen Cache ab.

Ok, wenigstens bin ich noch nicht paranoid. Aber das heisst natürlich nicht, dass SIE nicht hinter mir her sind.

https://github.com/contao/contao/issues/3016

https://github.com/Toflar/psr6-symfo...-store/pull/40

https://github.com/symfony/symfony/pull/41369

Da besteht ja doch noch Hoffnung, vielleicht wird es wieder was mit dem Browsercache. Die Umwelt wird es freuen. Naja, nur wenn die Browser nicht verrückt spielen. Ich hatte jetzt tatsächlich bei einigen Versuchen den Fall (Firefox), dass die Seite hätte aus dem Browsercache genommen werden können, dann aber doch vom Server abgerufen wurde, weil der Browser das als schnellere Variante bewertet hat. Da steht dann "Raced". Der war also ernsthaft davon überzeugt, dass er die Seite vom Webserver schneller runterladen kann als er sie von meiner SSD-Festplatte lesen kann? Und selbst wenn es so wäre, gibt es ja trotzdem keinen guten Grund das zu machen. Außer wenn das einzige Ziel ist, die Seitenladezeit mit Gewalt bis auf die letzte Millisekunde zu "optimieren". Aus meiner Sicht eine Fehlentwicklung bei Firefox. Was aus dem Browsercache genommen werden kann sollte auch daraus genommen werden. Damit wird der Webserver entlastet bzw seine Kapazität kann für andere Requests genutzt werden, die nicht aus dem Browsercache des entsprechenden Browsers bedient werden können. Sei es der selbe Browser oder der eines anderen Besuchers.

Ob ein Client seinen private Cache nutzt oder nicht wirst du halt nie forcieren können.

Ist doch alles nicht so straight-forward, wie man der Symfony Diksussion entnehmen kann :D

Zitat:

Zitat von Spooky

Ob ein Client seinen private Cache nutzt oder nicht wirst du halt nie forcieren können.

Leider nicht! Wenn allerdings die wichtigsten Browser nach und nach alle so einen - sorry - Schwachsinn implementieren, dann können wir den private Cache eh gleich vergessen. Was nutzt es mir, wenn die Ressource im private Cache liegt und trotzdem zusätzlich ein Request an den Server gestartet wird, weil selbst eine SSD-Festplatte Firefox offenbar zu langsam ist? Nada. Im Gegenteil, da schalte ich den private Cache in meinen Browsern lieber gleich komplett aus, um wenigstens Platz auf der Festplatte zu sparen und die Lebensdauer der SSD-Festplatte zu verlängern :mad:;)
Dieses "RCWN" (Race Cache With Network) lässt sich zwar abschalten und auch konfigurieren, aber wieviele Nutzer machen das? Genau! Per Default ist es eingeschaltet und der Browser kann nach einer minimalen Wartezeit von 0(!) ms einen Request an den Server starten. Richtig toll! :( Also private Cache künftig nur noch alibimäßig für Google? Glückwunsch auch!