Beschleunigen Sie die Geschwindigkeit Ihrer Website mit Fastest Cache - Cache Varnish

Procédure

Warum sollten Sie die Ladegeschwindigkeit Ihrer Website beschleunigen? 

Es ist gut zu wissen, dass die Ladegeschwindigkeit Ihrer Website von entscheidender Bedeutung ist, um den Erfolg dieser zu gewährleisten. Für ein Unternehmen beispielsweise vermittelt sie Ihren Besuchern einen ersten Eindruck. Darüber hinaus kann eine zu lange Ladezeit dieser sich auf die Suchmaschinenoptimierung Ihrer Website auswirken bei den wichtigsten Suchmaschinen und ermöglicht keine ausreichende Sichtbarkeit, um diese am Leben zu erhalten.

Es gibt keine Schwelle, die bei der Ladezeit Ihrer Webseiten nicht überschritten werden darf. Allerdings liegt die Ladezeit der meisten Websites unter drei Sekunden.

Was ist Fastest Cache und wozu dient es?

Das Tool Fastest Cache ist ein von LWS konzipiertes und entwickeltes System, das es ermöglicht, die Ladeleistung Ihrer Website zu optimieren dank der Verwendung von Page-Cache-Mechanismen, die auf Webserver-Ebene konfiguriert sind. Das Tool kombiniert die von NGINX und Varnish bereitgestellten Technologien.

NGINX ist ein leistungsorientierter Webserver, der es ermöglicht, wesentlich mehr Anfragen zu verarbeiten als Apache (siehe unseren Blogbeitrag mit dem Titel „Apache VS Nginx : Test de performance”). Er wird bei Fastest Cache hauptsächlich verwendet, um den sicheren Zugriff per https:// auf Ihre Website zu verwalten, bösartige HTTP-Anfragen zu eliminieren (siehe LWS Protect) und HTTP-Anfragen an die Varnish-Cache-Server weiterzuleiten.

Varnish ist ein HTTP-Dienst, der einen Page-Cache-Mechanismus implementiert und es ermöglicht, das Ergebnis einer HTTP-Anfrage im Speicher zwischenzuspeichern.

Mit den richtigen Konfigurationen ermöglicht NGINX, mehr Anfragen auf Ihrer Website zu bedienen, und Varnish verkürzt gleichzeitig die Ladezeit Ihrer Seite und reduziert Ihren CPU- und Speicherverbrauch.

Wie funktioniert der Dienst Fastest Cache?

1. Funktionsweise ohne Cache

Um die Funktionsweise besser zu verstehen, schauen wir uns zunächst an, wie es ohne Cache-Plugin abläuft, damit der Besucher Ihre Website sehen kann.

11. Der Besucher fordert die Seite vom Webserver an. Beispiel: index.php

22. Der Webserver führt die notwendigen Skriptausführungen aus (PHP, Perl, NodeJS, …)

33. Der Webserver erhält das Ausführungsergebnis

44. Der Webserver sendet die HTML-Seite, die aus dem Ergebnis der Skriptausführung hervorgeht

2. Funktionsweise mit dem Modul Fastest Cache

Wenn Fastest Cache aktiviert ist, wird ein Cache-Server zwischen dem Besucher und dem Webserver eingefügt.

Ziel ist es, die Anzahl der notwendigen Skriptausführungen zu reduzieren, indem das Ausführungsergebnis für die nächsten Anfragen, die dieselbe Antwort benötigen, im Speicher behalten wird. Dadurch muss dasselbe Skript nicht mehrfach ausgeführt werden, um dasselbe Ergebnis zu erzielen.

So eliminieren wir die Wartezeit der Skriptausführung aus der Ladezeit der Seite und sparen gleichzeitig die bei der Skriptausführung verwendeten Ressourcen.

11. Der Besucher fordert die Seite vom Webserver an. Beispiel: index.php
2. Fastest Cache überprüft, ob die Seite bereits generiert und im Cache-Speicher gespeichert wurde

• Wenn ja, wird die Seite direkt an den Besucher zurückgegeben ohne Zugriff auf den Webdienst und ohne Ausführung des Skripts
• Wenn nein, wird die Seite beim Webdienst zur Generierung angefordert, was zur Ausführung des Skripts führt (PHP, NodeJS, Perl, Ruby, …).

33. Sobald die Seite generiert wurde, bestimmt Fastest Cache, ob die Seite im Cache behalten werden kann (über Header, URL, …)

