Das Putzlowitsch Test- und SEO-Blog

WordPress für statische Seiten optimieren

WordPress und Permalinks

In WordPress kann man für schönere URLs die Permalinks aktivieren. Diese werden nur für die Struktur der Artikel-URL festgelegt, zusätzlich kann ein Präfix für Kategorien und Tags vorgegeben werden, für Seiten jedoch gibt es keine extra Einstellmöglichkeit.

Für Artikle steht eine Vielzahl von von Platzhaltern (Variablen) zur Verfügung, die bei Zusammensetzen der URL durch die jeweiligen Daten des konkreten Artikels ersetzt werden.

Auch wenn man Permalinks nur für die Artikle wirklich konfigurieren kann, wirken sich die dort gewählten Optionen auch auf die Seiten und andere URLs in WordPress aus. Einen sichtbaren Effekt hat die Entscheidung, ob man die Permalinks mit einem Schrägstrich abschließt oder nicht. Entsprechend erhalten auch alle anderen von WordPress generierten URLs diesen Schrägstrich oder nicht. Das gilt übrigens nur für den Schrägstrich (Slash), alle anderen Endungen wie z.B. .html werden dabei nicht übernommen.

WordPress und Rewrite-Rules

Damit WordPress die Permalinks wieder in konkrete Artikel- und Seiten-IDs auflösen kann, wird eine Liste von Regeln (RewriteRules) erstellt, die sequentiell abgearbeitet wird. Mit dem ersten passenden Treffer wird dann die Datenbankabfrage für einen Artikel oder eine Seite, für eine Kategorie- oder Tagübersicht oder einen Feed usw. erstellt.

Wie diese interne Liste aussieht hängt unter anderem auch davon ab, welche Struktur für die Artikel bei der Permalinkkonfiguration gewählt wird. WordPress muß Artikel von Seiten eindeutig unterscheiden können und das funktioniert nur, wenn die Permalinks als ersten Platzhalter keinen variablen Wert wie Postname (%postnam%), Kategorie (%category%), Tag (%tag%) oder Autor (%author%) enthalten. Andernfalls werden für jede statische Seite jeweils 11 Einträge in der Liste der RewriteRules erstellt, die so aussehen:

[seite-1/attachment/([^/]+)/?$] => index.php?attachment=$matches[1]
[seite-1/attachment/([^/]+)/trackback/?$] => index.php?attachment=$matches[1]&tb=1
[seite-1/attachment/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$] => index.php?attachment=$matches[1]&feed=$matches[2]
[seite-1/attachment/([^/]+)/(feed|rdf|rss|rss2|atom)/?$] => index.php?attachment=$matches[1]&feed=$matches[2]
[seite-1/attachment/([^/]+)/comment-page-([0-9]{1,})/?$] => index.php?attachment=$matches[1]&cpage=$matches[2]
[(seite-1)/trackback/?$] => index.php?pagename=$matches[1]&tb=1
[(seite-1)/feed/(feed|rdf|rss|rss2|atom)/?$] => index.php?pagename=$matches[1]&feed=$matches[2]
[(seite-1)/(feed|rdf|rss|rss2|atom)/?$] => index.php?pagename=$matches[1]&feed=$matches[2]
[(seite-1)/page/?([0-9]{1,})/?$] => index.php?pagename=$matches[1]&paged=$matches[2]
[(seite-1)/comment-page-([0-9]{1,})/?$] => index.php?pagename=$matches[1]&cpage=$matches[2]
[(seite-1)(/[0-9]+)?/?$] => index.php?pagename=$matches[1]&page=$matches[2]

Das mag bei wenigen Seiten zwar kaum ins Gewicht fallen, bei hunderten oder gar tausenden Seiten aber schon. Einerseits belegen diese vielen Regeln Speicher, andererseits müssen sie jedesmal abgearbeitet werden, bei z.B. 300 Seiten mehr als 3300 Listeneinträge. Probleme kann es auch beim Anlegen und Ändern von Seiten geben, denn die Liste muß dann jedesmal neu erstellt werden.

