Das Putzlowitsch Test- und SEO-Blog
Stichwort: Geschwindigkeit

Geschwindigkeit und Sichertheit – https geht auch schnell

Sicher ist sicher

Vor gut sechs Wochen habe ich meine putzlowitsch.de-Website auf https umgestellt.
Das SSL-Zertifikat ist schon immer in meinem Webhosting-Paket bei All-Inkl im Preis enthalten. Nun habe ich es endlich aktiviert.

Putzlowitsch mit Comodo-SSL Zertifikat

Sichtbarer Effekt ist das Schloß-Symbol in der Adressleiste, welches auf eine sichere Verbindung hinweist. Die Übertragung der Daten vom Browser des Nutzers zum Server und umgekehrt ist verschlüsselt. Das Zertifikat wird vom Browser ohne weitere Nachfrage akzeptiert, weil es in der Zertifikatshierarchie auf ein vertrauenswürdiges Root-Zertifikat von “AddTrust External CA Root” zurückgeht.

Ein technisch bedingter Nebeneffekt ist, daß meine Putzlowitsch-Domain auch eine eigene IP-Adresse bekommen hat, da All-Inkl nicht wie Strato das SNI-Verfahren verwendet. Im Unterschied zu 1&1, wo bei aktivem SSL das gesamte Webhosting-Paket eine gesonderte IP-Adresse erhält, ist es bei All-Inkl aber nur die per SSL gesicherte Domain.

Für Google eine neue Web-Site

Obwohl ich die Nicht-SSL-Version meiner Putzlowitsch-Seiten per 301-Redirect auf die https-Version weiterleite, ist es für Google erstmal eine neue Website. Erwartungsgemäß war der Google-Bot kurz nach der Umstellung auf meinen Seiten sehr aktiv.

Gut zu sehen ist das in den Google-Webmaster-Tools unter „Crawling-Statistiken“:

Pro Tag gecrawlte Seiten
Pro Tag gecrawlte Seiten

Waren es vorher ungefähr 500 bis 1500 Seiten am Tag, gab es kurz nach der Umstellung einen Spitzenwert von fast 7500 Seiten.

Pro Tag heruntergeladene Kilobyte
Pro Tag heruntergeladene Kilobyte

Entsprechend zeigt sich das auch bei der durch den Google-Bot heruntergeladenen Datenmenge.

Die eigentlich spannende Frage ist aber die nach der Gewschwindigkeit

Sicher muß nicht langsamer sein

Nachdem meine Schnurpsel-Seite hier durch die https-Umstellung einen merk- und meßbaren Geschwindigkeitverlust erlitten hat, war ich gespannt, ob sich das bei All-Inkl ähnlich darstellt.

Ich habe durchaus erwartet, daß die Seiten etwas langsamer werden, denn die Verschlüsselung benötigt auch bei All-Inkl natürlich Rechenzeit. Nach der Umstellung fühlte sich die Seite nicht langsamer an. Und wie schnell werden die Seiten für den Google-Bot ausgeliefert?

Hierzu habe ich wieder einen Blick in die Google-Webmastertools geworfen. Dort kann man sich die Ladezeiten für die Seitenabrufe durch den Googlebot ansehen.

Dauer des Herunterladens einer Seite (in Millisekunden)
Dauer des Herunterladens einer Seite (in Millisekunden)

Größere Schwankungen bei der Ladezeit gab es seit Anfang Oktober, warum auch immer, bereits vor der HTTPS-Umstellung. Danach ist für mich zumindest keine signifikanter Anstieg zu erkennen. Die Werte schwanken im Bereich von 500 bis 1100 Milliskunden.

„Gefühl“ und Meßwerte zeigen, die Seite ist durch SSL-verschlüsselte Auslieferung nicht wirklich langsamer geworden.

Noch schneller

In der Ladezeit-Grafik ist ab dem 26. November ein interessanter Kurvenverlauf zu sehen. Die Zeiten für die Auslieferung der Seiten an den Google-Bot liegen seitdem fast konstant bei knapp unter 300 ms. Was ist passiert?

