Fastest Cache: Beschleunigen Sie Ihre Website mit Varnish und NGINX

Procédure

Warum die Ladegeschwindigkeit Ihrer Website erhöhen?

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

Es gibt keinen Grenzwert, der bei der Ladezeit Ihrer Webseiten nicht überschritten werden darf. Die Ladezeit der meisten Websites liegt jedoch unter drei Sekunden.

Was ist Fastest Cache und wozu dient es?

Das Tool Fastest Cache ist ein von LWS entwickeltes System, das dazu dient, 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 auf Leistung ausgerichteter Webserver, der deutlich mehr Anfragen verarbeiten kann als der traditionelle Webserver Apache HTTPd Server (siehe unseren Blogbeitrag mit dem Titel „Apache VS Nginx : Performance-Test”). LWS verwendet NGINX, um im Vorfeld ein hohes Volumen an HTTP-Anfragen ohne Leistungseinbußen empfangen zu können. Diese können anschließend effizient gefiltert werden, um schädliche Anfragen zu entfernen (siehe LWS Protect) und die HTTP-Anfragen an den Varnish- oder LiteSpeed-Cache-Server weiterzuleiten, je nach Wahl des Kunden über seine Hosting-Oberfläche.

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

Mit den richtigen Konfigurationen ermöglicht NGINX, mehr Anfragen auf Ihrer Website zu empfangen, und Varnish ermöglicht es gleichzeitig, die Ladezeit Ihrer Seite zu verkürzen und Ihren CPU- sowie RAM-Verbrauch zu reduzieren.

Wie funktioniert der Dienst Fastest Cache?

Funktionsweise ohne Cache

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

1. Der Besucher fordert die Seite vom Webserver an. Beispiel: index.php
2. Der Webserver führt die erforderlichen Skriptausführungen aus (PHP, Python, Node.js …)
3. Der Webserver empfängt das Ausführungsergebnis
4. Der Webserver sendet die HTML-Seite, die aus dem Ergebnis der Skriptausführung hervorgegangen ist

Funktionsweise mit dem Modul Fastest Cache

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

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

So eliminieren wir die Wartezeit für die 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 prüft, ob die Antwort aus dem Cache abgerufen werden kann:

• 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 vom Webserver erzeugt, was die Ausführung des Skripts (PHP, Node.js, Perl, Ruby, …) zur Folge hat. Sobald die Seite erzeugt wurde, bestimmt Fastest Cache, ob die Antwort im Cache gespeichert werden kann.
  • Wenn ja, wird die Seite im Cache-Speicher abgelegt und an den Besucher zurückgesendet
  • Wenn nein, wird die Seite an den Besucher zurückgesendet, ohne im Cache-Speicher abgelegt zu werden

Es ist festzustellen, dass, wenn eine Seite im Cache-Speicher gespeichert ist, die Verarbeitung durch den Webserver sowie die Skriptausführung vermieden wird, was die Ausführungszeit und den Ressourcenverbrauch erheblich reduziert.

Verhalten des Caching-Systems

Fastest Cache stützt sich auf mehrere Signale, um das angewendete Caching-Verhalten zu bestimmen:

• Dateierweiterung in der URL
• Vorhandensein und Inhalt der URL-Parameter (Query Strings)
• Antwortheader Cache-Control
• Cookies

Fastest Cache erkennt außerdem bestimmte CMS sowie Erweiterungen / Module und implementiert spezifische Caching-Verhaltensweisen in Bezug auf diese Werkzeuge.

Verhalten beim Empfang der Anfrage

Fastest Cache cached nur die HTTP-Methoden GET und HEAD.

Wenn ein Besucher eine URL aufruft, normalisiert Fastest Cache die Anfrage, indem Cookies und URL-Parameter entfernt werden, die das endgültige Rendering des Skripts serverseitig nicht beeinflussen (Google-Analytics-URL-Parameter, Cookies im Zusammenhang mit Javascript-Skripten ...).

Sobald die Anfrage normalisiert ist, wird geprüft, ob sie eine HTTP-Authentifizierung enthält (HTTP-Request-Header Authorization) oder ob noch Cookies vorhanden sind (HTTP-Request-Header Cookie). Wenn ja, wird die Anfrage an den Webserver zurückgeleitet, ohne das Caching-System zu durchlaufen.

Verhalten beim Senden der Antwort

Wenn die Anfrage das Cache bei der Annahme nicht umgangen hat, analysiert Fastest Cache die vom Webserver bereitgestellte HTTP-Antwort erneut und prüft, ob es möglich ist, die Antwort für eine zukünftige Verwendung zu cachen.

Wenn die HTTP-Antwort einen HTTP-Antwortheader Cdn-Cache-Control liefert, befolgt Fastest Cache sofort die dort definierten Vorgaben:

• Wenn dort no-store, no-cache oder private definiert ist, gibt Fastest Cache die Antwort an den Besucher zurück, ohne sie im Cache zu behalten.
• Wenn dort s-maxage oder max-age definiert ist, verwendet Fastest Cache diesen Wert sofort als Aufbewahrungsdauer der Seite im Cache.

Wenn Cdn-Cache-Control mit Set-Cookie definiert ist, wird Cdn-Cache-Control ignoriert und die Antwort wird nicht im Cache behalten.

Die statischen Dateien, die den WordPress-Themes, Plugins, Uploads und dem Core entsprechen, werden automatisch für 30 Tage im Cache behalten.

