Keine Client-Cache-Antwort-Header - page 2

bens0778
(@bens0778)

vor 1 Jahr, 1 Monat
Hallo zusammen,

ich lese nun schon eine Weile zu dem Thema nach und komme auf keinen grünen Zweig. Im Bereich Webseitenzustand bekomme ich folgende Fehlermeldung:

„Es wurden keine Client-Cache-Antwort-Header erkannt.“

Ich habe nun schon x Plugins getestet, die allesamt keine Besserung bewirkten (Comet Cache, WP Super Cache, WP Fastest Cache, WP Optimize). Für Objekt Cache habe ich redis im Einsatz, das ist ja aber nach meinem Verständnis der Materie auch nicht das Problem.

Ich habe meine Webseite oben nicht angegeben, weil sie öffentlich nicht verfügbar ist und hoffe, dass Hilfe trotzdem möglich ist.

Ich betreibe die WordPress Installation auf meiner Synology dort über Webstation (PHP 8.0) und virtuellem Host (Apache HTTP Backend Server 2.4, erreichbar über eine Subdomain).

Bei meiner Recherche bin ich auf gewisse Änderungen/Ergänzungen der .htaccess gestoßen. Die gab es bei mir erstmal nicht, habe sie dann angelegt allerdings führte das alles zu nichts.

Ist der Weg über Plugins der einzige? Bin für jeden Hinweis dankbar.
- Dieses Thema wurde geändert vor 1 Jahr, 1 Monat von bens0778.

Ansicht von 9 Antworten - 16 bis 24 (von insgesamt 24)

← 1 2

Thread-Starter bens0778
(@bens0778)

vor 1 Jahr, 1 Monat

Ja, hat klappt. Datei ist automatisch erstellt. Der Inhalt ist jetzt:

BEGIN WordPress

Die Anweisungen (Zeilen) zwischen „BEGIN WordPress“ und „END WordPress“ sind

dynamisch generiert und sollten nur über WordPress-Filter geändert werden.

Alle Änderungen an den Anweisungen zwischen diesen Markierungen werden überschrieben.

RewriteEngine On RewriteRule .* – [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] RewriteBase / RewriteRule ^index.php$ – [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L]

END WordPress

Moderator Bego Mario Garde
(@pixolin)

vor 1 Jahr, 1 Monat

Ja, genau. Da setzt du nun

Header set X-WordPress OK

als erste Zeile ein.

Dann rufst du eine Webseite im Browser auf, schaust dir die Web-Entwickler-Tools > Netzwerk an und prüfst von der ersten Datei den Antwort-Header. (Siehe Beschreibung oben.) Der sollte nun den (erfundenen) Header „x-wordpress OK“ enthalten.

Thread-Starter bens0778
(@bens0778)

vor 1 Jahr, 1 Monat

Das klappt!
Moderator Bego Mario Garde
(@pixolin)

vor 1 Jahr, 1 Monat
Prima, dann löschst du die Zeile wieder, aktivierst ein Cache-Plugin (z.B. Surge) und schaust, ob in einem privaten Browser-Fenster ein Header „x-cache: hit“ angezeigt wird. (Unter Umständen siehst du zuerst „x-cache:miss“, was soviel bedeutet wie „Cache-Plugin läuft zwar, aber die Seite ist nicht im Cache. Lädst du die Seite erneut, sollte die Seite im Cache vorhanden sein und der Header „x-cache: hit“ ausgegeben werden.)

Das private Browser-Fenster soll sicherstellen, dass du die Webseite als unangemeldeter Besucher siehst, weil angemeldeten Nutzern keine gecachten Seiten angezeigt werden – du würdest sonst nach Änderungen im Backend im Frontend weiterhin den alten Stand sehen.
- Diese Antwort wurde geändert vor 1 Jahr, 1 Monat von Bego Mario Garde. Grund: Begründung privates Browser-Fenster
Thread-Starter bens0778
(@bens0778)

vor 1 Jahr, 1 Monat
Auch das klappt soweit. Ich habe bei der Seite einen Passwortschutz als Plugin aktiviert. Kann es sein, dass mir das insgesamt einen Strich durch die Rechnung macht?