Mein Webhostingpaket bei All-Inkl liegt nun schon seit mehreren Jahren auf einem Server, der mittlerweile nicht mehr der schnellst ist. Ein großer Nachteil war aus meiner Sicht, das dort nur die veraltete PHP-Version 5.2 als Standard lief. Man kann zwar per .htaccess die PHP-Version ändern, aber dann läuft PHP nicht mehr als Apache-Modul, sondern als FastCGI im Kontext des FTP-Benutzers. Genau das wollte ich aber nicht.

Die einzige Möglichkeit, eine aktuelle PHP-Version (5.6) als mod_php zu bekommen, ist der Umzug auf einen anderen Server, bei dem das neue PHP als Standard läuft.

Gesagt, getan. Am Abend des 25.11. habe ich meinen Wunsch dem Support vorgetragen und wurde noch direkt in die nächtlichen Updates und Umzüge eingetaktet. Am nächsten morgen war alles erledigt und meine Websites liefen mit PHP 5.6.

Und nicht nur das, sie waren sogar spürbar (und meßbar, siehe oben) schneller.

SSL muß nicht langsam sein

Putzlowitsch Chrome-Timeline

Alles in allem bin ich mit der HTTPS-Umstellung bei All-Inkl für meine „Putzlowitscher Zeitung“ sehr zufrieden. Ob und was es sonst nocht bringt, werde ich sehen. Technisch gesehen und von der Geschwindigleit her war es in jedem Fall ein Erfolg. :-)

3 Kommentare »

Geschwindigkeit vs. Sichertheit – https bremst Seite aus

Sicher ist sicher

Vor gut einem Monat habe ich meine schnurpsel.de-Website auf https umgestellt. Für das Shared-Webhosting bietet Strato zu einem monatlichen Preis von 2,99 Euro ein einfaches Single-Domain-Zertifikat an, welches ich nun hier auch nutze.

Schnurpsel mit Strato-SSL

Sichtbarer Effekt ist das Schloß-Symbol in der Adressleiste, welches auf eine sichere Verbindung hinweist. Die Übertragung der Daten vom Browser des Nutzers zum Server und umgekehrt ist verschlüsselt. So weit, so gut.

Sicher ist langsamer

Ich habe durchaus erwartet, daß die Seiten etwas langsamer werden, denn die Verschlüsselung benötigt natürlich Rechenzeit. Die ersten Test der auf https umgestellten Domain bestätigten das auch. Die Seiten werden merklich langsamer geladen. Aber wie langsam ist nun dieses Langsam, wenn es sogar merkbar ist?

Hierzu habe ich einen Blick in die Google-Webmastertools geworfen. Dort kann man sich die Ladezeiten für die Seitenabrufe durch den Googlebot ansehen.

Google-Webmastertools: schnurpsel.de mit https

Vor der Umstellung lag die Ladezeit zwischen 0,5 und 1 Sekunde. Das ist sicher kein Spitzenwert, aber durchaus akzeptabel. Nach der Umstellung bewegt sich die Zeit im Bereich von 1,5 bis 2 Sekunden, eine merkliche Verschlechterung.

Die Zeitfresser

Die konkreten Ladezeiten habe ich mir in den Entwicklertools von Chrome angesehen. Die Timeline und die „Resource network timing“ gibt Aufschluß darüber, wie lange etwas beim Aufruf einer Seite dauert.

Da ich keine „Meßwerte“ für schnurpsel.de aus der Zeit vor der https-Umstellung besitze, habe ich die Werte für ein Testblog, auch bei Strato gehostet, als Vergleich herangezogen.

Strato ohne https

Die Timeline für schnurpsel.de sieht so aus:

Die Zeiten für „Blocking“ und „DNS Lookup“ haben nichts mit dem Webserver selbst zu tun und liegen im normalen Rahmen.

Interessant wird es dann beim „Connecting„, der Zeit für den Verbindungsaufbau mit dem Server auf der Netzwerkebene (TCP) und eben auch für die erste SSL-Aushandlung. Die Zeit hat sich von etwa 30 ms ohne SSL auf fast 300 ms mit SSL mal eben verzehnfacht.

