WordPress Turbo zünden: Wie fünf A’s Google und Deine Besucher verzücken – Nginx, Varnish und WordPress im Team

Fünf Bestnoten beim Speedranking

Ich habe vor Kurzem den Umzug meines Blogs auf einen neuen RootServer angeteasert; dieser ist nun vollzogen und ich möchte meine Umsetzung gerne mit euch teilen.
Der neue RootServer, nennen wir diesen der Einfachheit halber „VPS“ (Virtual private Server), besitzt folgende Ausstattung: 16 GB Ram, 4 CPU vCores und 250 GB high I/O SSD Platten.
Darauf läuft ein Ubuntu 14.04 LTS, aktuell die damit ausgelieferte PHP Version 5.5.9 und eine Maria DB in der Version 10.
Dort bin ich mit meinen aktuell sechs WordPress Installationen alleine unterwegs: genug Power also, um mein WordPress Hosting zu optimieren.

So startet meine kleine Beitragsreihe: optimiertes WordPress Hosting mit Nginx, Varnish, Apache,PHP und MariaDB.
Wie immer gilt für meine Ausführungen:

  1. es gibt mehrere Wege nach Rom
  2. nobody is perfect
  3. nachmachen auf eigene Gefahr 🙂

Am Ende meiner kleinen Beitragsreihe sollte nachvollziehbar sein, wie auf Webpagetest ORG  die folgenden Werte erreicht werden können:

Der grundlegende Aufbau: wie spielen Nginx, Varnish, Apache und PHP (WordPress) zusammen?

Warum nutze ich genau die „Nginx – Varnish – Apache“ Kombination?

  • Nginx dient  lediglich als Proxy um HTTPS zu terminieren
  • Varnish dient als schneller und intelligenter Web-Application Beschleuniger
  • Apache ist als langjähriger Begleiter das benötigte Stück Sicherheit und Wissen für mich

Ja,  Nginx könnte auch als Cache, und / oder in Zusammenspiel mit PHP-FPM oder HHVM (HippHop VM von Facebook) ohne den Apache laufen. Varnish könnte auch ohne einen vorgeschalteten Nginx direkt vor dem Apache laufen.
Aber: Varnish unterstützt kein HTTPS, so dass es eines zusätzlichen SSL Layers für eine zukünftige HTTP2 Unterstützung und auch für einen verschlüsselten Zugang zum WordPress Backend bedarf. Daher steht der Nginx vor dem Varnish.
Da Nginx für mich keine wirkliche Alternative / Ersatz zu einem Varnish (als Web-Application Beschleuniger) ist läuft der Apache als „Relikt“ als Backend um WordPress / PHP auszuliefern.

Zugegeben: meine, rein subjektive Meinung.
Jedoch eine, die ich vielleicht (!), mit dem Umbau des Nginx für eine WordPress – Installation: Nginx => PHP-FPM gegentesten werde.

Google und meinen Besuchern biete ich erstmal nur HTTP an.

Warum bietet mein Blog Google und meinen Besuchern aber nur das HTTP Protokoll an, wo Google HTTPS Seiten doch höher bewertet?
Das hat ganz einfach finanzielle Gründe: neben der Domain wp-loft.de habe ich JavaScript, CSS Dateien und statische Inhalte auf weitere Subdomains verteilt, um die Anzahl der Browser Requeste per (Sub) Domain zu optimieren. Um nun den kompletten Datentransfer zu verschlüsseln, müsste ich mir ein Wildcard Zertifikat kaufen; das ist nicht grade günstig. Daher warte ich mit einer stringenten HTTPS Umsetzung bis Mitte diesen Jahres auf den Livegang von Let’s Encrypt.

So lauscht der Nginx auf den  HTTP (Port 80) und HTTPS (Port 443). Alle Requeste werden an den lokal laufenden Varnish Dienst (Port 6081) weitergeleitet.
Ausgenommen Zugriffe ins WordPress Backend. Da es sinnfrei ist Anfragen für eingeloggte User mit Varnish zu cachen, spricht der Nginx in diesem Falle direkt mit dem Apache Webserver auf Port 8080.
Mit den vom Nginx mitgelieferten Header Variablen versehen schickt der Varnish die (nicht gecachten Anfragen) in Richtung Apache (Port 8080) weiter. Dieser liest die Headervariablen aus, und weiß damit welche Anfragen an welchen der konfigurierten VHosts weiterzuleiten sind um WordPress Content auszuiefern.
Inhalte die bereits im Varnish gecacht sind, werden direkt – und damit  sehr, sehr schnell an den Nginx ausgeliefert.

Die Inhalte meiner kleinen Beitragsreihe: Nginx / Varnish / Apache / WordPress

Meine Beitragsreihe soll sich in drei Teile Gliedern:

Jeder Teil wird im Abstand von zwei Wochen hier auf meinem Blog erscheinen.