Speed Index < 1000 mit Nginx, ngx_pagespeed, PHP, W3TC

Nginx-Logo
Nginx-Logo
Nichts ist nerviger als langsam ladende Webseiten – wer WordPress selbst hostet (in meinem Fall auf einem Cloudserver bei JiffyBox) hat jedoch etliche Luft für Optimierungen. Hier stelle ich einige vor.
Das Endergebnis vorweg: für die Blog-Startseite unter www.tech-blogger.net ermittelte Webpagetest.org am 09. November 2013 einen Speed-Index von 601 (kleiner ist besser, mehr Informationen zum Speed Index) für den „First View“ und 401 für den „Repeat View“. Das ganze für eine normale WordPress-Blog-Seite (Lightbox für Bilder, 10 Beiträge auf der Startseite, Bilder für Beiträge, Google Analytics) mit einem auf TwentyTwelve basierendem Theme (von mir etwas angepasst für SEO).

Die Software

Um nicht durch veraltete Software-Version gebremst zu werden, habe ich mir für dieses Projekt für einen virtuellen Server mit Debian 7.1 „Wheezy“ entschieden. Für das bisher von mir eingesetzt Debian 6.0.8 gibt es leider nicht ohne weiteres alle Pakete in Versionen, die ich benötige. Im Detail sehen die Eckpunkte meines Setups wie folgt aus:

  • 3 CPU-Kerne, 2 GB RAM, 75 GB HDD
  • Debian 7.2 „Wheezy“
  • Linux version 3.10.13-x86_64
  • nginx 1.4.3 mit ngx_pagespeed und SPDY von dotdeb.org
  • PHP 5.5.5 mit Xcache 3.1.0 von dotdeb.org

MYSQL läuft noch auf einem anderen vServer meines bisherigen Anbieters – die Zugriffe auf die Datenbank müssen also über das Internet abgewickelt werden, durch das Caching fällt dies aber nicht weiter ins Gewicht. In Zukunft soll auch die Datenbank umziehen, das braucht aber noch etwas Zeit und Vorbereitung.

Die Einstellungen

Mit nginx, gzip sowie Pagespeed habe ich mich bereits in der Vergangenheit auseinandergesetzt – die Verwendung von Googles Pagespeed-Service und das damit verbundene Umleiten aller Request über die Server des Internet-Giganten gefiel mir aber mit der Zeit nicht mehr. Außerdem verliert man so die Geo-Location der IP-Adresse des Servers in Deutschland (und eine geplante Unterstützung von SPDY wird auch nicht einfacher). Nachdem also die genannte Software installiert war, ging es an die richtigen Einstellungen. Ich gehe hier davon aus, dass bereits ein lauffähiger WordPress-Blog vorhanden ist, PHP und Mysql also richtig installiert sind, und zeige nur Vorschläge für Änderungen auf.

ngx_pagespeed aktivieren

Vorteil des Nginx-Pakets von dotdeb.org ist, dass das Pagespeed-Modul bereits vorhanden ist und nur aktiviert werden muss. In der nginx.conf (bei Debian unter /etc/nginx/nginx.conf) im Abschnitt „http“ hinzufügen:

pagespeed on;
pagespeed FileCachePath "/var/www/pagespeed_cache/"; #an eigenes System anpassen
pagespeed EnableFilters combine_css,combine_javascript; #Zwei Beispielfilter

Damit ist Pagespeed für alle vorhandenen vHosts aktiviert, in diesen kann es nun deaktiviert werden (wenn es mit einer Webseite gar nicht harmoniert) oder entsprechend angepasst werden – letzteres ist mein Ziel. Zuerst die allgemeinen Settings, die für jeden vHosts eingesetzt werden müssen, der nix_pagespeed verwenden soll. Diese in den „server“-Blöcken der jeweiligen vHosts ergänzen:

#pagespeed
location ~ "\.pagespeed\.([a-z]\.)?[a-z]{2}\.[^.]{10}\.[^.]+" { add_header "" ""; }
location ~ "^/ngx_pagespeed_static/" { }
location ~ "^/ngx_pagespeed_beacon$" { }
location /ngx_pagespeed_statistics { allow 127.0.0.1; deny all; }
location /ngx_pagespeed_global_statistics { allow 127.0.0.1; deny all; }
location /ngx_pagespeed_message { allow 127.0.0.1; deny all; }
location /pagespeed_console { allow 127.0.0.1; deny all; }

Nun zu den spezifischen Einstellungen mittels der Filter. Dabei muss man etwas rumprobieren, nicht jeder Filter funktioniert mit jedem Javascript/CSS, so führte in meinem Fall z.B. „defer_javascript“ dazu, dass die Lightbox nicht mehr funktionierte und die Bilder einfach auf einer neuen Seite geladen wurden – unschön. Letzten Endes ist bei mir folgendes Filterset herausgekommen:

#pagespeed Filter
pagespeed XHeaderValue "Pagespeed on kadder.de powered by Nginx";
pagespeed EnableFilters insert_dns_prefetch;
pagespeed EnableFilters lazyload_images,recompress_images,rewrite_images,convert_jpeg_to_progressive;
pagespeed EnableFilters move_css_to_head;

W3TC – WordPress Total Cache installieren

Im Zusammenspiel mit XCache lässt sich W3TC wirklich sehr gut nutzen. Aber auch hier muss man darauf achten, dass sich Funktionen nicht überschneiden bzw. doppelt ausgeführt werden. So ist es zum Bespiel tödlich, von CSS welches W3TC minified wurde noch einmal von Pagespeed bearbeiten zu lassen – man muss sich für ein Tool entscheiden. Wofür W3TC aber gut geeignet ist: das Browser-Caching entsprechend erhöhen, Cookies für statische Dateien entfernen und eben Datenbankrequests, Objekte und Seiten im XCache abzulegen (der mindestens 128 MB groß sein sollte, sonst kann es selbst mit einem einfachen Blog wie diesem Eng werden). W3TC kann einfach über die Plugin-Verwaltung von WordPress installiert werden, danach müssen noch ein paar Einstellung in die jeweilige vHosts-Konfiguration kopiert werden, damit alles klappt.

WordPress nginx compatibility

Die meisten WordPress-Anleitungen beziehen sich auf Apache. Ich habe mich jedoch für Nginx entschieden, da dieser Server „leichter“ daherkommt als Apache und mit wirklich hoher Geschwindigkeit überzeugt. Damit es WordPress etwas leichter hat, empfiehlt es sich, das Plugin „nginx Compatibility“ zu installieren. Dies kann über die Plugin-Suche geschehen, man sollte sich nicht davon irritieren lassen, dass die Plugin-Seite auf russisch ist.

WordPress SEO by Yoast

Kein direkte Thema für die Performance, aber man versucht ja nicht, einen Blog besonders schnell zu bekommen und will damit nicht bei den Suchmaschinen brillieren. Ein Hilfsmittel, welches auch mit den genannten Maßnahmen hier problemlos funktioniert: WordPress SEO by Yoast. Die Funktionen dieses Plugins würden hier mit Sicherheit den Rahmen sprengen 🙂

Fazit und Ausblick

Mit relativ einfachen Maßnahmen war es mir möglich, die Darstellungsgeschwindigkeit meines Blogs deutlich zu steigern. Die größte Hürde dürfte dabei ein eigener Server bzw. die richtige Software auf einem gemieteten Webspace sein. Wie eingangs erwähnt sehe ich noch eine wesentliche „Ausbaustufe“, und zwar die Verwendung von SPDY. SPDY ist eine HTTP/1.1 Alternative und funktioniert ausschließlich über SSL-Verbindungen (ein entsprechendes Zertifikat habe ich bestellt, das wurde nur leider über das Wochenende nicht fertig). Durch die Verwendung von SPDY sollen noch einmal ~20 Prozent geringere Ladezeiten möglich sein – ich bin gespannt. Wer noch grundlegende Gedanken zu diesem Thema hat ist gerne eingeladen, sie hier zu teilen – ich werde weiterhin versuchen, meine Seiten zu schnell wie möglich auszuliefern, und dies sollte im Sinne von allen Nutzern im Internet sein.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.