Die „SSL„-Zeit gibt es ohne https natürlich nicht. Hier wird die verschlüsselte Verbindung mit dem Schlüsselaustausch, Prüfung des Zertifikates usw. abschließend ausgehandelt. Das schlägt noch einmal mit mindestens 250 ms zu Buche.

Die Zeit für das Senden („Sending“) kann man praktisch vernachlässigen, sie liegt immer im Bereich von wenigen Millisekunden.

Die Wartezeit („Waitung“) ist die Zeit die vergeht, bis nach dem Senden der Anforderung (Request) die Antwort (Response) beim Browser eintrifft. Für WordPress ist es die Zeit, die benötigt wird, um die Seite zu erstellen, also Laden von WordPress, der Plugins und des Themes, Datenbankabfragen, Erzeugen der Ausgabe usw. Die Zeit liegt bei der Schnurpsel-Seite höher als bei der Testseite, weil einfach viel mehr Daten zu verarbeiten sind. Die Testinstallation ist praktisch eine leere WP-Seite.

Zu guter Letzt müssen die Daten vom Server zum Browser übertragen werden, was der „Receiving“-Zeit entspricht. Auch hier dauert es bei Schnurpsel Erwartungsgemäß länger, weil mehr Daten zu übertragen sind.

Langsames SSL bei Strato

Die zusätzliche Zeit von 550 ms (300 ms + 250 ms) paßt ganz gut zu dem, was in den Webmastertools von Google angezeigt wird. Wobei das eher die Untergrenze darstellt, die Verlängerung der Ladezeit durch SSL kann auch höher ausfallen.

Srato mit https (700 ms)

Letztendlich stellt sich mir nun die Frage, was besser oder schlechter ist. Die deutlich merkbar längere Ladezeit spricht gegen https, das mehr an Sicherheit, verbunden mit größerem Vertrauen und „Professionalität“, aber dafür.

Ich werde bei https bleiben und hoffe einfach, daß Strato da irgendwie noch was an der Geschwindigkeit verbesserm kann. Bei anderen Sachen haben sie es ja früher oder stäter auch geschafft. :-)

12 Kommentare »

Das Strato SSL Zertifikat – gut für den Nutzer (und für Google)

Sicher ist sicher

Gestern bestellt, heute schon aktiv, so schnell ging das mit dem Strato-SSL-Zertifikat für meine Domain schnurpsel.de. Zu erkennen ist das an dem Schloß-Symbol oben in der Adresszeile des Browsers.

Schnurpsel mit Strato-SSL

Alle Daten, die zwischen Eurem Webbrowser und meiner Website hin- und hergeschickt werden sind nun verschlüsselt. Das bedeutet, daß niemand mitlesen kann, welche Seiten Ihr aufruft oder welche Daten Ihr als Kommentar abschickt.

Der Spaß kostet mich zwar 2,99 Euro im Monat, aber das ist es mir wert. :-)

Das Strato Single-Domain SSL-Zertifikat

Strato bietet für die Webhosting-Pakete zwei Zertifikate an. Ein Single-Domain-Zertifikat für 2,99 Euro im Monat, das genau für die Domain gilt, für die es bestellt wird. In meinem Fall ist das schnurpsel.de, es funktioniert aber auch für www.schnurpsel.de. Das war noch nicht immer so, wie hier ein Nutzer schreibt.

Es gibt zudem ein Wildcard-Zertifikat für 9,99 Euro im Monat, das auch alle Subdomains mit abdeckt, wie z.B. testblog.schnurpsel.de oder bilderdieb.schnurpsel.de. Aber das ist mir dann doch zu teuer und die Subdomains sind praktisch nur Testseiten.

So sehen die Daten des Zertifikates aus:

Strato SSL-Zertifikat für www.schnurpsel.de

Ausgestellt ist es von Strato für www.schnurpsel.de, als Alternativ-Name ist aber auch schnurpsel.de eingetragen.

Das Zertifikat wird vom Browser ohne weitere Nachfrage akzeptiert, weil es in der Zertifikatshierarchie auf ein vertrauenswürdiges Root-Zertifikat von „Equifax Secure CA“ zurückgeht.

