Pagespeed: combine_css mit WordPress

Wer WordPress mit mod_pagespeed bzw. ngx_pagespeed verwendet und den Filter combine_css verwendet, wird feststellen, das nichts passiert. Was ist zu tun?

Der Grund für die Probleme: Das Pagespeed-Modul berücksichtigt keine CSS-Einbindungen, die unterschiedliche IDs haben. WordPress setzt den Namen des CSS als ID bei der Einbindung, am Ende sieht es dann so aus:

link rel='stylesheet' id='wp-pagenavi-css' href='/wp-content/plugins/wp-pagenavi/pagenavi-css.css?ver=2.70' type='text/css' media='all'/

Der Lösungsansatz: die ID sowie den dazugehörigen Wert entfernen. Dafür kann man eine entsprechende Funktion in der functions.php des Themes einbinden:

function remove_style_id($link) {
        return preg_replace("/id='.*-css'/", "", $link);
}
add_filter('style_loader_tag', 'remove_style_id');

Der Hintergrund: der Filter style_loader_tag beinhaltet die Einbindung, die Funktion remove_style_id macht nichts weiter als in der fertigen Ausgabe der CSS-Einbindung in WordPress die ID-Werte zu entfernen. Das „Problem“ besteht schon länger, auf Codecentric.de wurde dieser Lösungsansatz bereits 2011 beschrieben.

Insgesamt braucht man am Ende mit den funktionierenden combine_css das WordPress W3TC-Plugin nicht mehr: Caching wird via Microcaching direkt von Nginx gelöst, alle anderen Seitenoptimierungen erledigt das Pagespeed-Modul im Webserver. Dieser Blog läuft mit einer entsprechenden Konfiguration und erreicht damit sehr gute Speed-Index-Werte.

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).
Weiterlesen…

Backup mit Strongspace.com und sshfs

Wer einen Blog oder eine andere Webseite betreibt, steht früher oder später vor dem „Problem“, eine Backup-Strategie zu benötigen. Hier sind verschiedene Ansätze denkbar, hier will ich eine Variante vorstellen. Folgende Voraussetzungen: zum Hosting wird ein vServer mit Root-Zugriff eingesetzt (Debian 6.0), das Backup soll unabhängig vom Anbieter stattfinden. Meine Wahl fiel auf den Anbieter Strongspace.com, welcher für 3,99 US-Dollar im Monat 15 GB Platz anbietet, auf den per SSH und rsync zugegriffen werden kann. Vorteil am Ende: egal welches Backup-Programm tatsächlich eingesetzt wird, das Backup wird direkt auf Strongspace.com gesichert – ohne Umwege in Form von rsync.
Weiterlesen…

UMTS: Daten-Volumen sparen mit Proxy

Da ich derzeit auf das knappe Datenvolumen von einem Gigabyte pro Monat (derzeit mit einer Fyve-Karte, da dort noch Guthaben drauf war) angewiesen bin, versuche ich natürlich, möglichst sparsam mit den Daten umzugehen.

Bereits vor einiger Zeit habe ich dafür auf einem vServer ein entsprechendes Setup aufgesetzt, welches mit einer VPN-Verbindung erreichbar ist und dann mit einer Proxy-Kette verschiedene Aufgaben übernimmt. Das ganze läuft unter Debian und lässt sich wahrscheinlich auch einfacher realisieren, aber ein wenig Spaß muss da auch dabei sein. Ich werde jetzt kurz den Weg der Daten vom Internet bis zu meinem Notebook schildern, vielleicht dient dies ja dem ein oder anderen als Inspiration, wenn er vor einem ähnlichen Problem steht.
Weiterlesen…

nginx + PHP unter Debian (+ W3TC)

nginx ist ein schneller Webserver, der sich auch als Reverse Proxy oder zum Streaming von Flash-Videos einsetzen lässt. Ursprünglich entwickelt für die Anforderungen einer russischen Suchmaschine setzen auch immer mehr Webprojekte auf nginx. Anders als beim bekannten Apache-Webserver ist die Konfiguration von nginx unter Debian nicht ganz so simpel – es müssen noch Dateien von hand angepasst werden. Dieser Beitrag beschreibt die Basis-Änderungen, die nötig sind, um PHP5 mit Xcache als FastCGI-Einbindung unter Debian zum laufen zu kriegen. Die gezeigten Einstellungen sollten immer an die eigene Umgebung angepasst werden.

Installation
Mit folgendem Befehl werden die passenden Pakete installiert:

apt-get install php5-cgi php5-xcache php5-mysql nginx

Der mysql-Server ist in unserem Fall auf einem anderen Server untergebracht, ansonsten müsste zusätzliche noch das entsprechende Paket installiert werden. Der nächste Schritt ist die Einrichtung des nginx, wir behaltet dort weitgehenden den Debian-Standard bei. Mit dem Befehlt

/etc/init.d/nginx start

wird überprüft ob die Konfiguration bis hier hin funktioniert und der Webserver korrekt startet.

Konfiguration

Ist dies der Fall, müssen noch einige Anpassungen an der PHP-Einstellung für den jeweiligen Host sein (der Default-Host wird in „/etc/nginx/sites-available/default“ konfiguriert).

location ~ \.php$ {
fastcgi_pass 127.0.0.1:9000; #php läuft auf Localhost, Port 9000
#fastcgi_index index.php; #wird für diese Konfiguration nicht benötigt
fastcgi_param SCRIPT_FILENAME /var/www$fastcgi_script_name; #legt das Verzeichnis fest
include /etc/nginx/fastcgi_params;
}

In der fastcgi_params, die von Debian unter /etc/nginx angelegt wird, muss ebenfalls noch etwas geändert werden. Folgende Zeilen müssen auskommentiert werden:

#fastcgi_param SCRIPT_NAME $document_root$fastcgi_script_name;

Jetzt kann php-cgi alleine gestartet werden, um zu schauen ob alles funktioniert:

php-cgi -b 127.0.0.1:9000

Eine php-info-Datei in /var/www sollte jetzt Informationen zum installieren PHP zurückliefern. Gibt es die Meldung „no input file specified“ stimmt noch etwas mit den Verzeichnissen nicht. Funktioniert alles, kann das php-cgi-Startscript aus dem Nginx-Wiki übernommen werden und Einstellungen am XCache etc. vorgenommen werden. auch sollten wie im Wiki beschrieben Upload-Verzeichnisse geschützt werden, damit dort kein PHP ausgeführt werden kann.

Demnächst geht es hier weiter mit Redirects unter Nginx und Klartext-URLs mit WordPress (wie sie dieser Blog auch schon verwendet).
Weiterlesen…