Permalinks für statische Seiten optimieren

Wenn man viele statische Seiten verwendet oder vielleicht gar keine Artikel (WordPress als CMS), sollte man als ersten Platzhalter (Strukturtag) in den Permalinks einen numerischen Wert wie Datum (year,monthnum,day), Zeit (hour,minute,second) oder die ID (post_id) verwenden. Die von WordPress zur Auswahl angebotenen Möglichkeiten erfüllen diese Bedingungen:

Tag und Name: /%year%/%monthnum%/%day%/%postname%/
Monat und Name: /%year%/%monthnum%/%postname%/
Numerisch: /archives/%post_id%

Für Benutzerdefinierte Einstellungen wären z.B. /%post_id%-%postname%/ geeignet. Es darf auch ein fester Text vor dem ersten numerischen Wert stehen, also z.B. /news/%post_id%-%postname%/.

Mit diesen Permalinkeinstellungen werden keine extra Rules je Seite erzeugt, das spart zumindest bei WordPressinstallationen mit sehr vielen statischen Seiten Speicherplatz und Abarbeitungszeit.

Weitere Artikel mit Bezug zu diesem:
7 Kommentare »

Strato PowerPlus mit SpeedPlus – Fehler bei der Remote-Adresse (REMOTE_ADDR)

Nachtrag am 22.01.2010:

Seit heute scheint das weiter unten geschilderte Problem mit der Remote-Adresse nicht mehr zu bestehen. Die Einträge in der .htaccess-Datei oder sonstige Eingriffe sind daher möglicherweise nicht mehr erforderlich.
Bei mir ist das Problem verschwunden, aber offensichtlich noch nicht generell.

Nachtrag am 01.03.2011:

Nach aktuellen Informationen ist das Problem wohl nun doch endgültig behoben worden. Die Einträge in der .htaccess-Datei oder sonstige Eingriffe sind daher nicht mehr erforderlich.

Seit Anfang Dezember 2009 bin ich mit meiner Schnurpsel-Seite wieder zurück zu Strato umgezogen. Ganz weg war ich ja nicht, ich hatte nur den Hostnamen bei einem anderen Anbieter aufgeschaltet. Aber seit es nun SpeedPlus bei Strato gibt, bin ich nun doch wieder zurückgekehrt.

Die Geschwindigkeit ist wirklich gut. Antwortzeiten von ungefähr 0,5 Sekunden gegenüber 3 bis 4 Sekunden vorher sind für ein PHP-Schwergewicht wie WordPress eine merkliche Verbesserung. Zudem wurde auch gleich das ohne-www-Problem beseitigt, in der Umgebungsvariable HTTP_HOST steht nun der tatsächlich im HTTP-Request angegebene host drin.

Die Remote-IP-Adresse (REMOTE_ADDR)

Neben allerlei anderen interessanten Informationen wird bei jedem Webseitenaufruf auch die IP-Adresse des Aufrufers in einer Umgebungsvariablen vermerkt. Auf diese kann z.B. mit Skriptsprachen wie PHP oder Perl als Variable „REMOTE_ADDR“ zugegriffen werden. Diese Remote-Adresse ist z.B. für statistische Auswertungen interessant oder kann beim Aussperren unerwünschter Zugriffe (Spam-Bots) helfen.

Allerdings zählt diese IP-Adresse ja nach Auffassung und Auslegung der Gesetze zu den personenbezogenen Daten und dürften dann eigentlich nicht gespeichert werden. Bei Strato werden die IP-Adressen in den den Kunden zur Verfügung gestellten Serverlogdateien in anonymisierter Form gespeichert. Auch die im Kundenmenü anzeigbare Webseiten-Statistik greift auf diese Daten zurück.
So können die Zugriffe zwar unterschieden aber nicht einem konkreten Anschluß zugeordnet werden