Besonderheiten beim Strato-SSL-Zertifikat

Viele Domains unter einer IP-Adresse

Ursprünglich funktioniert SSL nur dann, wenn unter einer IP-Adresse genau eine Website, also Domain angesprochen wird. Das liegt daran, daß die Verschlüsselung bereits bei der ersten Kontaktaufnahme des Browsers mit dem Server ausgehandelt wird und zu dem Zeitpunkt noch keine Information über die gewünschte Domain übertragen wird.

Beim Shared Webhosting der großen Anbieter wie auch Strato tummeln sich unter einer IP-Adresse aber viele Domains, so das hier SSL nicht ohne Weiteres funktioniert. Der Weg aus dem Dilemma ist eine Erweiterung des SSL-Standards von 2003 für das Multidomain-Hosting, die Server Name Indication (SNI). Hier wird der gewünschte Domainname bereits bei der Aushandlung, allerdings unverschlüsselt, übertragen.

Damit ist es möglich, auch mehrere Domains unter einer IP-Adresse mit individuellen SSL-Zertifikaten anzusprechen. Genau diese Erweiterung nutz auch Strato für die SSL-Zertifikate.

Die Sache hat eber einen kleinen Haken. Ältere Browser oder Geräte unterstützen den SNI-Standard nicht und so sind Websites damit nicht erreichbar. Der oben verlinkte Wikipedia-Artikel enthält eine Liste der Browser- und Systeme, die SNI unterstützen.

Die http auf https Weiterleitung

Damit künftig die Seite nur noch über https aufgerufen werden kann, sollten die http-Aufrufe auf https-Aufrufe weitergeleitet werde. Dazu bietet Strato im Kundenbereich die Option „SSL erzwingen“ an.

Strato-Option SSL erzwingen

Eigentlich eine feine und bequeme Sache, wäre da nicht ein Problem. Die Weiterleitung, die mit dieser Option ausgelöst wird, hat den Status 302 Found, was folgendes bedeutet:

„Die angeforderte Ressource steht vorübergehend unter der im „Location“-Header-Feld angegebenen Adresse bereit. Die alte Adresse bleibt gültig.“

Genau das wollen wir aber nicht, die Seite soll nun immer und nur per https erreichbar sein. Richtig wäre also der Status 301 Moved Permanently:

„Die angeforderte Ressource steht ab sofort unter der im „Location“-Header-Feld angegebenen Adresse bereit (auch Redirect genannt). Die alte Adresse ist nicht länger gültig.“

So soll es sein. Mein Tip daher für Euch: Setzt nicht die Option im Strato-Kundenmenü aktiv, sondern macht die Umleitung in der .htaccess selber. Das ist auch nicht weiter kompliziert. Bei mir steht folgendes drin:

# HTTPS erzwingen 
RewriteCond %{ENV:HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Das muß natürlich nach dem RewriteEngine On, aber am besten noch vor allen anderen RewriteRules stehen.

Warum Strato per 302 weiterleitet, keine Ahnung. Vielleicht sollte man sie mal auf den Fehler hinweisen. Mit den Statuscodes haben die es eh nicht so, wenn ich da noch an die Sache mit dem 410 denke.

https – ein Rankingvorteil bei Google

Als ich gestern das SSL-Zertifikat bei Strato bestellt hatte, wußte ich noch nicht, daß Google heute bekannt geben würde, daß die sichere SSL-Verschlüsselung ein Ranking-Faktor ist. Tja, Zufälle gibt es manchmal. :-)

Ist also alles prima und ich habe intuitiv das Richtige getan. Oder doch nicht?

Mir ist aufgefallen, daß meine Seiten hier bei Schnurpsel jetzt langsamer geladen werden. Zumindest kommt es mir so vor. Und da die Seitengschwindigkeit auch ein Rankingfaktor ist bleibt abzuwarten, was nun passiert. Überwiegt der Vorteil durch SSL oder der Nachteil durch die schlechtere Geschwindigkeit. Ich werde sehen…