Dein Test klappt, wenn ich den Passwortschutz deaktiviere – sonst bleibt es bei x-cache:miss

Ganz herzlichen Dank, dass Du Dir die Zeit nimmst mir das im Detail aufzudröseln. Dein und Euer Einsatz hier ist wirklich bemerkenswert.
- Diese Antwort wurde geändert vor 1 Jahr, 1 Monat von bens0778.
- Diese Antwort wurde geändert vor 1 Jahr, 1 Monat von bens0778.
Moderator Bego Mario Garde
(@pixolin)

vor 1 Jahr, 1 Monat

Klingt vernünftig, dass du x-cache:miss bekommst. Den Passwortschutz wirst du nicht zwischenspeichern wollen?

Bekommst du denn weiterhin die Fehlermeldung im Website-Zustandsbericht?

Thread-Starter bens0778
(@bens0778)

vor 1 Jahr, 1 Monat

Leider schon, ja.
Moderator Bego Mario Garde
(@pixolin)

vor 1 Jahr, 1 Monat
Du kannst versuchen, Expire-Headers in der .htaccess hinzuzufügen. Dazu fügst du oberhalb des bereits besprochenen WordPress-Blocks folgende Zeilen ein:
```
## EXPIRES HEADER CACHING ##
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/jpg "access 1 year"
ExpiresByType image/jpeg "access 1 year"
ExpiresByType image/gif "access 1 year"
ExpiresByType image/png "access 1 year"
ExpiresByType image/svg "access 1 year"
ExpiresByType text/css "access 1 month"
ExpiresByType application/pdf "access 1 month"
ExpiresByType application/javascript "access 1 month"
ExpiresByType application/x-javascript "access 1 month"
ExpiresByType application/x-shockwave-flash "access 1 month"
ExpiresByType image/x-icon "access 1 year"
ExpiresDefault "access 2 days"
</IfModule>
## EXPIRES HEADER CACHING ##
```
Danach kannst du mit dem Online-Tool https://www.giftofspeed.com/cache-checker/ testen, ob es funktioniert.

(Quelle: Wie man Expires Header in WordPress hinzufügt)

Wenn es dir nur darum geht, die Fehlermeldung zu unterdrücken, reicht in der wp-config.php der Eintrag define( 'WP_ENVIRONMENT_TYPE', 'staging' );.
Moderator Bego Mario Garde
(@pixolin)

vor 1 Jahr, 1 Monat
In diesem Beitrag wurde das Feature, dass der Page-Cache geprüft wird, vorgestellt: New cache Site Health checks in WordPress 6.1

Am Ende des Beitrags steht, dass du auch einen eigenen Header als Prüfkriterium verwenden kannst. Sinngemäß müsstest du in der functions.php oder in einem Code Snippet folgende Zeilen eintragen:
```
/**
 * Filter the page cache supported cache headers
 * $cache_headers contains List of client caching headers and their (optional) verification callbacks.
 */
add_filter( 'site_status_page_cache_supported_cache_headers', function( $cache_headers  ) {
	// Add new header to the existing list.
	$cache_headers['x-cache'] = static function ( $header_value ) {
		return false !== strpos( strtolower( $header_value ), 'hit' );
	};
	return $cache_headers;
});
```
Bei der Prüfung geht es darum, bei Webseiten, die nach einer vorgegebenen Zeit nicht ausgeliefert werden, zu prüfen, ob wenigstens ein Cache-Plugin verwendet wird (was du mit Surge tust). Deshalb finde ich es OK, wenn du einen eigenen Header hinzufügst.
Andererseits ist die Synology nicht primär als Webserver gedacht und es kann gut sein, dass sie einfach … ein bisschen langsam ist. Da wäre es fair, das Zeitinterval hochzusetzen:
```
/**
 * Filter the response time threshold
 */
add_filter( 'site_status_good_response_time_threshold', function() {
	return 1200; // default: 600
} );
```

Ansicht von 9 Antworten - 16 bis 24 (von insgesamt 24)

← 1 2

Das Thema „Keine Client-Cache-Antwort-Header“ ist für neue Antworten geschlossen.

Ansichten