Mehr Geschwindigkeit mit SpeedPlus

Wenn ich die Grafik zu SpeedPlus bei Strato richtig deute, werden die Zugriffe nicht mehr direkt auf die Webserver geroutet, sondern von einem Loadbalancing-Cluster lastabhängig verteilt.
Diese Verteilung funktioniert vermutlich ähnlich wie bei einem nicht-transparenten Proxy, denn für den Webserver sieht es so aus, als würde der Strato-interne Server die Seite anfordern. Genau deshalb steht in der Remoteadresse nicht mehr die IP-Adresse des Aufrufers drin, sondern eine 81.169.145.xxx drin.

Komischerweise tritt der Effekt aber nicht bei allen Domains auf, nur die Hälfte meiner Domains (inkl. Subdomains) bei Strato ist davon betroffen.

Die richtige Remoteadresse ermitteln und setzen

Ich wäre ja nicht Schnurpsel, hätte ich nicht bereits eine Lösung für das Problem parat :-)
Die richtige IP-Adresse findet man im Request-Header-Feld X-Forwarded-For, daß heißt der Strato-Server trägt hier die Adresse ein, von der er die Anforderung erhalten hat.

In Skriptsprachen wie PHP oder Perl steht diese Variable als „HTTP_X_FORWARDED_FOR“ zur Verfügung. Hier könnte man sich die Remote-Adresse also einfach möglichst am Anfang (bei WP z.B. in der wp-config.php) der Abarbeitung in die REMOTE_ADDR eintragen, z.B. so:

if( isset( $_SERVER['HTTP_X_FORWARDED_FOR'] ) ) {
  $ip_addr = @trim( @end( @explode( ",", $_SERVER['HTTP_X_FORWARDED_FOR'] ) ) );
  if( '' != $ip_addr )
    $_SERVER['REMOTE_ADDR'] =  $ip_addr;
}

Hier kommen zwei wichtige Aspekte zum Tragen, denn in „X-Forwarded-For“ können mehrere durch Komma getrennte IP-Adressen stehen, sofern unterwegs mehrere Proxies durchlaufen wurden. Außerdem soll die Adresse nicht überschrieben werden, falls kein X-Forwarded-For-Feld existiert oder aus anderem Grund nicht ermittelt werden kann.

Für Perl könnte das etwa so aussehen:

if( $ENV{'HTTP_X_FORWARDED_FOR'} ne "" )
{
  my @ip_list = split(/,/, $ENV{'HTTP_X_FORWARDED_FOR'});
  $ENV{'REMOTE_ADDR'} = $ip_list[-1]; 
}

Nachteil ist hierbei natürlich, daß man alle Webapplikationen, die irgendwie die REMOTE_ADDR verwenden, entsprechend anpassen muß. Es geht aber auch noch einfacher und allgemeiner.

Umgebungsvariablen mit mod_setenvif setzen

Das Apache-Modul mod_rewrite kennen bestimmt viele WordPress-Nutzer, manch einer kennt vielleicht sogar mod_alias, aber vermutlich nur wenige haben schon mal etwas vom Modul mod_setenvif gehört. Es kommt auch ganz bescheiden und unspektakulär mit nur vier Anweiungen daher.

Mit dem Modul mod_setenvif hat man die Möglichkeit, Umgebungsvariablen abhängig von Request-Feldern zu setzen. Genau das brauchen wir hier. Wir haben das Request-Feld X-Forwarded-For und wollen abhängig davon die Umgebungsvariable REMOTE_ADDR setzen. Das Problem läßt sich mit ein bißchen Regular-Expression in einer Zeile in der .htacces erschlagen:

SetEnvIf X-Forwarded-For "(.+,)? *(.+)$" REMOTE_ADDR=$2