19 Kommentare »

Wie schnell ist meine Webseite?

Nützliche Diagramme in den Webmastertools

In den Google-Webmastertools gibt es unter „Diagnostics->Crawl stats“ eine Übersicht zu den Aktivitäten des Google-Bots. Man kann sich für einen Zeitraum von 3 Monaten die Anzahl der jeweils pro Tag gecrawlten Seiten bzw. die heruntergeladene Kilobytes und die Dauer des Herunterladens einer Seite (in Millisekunden) als Grafik ansehen.

Mit letzterem Diagramm läßt sich recht gut die Leistungsfähigkeit des Webservers beurteilen. Die Zahlen sagen allerdings nicht unbedingt etwas darüber aus, wie schnell der normale Nutzer die Seiten angezeigt bekommt.

Ich habe mir die Daten für drei Webhoster angesehen.

All-Inkl

Google-Crawling bei All-Inkl - Juni bis August 2011

Bei All-Inkl habe ich unter anderem putzlowitsch.de gehostet. Die Seitenabrufzeiten des Google-Bots liegen bei fast konstanten 750 Millisekunden. Von Anfang Juni bis Anfang Juli gab es einen Anstieg auf ungefähr 1200 ms. Was da los war, kann ich nicht sagen.

Die Seitenabrufdauer ist mit den derzeitigen 0,75 Sekunden recht ordentlich. Auch die gefühlte Geschwindigkeit beim Aufruf der Putzlowitsch-Seiten ist für mein Dafürhalten gut bis sehr gut.

1&1

Google-Crawling bei 1&1 - Juni bis August 2011

Bei 1&1 habe ich zur Zeit keine wirklich wichtigen Seiten zu liegen. Das Diagramm zeigt die Zeiten für gerech.net, allerdings noch bevor ich dort das aktuelle WordPress (WP) 3.2.1 installiert hatte. Vorher gab es dort nur statische Seiten mit ein wenig SSI.

Die Zeiten liegen oft deutlich unter 750 Millisekunden, schwanken aber auch stärker. Insgesamt ist die Geschwindgkeit aber gut. Es bleibt abzuwarten, wie das nun mit WP und der intensiven Datenbanknutzung aussehen wird. Heute gab es zwischenzeitlich einige Probleme mit der Erreichbarkeit meiner 1&1-Seiten überhaupt.

Strato

Google-Crawling bei Strato - Juni bis August 2011

Strato war schon länger ein Performance-Sorgenkind. Nachdem die Sache mit PHP mittlerweile ganz gut läuft, scheint nun doch die Datenbank öfter mal die Seiten auszubremsen. Ich habe dazu im Moment eine kleine Test laufen, dessen bisheriger Verlauf aber auch Grund zur Hoffnung auf Verbesserung der Situation gibt.

Die Ladezeiten schwanken teils erheblich im Bereich von ungefähr 650 Millisekunden bis rauf zu 4,2 Sekunden. Auch die gefühlte Geschwindigkeit geht von zügiger Seitenanzeige bis zu lahmem Seitenaufbau. Zu bestimmten Zeiten kann das bis zu 20, 30 Sekunde gehen oder endet sogar im Timeout (Fehler 500).

Bei Strato läuft übrigens meine Schnurpsel-Seite hier.

Langsam, schnell oder mittelmäßig

Das Benutzererlebnis beim Besuch einer Webseite hängt von vielen Faktoren ab. Ein nicht unwichtiger Aspekt ist die Seitengeschwindigkeit. Die technische Basis dafür liefert die Performance des Webservers.

So gesehen bietet das Webhosting von All-Inkl eine gute Grundlage für schnelle Webseiten. Allerdings hängen die Leistungsdaten natürlich auch vom konkreten Hostingpaket ab. Insofern will ich nicht verschweigen, daß ich bei All-Inkl den Tarif „all-inkl Business 2011“, bei 1&1 „1&1 Homepage Business Pro“ und bei Strato „PowerPlus“ habe. In anderen Paketen kann die Geschwindigkeit anders aussehen.

Wie sieht denn bei Euch die Geschwindigkeitsgrafik in den Google-Webmastertools aus?