Wenn die HTTP-Antwort aus dem Page-Cache-System von LWS Optimize, WP Fastest Cache, Airlift, W3 Total Cache, WP Rocket, WP Optimize oder FastPixel stammt, wird sie für 7 Tage im Cache behalten. Diese WordPress-Plugins führen die Varnish-Cache-Leerung selbst durch, wenn sie den Page-Cache löschen.

Wenn die HTTP-Antwort aus dem Verzeichnis /_next/static stammt, wird sie ebenfalls für 7 Tage im Cache behalten.

Wenn die HTTP-Antwort einen HTTP-404-Code zurückgibt, wird sie 900 Sekunden lang im Cache behalten. Dies vermeidet insbesondere für WordPress weitere unnötige Anfragen an die MySQL-Datenbank.

Wenn die HTTP-Antwort einen HTTP-500-Code zurückgibt, wird die Antwort niemals im Cache behalten.

Wenn die HTTP-Antwort ein Cookie enthält (HTTP-Antwortheader Set-Cookie), wird die Antwort niemals im Cache behalten.

Wenn die HTTP-Antwort einen HTTP-Antwortheader Cache-Control oder Surrogate-Control liefert, folgt Fastest Cache dem erwarteten Cache-Verhalten für Browser. Wenn diese Header zusammen mit Cdn-Cache-Control bereitgestellt werden, ignoriert Fastest Cache Cache-Control und Surrogate-Control zugunsten von Cdn-Cache-Control. Dies ermöglicht beispielsweise, den Browser dazu zu zwingen, bei jedem Besuch eine HTTP-Anfrage zu stellen, um eine Artikelliste anzuzeigen, ohne dass die Artikelliste im Server-Cache fehlt.

Vorstellung der Oberfläche und Aktivierung des Dienstes

Fastest Cache wird in cPanel in der Sektion „Performance“ als Symbol angezeigt.

Einmal in der Oberfläche 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.
• Der Button „Cache leeren“ ermöglicht das Löschen aller zwischengespeicherten Daten für diesen bestimmten Domainnamen.
• Der Button „Cache deaktivieren“ ermöglicht das Deaktivieren des Cachings.
• Der Button „Cache aktivieren“ ermöglicht das Aktivieren des Cachings.
• Der Button „Betriebsmodus ändern“ ermöglicht das Ändern des Verhaltens des Cache-Systems. Diese Modi werden im Anschluss erklärt.

Die verschiedenen Cache-Modi

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

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

Cache-Leerung

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

Wenn diese Methoden von Ihrem Hosting aus gestartet werden (PHP-Skript Ihrer Website, Cron-Job oder SSH-Terminal), benötigen sie weder API-Token noch Kennung: Fastest Cache akzeptiert die HTTP-Methoden PURGE direkt.

Cache-Leerung mit cURL

Cache einer Seite leeren:

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

Dies ermöglicht das Leeren des Caches der URL https://mon-site-web.com/mapage.php.

Cache eines Verzeichnisses leeren:

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

Dies ermöglicht das Leeren aller Caches der URLs, die mit 'https://mon-site-web.com/wp-content/uploads/' beginnen

Cache einer Website leeren

curl -X PURGE https://mon-site-web.com/.*

Für alle drei Befehle sind drei Rückgaben möglich:

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

HTTP-Code 4xx : Die Leerung ist nicht erlaubt.

HTTP-Code 5xx : Es ist ein Fehler aufgetreten.

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 sie in $pages auf.

 'PURGE',
        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($site . '/.*') . PHP_EOL;
}
else {
    foreach ($pages as $page) {
        echo date('Y-m-d H:i:s') . ' ' . $page . ' : HTTP ' . purger($site . $page) . PHP_EOL;
    }
}

Um es automatisch auszuführen, beispielsweise jede Nacht, erstellen Sie eine Cron-Task, die diese Datei mit PHP ausführt. Wenn Sie einfach nur den gesamten Cache leeren möchten, kann der Cron-Job auch direkt ausführen:

curl -s -o /dev/null -X PURGE 'https://mon-site-web.com/.*'

Leerung mit einem Plugin oder Modul

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

Hier sind einige getestete und verifizierte kompatible Plugins:

• LWS Optimize
• WP Fastest Cache
• WP Rocket
• Proxy Cache Purge

HTTPS-Erkennung und Weiterleitungen

Der HTTPS-Status und die auf Apache angegebenen Ports werden in die Umgebung injiziert und erfordern in der Regel keine zusätzlichen Änderungen.

Falls die HTTPS-Erkennung mit Fastest Cache nicht funktioniert, kann dies Endlosschleifen bei Weiterleitungen verursachen. Daher ist es notwendig, die Erkennungsdaten anzupassen.

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 können HTTP-Anfragen filtern, wodurch die von Fastest Cache zum Leeren des Caches verwendeten „PURGE“-Anfragen blockiert werden könnten. Es wird Ihnen daher empfohlen, beim Leeren mit curl die IP-Adresse des Servers anzugeben, um bei den Löschvorgängen die CDNs zu umgehen:

curl -X PURGE --resolve mon-site-web.com:443:IP_DU_SERVEUR 'https://mon-site-web.com/.*'

CDNs können außerdem eine zusätzliche Cache-Schicht enthalten, die Sie unabhängig vom von Fastest Cache bereitgestellten Cache verwalten müssen.