Optimalerweise steht diese Zeile ganz am Anfang einer .htaccess im Wurzelverzeichnis des Webpaketes. Dann wirkt sei auch auf alle Domains oder Subdomains, die ihr sichtbares Wurzelverzeichnis in einem Unterverzeichnis des Webspace haben.

Das schöne an diesem kleinen Eingriff ist, daß er auch auf das Serverlogfile und die Webstatistik wirkt. Im Logfile stehen nun wieder zwar anonymisierte, aber unterscheidbare Zugriffe und die Webstatistik zeigt nicht mehr 10000 Zugriffe von nur 5 Adressen an.

Ende gut, alles gut?

Mit ein bißchen Handarbeit kann man wieder mal einen Strato-Konfigurationsfehler ausbügeln. Andereseits ist die SpeedPlus-Plattform noch recht neu, da können solche Fehler schon mal auftreten. Ich habe das Problem auch bereits vor 10 Tagen an den Strato-Support gemeldet, warte aber immer noch auf die Antwort zu meinem Ticket. Scheint etwas komplizierter zu sein. Bis zur Strato-Problemlösung kann mein kleiner „Trick“ zumindest über die Zeit helfen.

7 Kommentare »

SpeedPlus – Strato macht PHP-Anwendungen schneller

Daß ich das noch miterleben darf! Strato hat es tasächlich geschafft, die Performance von PHP-Webapplikationen wie WordPress, Joomla, Typo3 oder Drupal deutlich zu verbessern. „SpeedPlus“ heißt das Kind und wird in einer entsprechenden Pressemitteilung etwas ausführlicher erläutert.

Und nun kommt auch schon die schlechte Nachricht. Von SpeedPlus profitieren derzeit nur Webhostingpakete der PowerPlus-Klasse. Mit BasicWeb und DynamiX guckt man geschwindigkeitsmäßig weiterhin in die Röhre.

Zwar werden in der Pressemitteilung nur die Neukunden erwähnt, aber teilweise werden wohl auch Bestandskunden mit den passenden Tarifen umgestellt. So erhielt ich vorhin einen Anruf vom technischen Support bezüglich meines Tickets 1034031, welches ich angeblich am 16.11. durch eine telefonisch Anfrage initiiert haben soll. Ich bin zwar manchmal etwa vergeßlich aber in dem Fall sehr sicher, daß ich da nicht angerufen hatte. Aber egal, zumindest wurden vom Support ein paar technische Fragen zur Umstellung geklärt und eine halbe Stunde später ging mit meiner WordPress-Testinstallation richtig die Post ab.

Antwortzeiten von etwa einer halben Sekunde gegenüber 3 bis 4 Sekunden vorher sind schon eine angenehme und merkliche Verbesserung. Zudem wurde das ohne-www-Problem beseitigt, es wird also im HTTP_HOST der tatsächlich im Request angegebene host zurückgeliefert.

Im Moment gibt es eigentlich nur noch einen Grund, der mich davon abhält, mit meiner Schnurpsel-Seite wieder zu Strato zurück umzuziehen. Der hoffnungslos veraltete und damit fehlerhafte WebDatabaseManager in Gestalt von phpMyAdmin-Version 2.6.4-pl3 ist nun wirklich keine Glanzleistung für einen der großen Webhoster in Deutschland.

Vielleicht gibt es ja auch noch ein Update für den „WebDatabaseManager“, dann könnte man sogar Strato mit den PowerPlus-Webhostingpaketen für WordPress empfehlen. Das kleinste PowerPlus-Paket, welches ich hier selbst habe, kostet übrigens derzeit 6,90 Euro und ist mit der aktuellen Aktion bis zum 31.12. für die ersten 6 Monate umsonst.

23 Kommentare »

Ticket 1034031

Manchmal bekommt man Antworten auf Fragen, die man gar nicht gestellt hat.