0 Kommentare »

Google-Bildersuche dynamisch und schnell wie nie zuvor

Schnell wie der Wind

Google-Bildersuche: Laufschuhe schnell im IndexEines muß man Google ja lassen, die Bildersuche ist so dynamisch und schnell wie nie zuvor.

Das gestern veröffentlichte Bild meiner neuen Asics-Treter ist schon heute in der Bildersuche zu finden, zur Suchphrase GT-2150 G-TX sogar auf der ersten Seite.

Googlebot-Image im Weihnachtsurlaub?

Allerdings war ich in den letzen Tagen schon etwas beunruhigt, weil seit etwa zwei Wochen der Googlebot-Image, welcher für die Bilder zuständig ist, hier bei Schnurpsel überhaupt nicht mehr zugange war.

Ein Blick auf die Bot-Statistik zeigt aber, daß wohl der normale Googlebot die Aufgaben des Image-Bots mit übernommen hat. Dieser hat in den letzten zwei Wochen 33 mal Bilder von schnurpsel.de abgerufen. Das ist nicht gerade viel, aber besser als gar nichts.

Auch bei Putzlowitsch sind die Bilderabfragen durch den Google-Bot eher bescheiden. Der Image-Bot war gut 60 mal da, der normale Bot hat reichlich 140 Bilder abgefragt. Das sind gerade mal ca. 15 Bilder am Tag, da gab es schon bessere Zeiten mit 50 bis 80 Bildern täglich. Aber gut, da will ich mal vom Bot über die Feiertage nicht zu viel verlangen. :-)

Viel und noch mehr, alt wie neu

Seit Anfang März zeichne für meine Hauptblogs die Ergebnisse der imagesite-Abfragen (seit August simuliert durch eine inurl-Abfrage) täglich auf. Die Lücken in den Kurven des Diagramms sind durch „Meßfehler“ bedingt.

Google-Bildersuche: Anzahl der Treffer für site-Abfrage

Kleinere Aufwärtsbewegungen sind Anfang April, Anfang Mai und Ende Juli zu erkennen. Einige Bewegung gab es Anfang/Mitte September, bis dann im Oktober die Zahlen deutlich zurück gingen. Der Verlust wurde im November und Anfang Dezember wieder ausgeglichen. Die Bewegungen passen zeitlich recht gut zu den Image-Updates, welche Martin vom TagSEOBlog sehr schön visualisiert hat.

Ab Mitte Dezember stieg die Anzahl der Bilder abermals deutlich an. Das sind bei Schnurpsel und Putzlowitsch jeweils mehr als 100 Bilder. Da ich in diesem Zeitraum bei weitem keine hundert neuen Bilder veröffentlicht habe, wurde hier offensichtlich ein größerer Teil älterer Bilder in den Index übernommen. Das sind teilweise auch Bilder, die früher schon im Index waren und wieder rausgeflogen sind (warum auch immer).

Ente gut, alles gut

Ich war es nicht

In den letzten Tagen zeigt die Kurve zwar wieder etwas nach unten aber insgesamt hat die Google-Bildersuche richtig gut Fahrt aufgenommen. Da will ich mal hoffen, daß es keinen Rückfall in die schnarchigen 3-Monats-Image-Updates gibt.

3 Kommentare »

Plug and Play

Plugin 123 HTTP TransportDas mit den Plugins für WordPress ist ja wirklich eine feine Sache. Es gibt deren viele und sie leisten teilweise Dinge, von denen man gar nicht wußte, das man sie jemals gebrauchen könnte.

Ja, auch ich verwende Plugins. :-)

Das aktuelle Thema des Wabmasterfridays lautet „Welche WordPress-Plugins habt ihr aktiv im Einsatz?“ und so habe ich hier im Blog-Adminbereich einfach mal nachgeschaut. Es sind derzeit ganze 27 aktive Plugins, die ich jetzt aber nicht alle ausführlich vorstellen werde.