• Wenn ja, wird die Seite im Cache-Speicher gespeichert und an den Besucher zurückgesendet
• Wenn nein, wird die Seite im Microcache-Speicher (Cache mit kurzer Gültigkeitsdauer) gespeichert und an den Besucher zurückgesendet

Man stellt fest, dass, wenn eine Seite im Cache-Speicher abgelegt ist, die Verarbeitung durch den Webserver sowie die Ausführung des Skripts vermieden werden.

Cachefähig, nicht cachefähig und Microcache

Wenn der Webdienst Fastest Cache eine neue Antwort liefert, wird diese analysiert, um festzustellen, ob sie für eine zukünftige Verwendung im Cache-Speicher behalten werden sollte oder nicht.

Bestimmte Seiteninhalte sollten nicht im Cache-Speicher abgelegt werden, wie etwa das Ergebnis eines Anmeldeformulars, das Ergebnis einer Zahlungsseite, … da sie Daten enthalten, die je nach Benutzer und Ereignis variieren.

Um zu bestimmen, ob eine Seite im Cache behalten werden kann oder nicht, verwendet Fastest Cache mehrere Mechanismen:

• HTTP-Anfragen mit HTTP-Verben außer HEAD und GET werden systematisch vom Cache ausgeschlossen.
• HTTP-Anfragen, die Cookies enthalten, werden ebenfalls ausgeschlossen. Die von Google Analytics, XiTi, DoubleClick, Quant Capital, AddThis und Cloudflare verwendeten Cookies werden vor der Erkennung entfernt. Ebenso werden die mit bekannten CMS verbundenen Cookies automatisch verwaltet, wenn der Cachemodus dem CMS entspricht.
• HTTP-Anfragen, die durch .htaccess-Passwörter geschützt sind
• Wenn die Antwort des Webservers Anweisungen zum Browser-Cache enthält (Header cache-control), wird sie von Fastest Cache automatisch berücksichtigt und die Seite wird im Cache-Speicher behalten.

Wenn eine HTTP-Anfrage vom Typ GET ist und weder durch .htaccess geschützt ist noch Cookies enthält und keine genauen Anweisungen zum Browser-Cache vorliegen, wird sie für einige Sekunden im Microcache gespeichert.

Der Microcache hilft somit, Probleme durch Nachfragespitzen auf nicht zwischengespeicherten Seiten auszugleichen. So lassen sich beispielsweise Überlastungen und Verlangsamungen bei einer Welle von Suchen nach demselben Produkt in einem E-Commerce-Shop beheben.

Vorstellung der Oberfläche und Aktivierung des Dienstes

Fastest Cache erscheint in Form eines Symbols in cPanel im Abschnitt „Performance“.

Sobald Sie sich in der Oberfläche befinden, werden die Hauptdomain, die zusätzlichen Domains und die Subdomains in der Liste angezeigt.

• Die Spalte „Cache-Status“ zeigt den Aktivierungsstatus des Caches an. Wenn dieser auf „Aktiviert“ steht, ist der Cache aktiviert.
• Die Schaltfläche „Cache leeren“ ermöglicht das Löschen aller zwischengespeicherten Daten für genau diesen Domainnamen.
• Die Schaltfläche „Cache deaktivieren“ ermöglicht das Deaktivieren des Cachings.
• Die Schaltfläche „Cache aktivieren“ ermöglicht das Aktivieren des Cachings.
• Die Schaltfläche „Betriebsmodus ändern“ ermöglicht das Ändern des Verhaltens des Cache-Systems. Diese Modi werden gleich anschließend erläutert.

Die verschiedenen Cache-Modi

Standardmäßig wählt das Cache-System den Modus „Allgemeine Nutzung“, der für allgemeine Verwendungen geeignet ist. Es gibt jedoch weitere Modi:

Entwicklermodus : entspricht der Deaktivierung des Caches und ermöglicht es, das Cache-System während Ihrer Entwicklungsphasen zu umgehen.
WordPress : ein besser für WordPress geeigneter Cache-Modus, bei dem die Verwaltung der Verzeichnisse (wp-content, wp-admin, …) und der spezifischen WordPress-Cookies verbessert ist.
Prestashop : ein besser für Prestashop geeigneter Cache-Modus, bei dem die Verwaltung der Verzeichnisse und der Cookies verbessert ist.

Cache-Leerung

Über die cPanel-Oberfläche, mit der sich der Cache leeren lässt, hinaus ist es möglich, den Cache manuell über das SSH-Terminal des cPanel-Kontos oder über ein auf dem Server gehostetes Skript zu leeren.