So kam vor einer Woche eine E-Mail vom Strato-Support zum oben genannten Ticket. Also von mir ist das nicht, meine letzte Supportanfrage war im Dezember 2008 und damals ging es um das Problem mit dem Datenbank-Backup und der veralteten und damit fehlerhaften phpMyAdmin-Version.

… wir möchten Sie mit dieser E-Mail über den Bearbeitungsstand Ihres Troubleticket informieren.
Ich habe Ihre Internetpräsenz aufgerufen und dabei festgestellt, dass die Ladezeiten aktuell im Rahmen liegen.

Die Frage ist, welche Internetpräsenz er aufgerufen hat. Wenn es meine Strato-Hauptdomain, als Schnurpsel-Seite hier ist, dann wundert es mich nicht, daß „die Ladezeiten aktuell im Rahmen liegen“. Schließlich bin ich vor ein paar Monaten mit der Seite umgezogen.

Punktuelle Engpäße können wir im Shared Webhosting Bereich leider nicht ganz ausschliessen. … Mit dem WordPress-Plugin Super Cache oder DB Cache kann die Anzeige der Seiten von WordPress beim wiederholten Aufruf des Benutzers beschleunigt werden. In den entsprechenden Foren und auf der Seite von WordPress finden Sie dazu weiterführende Hinweise. …

usw. usw.

Naja, komische Sache, mit dem Ticket, daß mir nicht gehört. Vielleicht wurde pauschal an alle Kunden, die WordPress nutzen, sowas verschickt. Keine Ahnung.

Weitere Artikel mit Bezug zu diesem:
2 Kommentare »

Geschwindigkeit ist keine Hexerei

Googlebot Ladezeit

Daß das Strato-Shared-Webhosting und WordPress derzeit nicht gut zusammenpassen und warum das so ist, hatte ich vor einiger Zeit geschrieben. Auf Grund der schlechten PHP-Performance dauert das Laden einer WordPress-Seite mindestens 3,5 bis 4 Sekunden, auch wenn keine umfangreichen Plugins oder fette Themes installiert sind.

In den Google-Webmastertools kann man sich die Ladezeiten in einem Diagramm für die letzten drei Monate ansehen. Die Grafik oben zeigt den Verlauf für meine Seite schnurpsel.de. Bis Mitte Juli hatte ich alles bei Strato in meinem Webhostingpaket liegen. Allerdings nutzte ich bereits zu dieser Zeit eine externe Datenbank (bei Host-Europe), da es zeitweise bei Strato auch erhebliche Probleme mit dem Datenbankserver gab.

Im Juli bin ich dann schließlich mit der WordPressinstalltion zu All-Inkl umgezogen, hatte aber weiterhin die externe Datenbank bei HE im Zugriff. Der Umzug verlief bis auf die 410-Gone-Panne auch ganz gut. Die Geschwindigkeit hatte sich schon deutlich verbessert. Einen kleinen Performance-Schub gab es dann nochmal Anfang/Mitte September, da hatte ich dann auch die Datenbank zum Webhoster mit der WordPressinstallation geholt.

Die Geschwindigkeit liegt nun bei 1 bis 1,5 Sekunden für den Seitenabruf. Das ist zwar kein Spitzenwert, aber durchaus akzeptabel. Gut, WordPress ist keine ganz kleine Webapplikation und erfordert schon einiges an Ressourcen vom Webserver, aber trotzdem ist es auch auf mittleren Shared-Webhostingpaketen vernünftig einsetzbar. Dazu muß allerdings der Webserver ordentlich konfiguriert sein. Ich weiß ehrlich gesagt nicht, was da bei Strato die PHP-Performance so ausbremst, normal ist das aber nicht. Selbst auf einem vergleichbaren 1&1-Paket ist WP schneller, und 1&1 gilt allgemein auch nicht grad als Gschwindigkeits-Überflieger.

Man kann nur hoffen, daß sich da bei Strato mal etwas tut, vielleicht ja unter der Regie eines möglichen, neuen Besitzers.

Keine Kommentare »