Der Grund ist einfach. Das hier ist mein Test- und Entwicklungsblog und so laufen da viele Sachen zu Testzwecken. Von den 27 Plúgins sind bis auf eines alles Eigenentwicklungen. Man erkennt sie an dem „123 Irgendwas“-Namen.

Fremde Plugins

Das einzige fremde Plugin ist DoFollow. Damit wird des nofollow-Attribut bei Links in Kommentaren entfernt. Das stellt aber keinen Freifahrtschein für jeden Mist dar. Erstkommentare werden moderiert und gegebenfalls Entlinkt oder Entfollowt.

Eigene Plugins

Viele Plugins sind nur kleine Helferlein, teilweise sogar ohne Optionenseite, manche bügeln nur Fehlkonfigurationen der Webhoster aus.

Ein paar haben aber schon einen etwas größeren Umfang und Nutzwert.

  • 123 IntLink
    IntLink zählt zu meinen ältesten Plugins und hat sogar Editor-Buttons. Mit dem Plugin kann man mit der Artikel-ID (bzw. Kommentar-ID) einfach auf bloginterne Artikel, Seiten oder auch Kommentar verlinken. Die Links werden erst zur Laufzeit generiert. Damit passen sie immer, egal ob man mal die Permalinks ändert oder mit dem ganzen Blog umzieht.
  • 123 Shrink Link
    Wer kennt das nicht, im Kommentar hinterläßt jemand einen monstermäßig langen Link, der dann weit nach rechts über den Rand hinausragt und das in mühsamer Arbeit erstellte Design zerstört. Mit Shrink-Link werden solche Links für die Anzeige gekürzt. Mit ein paar Optionen kann man das Kürzungsverhalten steuern.
  • 123 Homelink
    Lange Zeit war es in WordPress nur möglich einen Menüeintrag mit einem Link zur Startseite im Theme zu programmieren. Das Plugin ermöglicht das Hinzufügen des Startseiten Links im Backend, außerdem das Ein- und Ausblenden von Seiten aus dem Menü un das ändern der Menütexte.
    Seit WP 3.0 ist das alles mit den Benutzermenüs ja bereits fest eingebaut.
  • 123 Tools
    Das Plugin ist eine Art Sammelplugin für kleinere Funktionen, für die sich kein eigenes Plugin lohnen würde. Ein Werkzeugkasten halt. :-)

Dann gibt es noch mehrere nicht öffentliche Plugins, die ganz unterschiedliche Funktionen haben. Mit dem „123 Character Mixer“ kann man Buchstaben vertauschen, so daß eigenartig fremdsprachig anmutende Texte entstehen. Sehr wichtig ist mir das „123 Shortlink“-Plugin, damit kann ich per Artikel- oder Attachment-ID eine Weiterleitung auf den Artikel oder direkt auf ein Bild generieren. Das brauche ich z.B., wenn ich die Artikel oder Bilder in Twitter abkippen will. :-)

Apropos in Twitter abkippen, das werde ich jetzt auch gleich tun… :-)

2 Kommentare »

WordPress mit Permalinks – den Webserver entlasten

Wie WordPress Permalinks verarbeitet

Durch Permalinks bekommen Artikel und Seiten lesbare URLs und auch Struktur. Alle Artikel in der Kategorie ‚Wordpess‘ können mit schnurpsel.de/themen/wordpress/ aufgerufen werden, das Monatsarchiv für Juli 2010 mit schnurpsel.de/date/2010/07/.

Auf dem Webserver existiert aber kein Verzeichnis /themen/wordpress/ oder /date/2010/07/. Damit die Seiten trotzdem aufgerufen werden können, erstellt WordPress eine einfache Regel für das Rewrite-Modul des Apache-Webservers:

RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

Diese drei Zeilen führen dazu, das alles, was nicht tatsächlich als Datei oder Verzeichnis auf dem Server existiert, einfach an die index.php von WordPress durchgereicht wird. WordPress kümmert sich nun darum, ob es z.B. eine Kategorie „WordPress“ gibt, stellt die Liste mit den passenden Artikeln zusammen und gibt sie aus.

Was es alles nicht gibt