Von Ihrem Hosting aus gestartet (PHP-Skript Ihrer Website, Cron-Job oder SSH-Terminal), erfordern diese Methoden weder API-Token noch Zugangsdaten: Fastest Cache akzeptiert direkt die HTTP-Methoden PURGE und FULLPURGE. Das Token lwsapitoken betrifft nur LWS Cache, den Cache des LWS Panel (siehe diese Hilfe).

1. Cache-Leerung mit cURL

Cache einer Seite leeren:

curl -X 'PURGE' http://mon-site-web.com/mapage.php

Dies leert den Cache der URL http://mon-site-web.com/mapage.php.

Cache eines Verzeichnisses leeren:

curl -X PURGE -H 'X-Purge-Method: regex' 'https://mon-site-web.com/wp-content/uploads/.*'

Dies leert alle Caches der URLs, die mit 'http://mon-site-web.com/wp-content/uploads/' beginnen

Cache einer Website leeren

curl -X 'FULLPURGE' http://mon-site-web.com

Für alle diese drei Befehle sind zwei Rückmeldungen möglich:

HTTP-Code 200 : die Leerung wurde ohne Fehler erfolgreich durchgeführt.

HTTP-Code 405 : die Leerung ist nicht erlaubt oder wurde nicht durchgeführt.

2. Automatische Leerung mit einem PHP-Skript (Cron-Job)

Das folgende Skript leert den Cache der gesamten Website oder nur einiger Seiten. Kopieren Sie es in eine Datei purge-cache.php Ihres Hostings und geben Sie dann Ihre Domain in $site an. Um nur bestimmte Seiten zu leeren, listen Sie diese in $pages auf.

 $methode,
        CURLOPT_RETURNTRANSFER => true,
        CURLOPT_CONNECTTIMEOUT => 5,
        CURLOPT_TIMEOUT        => 20,
    ]);
    curl_exec($ch);
    $code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);
    return $code;
}

if (empty($pages)) {
    echo date('Y-m-d H:i:s') . ' vollständige Leerung : HTTP ' . purger('FULLPURGE', $site) . PHP_EOL;
} else {
    foreach ($pages as $page) {
        echo date('Y-m-d H:i:s') . ' ' . $page . ' : HTTP ' . purger('PURGE', $site . $page) . PHP_EOL;
    }
}
// HTTP 200 : Leerung durchgeführt. HTTP 405 : Leerung verweigert oder nicht durchgeführt.

Um es automatisch zu starten, zum Beispiel jede Nacht, erstellen Sie einen Cron-Job, der diese Datei mit PHP ausführt. Wenn Sie einfach den gesamten Cache leeren möchten, kann der Cron-Job auch direkt Folgendes ausführen:

curl -s -X FULLPURGE https://mon-site-web.com

3. Leerung mit einem Plugin oder Modul

Die Mehrheit der Plugins/Module mit Varnish-Integration ist mit dem internen Leerungsmechanismus von Fastest Cache kompatibel.

Hier sind einige getestete und als kompatibel verifizierte Plugins:

• WP Rocket : https://wp-rocket.me
• Proxy Cache Purge : https://wordpress.org/plugins/varnish-http-purge/

HTTPS-Erkennung und Weiterleitungen

Der HTTPS-Status und die auf Apache angegebenen Ports werden durch das in Apache integrierte Modul mod_fastestcache geändert. Daher sind in der Regel keine Änderungen erforderlich.

Falls die HTTPS-Erkennung mit Fastest Cache jedoch nicht funktioniert, kann dies Endlosschleifen bei Weiterleitungen verursachen. In diesem Fall ist es notwendig, die Erkennungsdaten zu ändern.

Die vertrauenswürdigen HTTP-Header für die Erkennung sind:

• X-Forwarded-Proto
• X-Forwarded-Port

Wenn Sie also die folgende HTTPS-Weiterleitung mit einer .htaccess verwenden:

RewriteEngine On 
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

und dies nicht funktioniert, können Sie die Variable SERVER_PORT durch X-Forwarded-Proto ersetzen:

RewriteEngine On
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !on
RewriteRule ^(.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R]

CloudFlare und andere CDNs

CDNs vom Typ CloudFlare verfügen über HTTP-Anfragefilter, die die von Fastest Cache zum Leeren des Caches verwendeten Anfragen „PURGE“ und „FULLPURGE“ blockieren könnten.

Wir empfehlen Ihnen, nur eine Cache-Ebene zu verwenden, also entweder Cloudflare oder Fastest Cache.

Ihre kombinierte Nutzung kann unerwünschte Verhaltensweisen verursachen. Testen Sie beide und verwenden Sie das, was Ihren Anforderungen am besten entspricht.