Im Moment sind wohl mal wieder ein paar Bots oder Skriptkiddies unterwegs, die einfach versuchen, irgendwelche php-Skripte aufzurufen, um mögliche Sicherheitslücken ausnutzen zu können. Das sieht dann etwa so aus:

/scripts/setup.php
/pma/scripts/setup.php
/phpMyAdmin/scripts/setup.php
/phpmyadmin/scripts/setup.php
/myadmin/scripts/setup.php

Solche Dateien gibt es hier allerdings nicht. Auch andere Sachen können zu fehlerhaften Aufrufen führen, z.B. Standard-Icons wie favicon.ico oder apple-touch-icon.png, die manche Browser einfach aufrufen oder durch Nutzer aus der Bildersuche falsch kopierte BILd-URLs.

Durch die für die Permalinks notwendigen mod_rewrite-Regeln werden alle dies Aufrufe nun an WordPress weitergeleitet. WordPress wird geladen, stellt eine Datenbankverbingung her, klappert die internene Rewriteregeln ab um schließlich nur festzustellen, daß es mit dem Aufruf nichts anfangen kann. Dann gibt WordPress schließlich auch nur eine Fehlerseite aus, die möglicherweise auch noch aufwändig gestaltet ist und unnötig viel Daten als Antwort zurücküberträgt.

WordPress und den Webserver entlasten

Damit nun nicht WordPress wegen jeder Kleinigkeit behelligt werden, kann man eine spezielle Regel der WordPress-Regel vorschalten, die einfach gegebenfalls die Abarbeitung der Rewrite-Regeln beendet:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule \.[^\.]+$ - [L]
</IfModule>

Die Idee dabei ist, daß alle Permalink-URLs normalerweise keine Dateierweiterung wie .html, .jpg oder .php haben. Falls nun eine Datei nicht existiert (RewriteCond) und diese Datei mit einem Punkt und mindestens einem weiteren Zeichen endet, wird die Abarbeitung der Regeln an dieser Stelle beendet (RewriteRule). Diese Zeilen müssen vor den WordPress-Regeln stehen.

WordPress bekommt diese Aufrufe nicht mehr zu sehen, der Fehler wird einfach vom Webserver behandelt. Hier kommt dann auch eine konfigurierte und vorhanden benutzerdefinierte Fehlerseite zu Anwendung.

Ich weiß, es gibt auch Blogger, die aus welchen Gründen auch immer, die Permalinks mit einem abschließenden .html konfiguriert haben. Aber auch das ist kein Problem, es muß nur eine Zeile hinzugefügt werden, welche die Regel für die Endung .html (oder eine andere) ungültig macht:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_URI}	!\.html$
RewriteRule \.[^\.]+$ - [L]
</IfModule>

Optimierte Version

Mann kann die zusätzlichen Bedingungen auch direkt in die WordPress-Rules einfügen. Nachteil hierbei ist aber, daß sie bei Änderungen an den Permalinkeinstellungen verloren gehen, weil WordPress den Block zwischen # BEGIN WordPress und # END WordPress neu schreibt:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI}	!\.[^\.]+$
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Die Version mit Endung .html:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI}	!\.[^\.]+$ [OR]
RewriteCond %{REQUEST_URI}	\.html$
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Plugin-Version

Angeregt durch die Kommentare von Ralf habe ich nun eine Plugin-Version fertig gestellt.

Download: 123 Rewrite Error 0.10

Das Plugin schreibt die Regeln beim Aktivieren, Deaktivieren und bei Änderungen an der Permalinkstruktur wie bei der Optimierten Version beschrieben automtisch mit den WordPress-RewriteRules in die .htaccess. Dabei wird auch gleich berücksichtigt, ob in der Permalinkstruktur eine Erweiterung wie .html angegeben wurde.

Fazit

Wieviel Serverlast oder Traffic durch diese Maßnahme eingespart wird, kann ich nicht sagen. Das hängt sicher auch vom Nutzungsprofil und der Konfiguration der Website ab. Aber warum sollte man solch eine einfache Möglichkeiten auslassen, um WordPress und dem Webserver das Leben ein bißchen leichter zu machen.

8 Kommentare »