Wenn man seine Website mit Pagespeed überprüft und dabei die Meldung “Enable Compression” (Komprimierung anschalten) erhält, dann ist das ein Hinweis darauf, dass die Daten unkomprimiert vom Server zum User gelangen. Gerade bei größeren Webseiten kann man durch eine gzip-Compression aber einiges an Datenmenge (ca. 70-80 %) und damit auch an Übertragungszeit einsparen.

Generell gibt es 3 Möglichkeiten, wie man die gzip-Compression nutzen kann. Die einfachste ist ein simpler Eintrag in der .htaccess:

1. gzip-Compression über die .htaccess

<IfModule mod_deflate.c>
<FilesMatch "\\.(js|css|html|xml)$">
SetOutputFilter DEFLATE
</FilesMatch>
</IfModule>

In der ersten Zeile wird geprüft, ob das Modul mod_deflate auf dem Server aktiviert ist. Das ist nämlich Voraussetzung zur Nutzung der gzip-Compression. Danach werden dann alle Dateien mit der Endung .js, .css, .html, .xml komprimiert. Es können natürlich noch weitere Endungen hinzugefügt werden. Allerdings macht eine Kompression von Grafikformaten wie z. B. jpg, gif oder png wenig Sinn, da diese bereits von Haus aus komprimiert sind. Ein Nachteil dieser Methode ist, dass das Modul mod_deflate nicht bei allen Hostern installiert ist. In diesem Fall bietet sich Methode 2 an.

2. gzip-Compression mit PHP

Bei dieser Methode wird einfach bei jeder Seite, die man komprimieren möchte, in der ersten Zeile folgender Code eingefügt:

<?php
ob_start("ob_gzhandler");
?>

Diese Methode hat 2 Nachteile. Zum einen funktioniert sie nur mit php-Dateien. Die Datei muss also die Endung .php haben (dies kann man zwar auch umgehen, aber darauf will ich jetzt nicht näher eingehen). Außerdem muss der Code in jede Datei, die man komprimieren möchte, extra eingefügt werden. Wenn man viele Dateien hat, ist das natürlich eine Menge Arbeit. Deswegen sollte man zuerst die 1. Möglichkeit (gzip-Compression über die .htaccess) ausprobieren und nur wenn diese nicht funktioniert, die gzip-Compression über php erledigen.

3. Dateien vorkomprimieren

Die beiden ersten Methoden haben das Problem, dass sich dadurch die Serverlast etwas erhöht. Das ist eigentlich nicht weiter tragisch, da die eingesparte Datenmenge diesen Nachteil mehr als nur wettmacht. In einigen Fällen ist es aber trotzdem sinnvoll, die Kompression vorab von Hand zu erledigen. Dies bietet sich vor allem bei Dateien an, die einerseits sehr groß sind und andererseits nur selten geändert werden.

Wem bei dieser Beschreibung spontan Javascript-Bibliotheken wie z. B. jQuery einfallen, der liegt damit vollkommen richtig. In der aktuellen Version 1.4.2 hat jquery.js eine Größe von ca. 80 kb. Durch eine manuelle Kompression lässt sich die Dateigröße auf ca. 25 kb verringern. Nachdem man die Datei mit einem Packer wie z. B. 7zip verkleinert hat, kopiert man sie einfach in das gleiche Verzeichnis wie die Originaldatei. Um Kompatibilitätsprobleme mit dem Safari-Browser zu vermeiden, sollte man die Endung der komprimierten Datei von .gz auf .jgz ändern. Danach fügt man noch folgenden Code, den ich auf tutorialajax.com gefunden haben, in die .htaccess ein:

RewriteEngine on
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{REQUEST_FILENAME}.jgz -f
RewriteRule (.*)\.js$ $1\.js.jgz [L]
AddType "text/javascript" .js.jgz
AddEncoding gzip .jgz

Mit diesem Code wird die gepackte Version der Datei anstelle der Originaldatei ausgeliefert.

Nutzung der gzip-Compression mit WordPress

WordPress-User können die oben beschriebenen Methoden ebenfalls problemlos einsetzen. Aber wie so oft bei WordPress, gibt es für diesen Zweck natürlich auch ein Plugin, das einem auch bei der gzip-Compression das Leben erleichtern. Dabei handelt es sich um das Plugin wpCompressor des bekannten WordPress-Entwicklers Sergej Müller. Das Plugin setzt für die Komprimierung die oben beschriebene Methode 2 (gzip-Compression mit PHP) ein, die allerdings nicht so schnell ist wie die 1. Methode. Deshalb sollten auch WordPress-User lieber die gzip-Compression über die .htaccess nutzen und nur, wenn der Hoster dies nicht ermöglicht, zum Plugin greifen.

Test der gzip-Compression

Zum Testen, ob die gzip-Compression auch tatsächlich funktioniert, kann man dieses PHP-Skript verwenden. Einfach den Namen der Website eintippen und auf “Check” klicken. Dann kriegt man angezeigt, ob die angegebene Website komprimiert ist und welche Datenmenge eingespart wurde.

Fazit: Die Komprimierung von Webseiten macht auf alle Fälle Sinn und ist mit wenig Aufwand verbunden. Die einfachste und schnellste Methode ist die gzip-Compression über die .htaccess, die man durch eine Vorkomprimierung einzelner Dateien noch ergänzen kann. Falls dies vom Hoster nicht unterstützt wird, sollte man die Daten per PHP-Aufruf komprimieren.

Artikelreihe Webseiten beschleunigen:

Teil 1: Dateigröße von Grafiken verkleinern

Teil 2: Expires-Header verwenden

Teil 3: Parallele Downloads

WordPress hat viele tolle Funktionen, die standardmäßig eingebaute Suche gehört leider nicht dazu. Die ins Suchfeld eingetragenen Begriffe werden zwar gefunden, aber die Ausgabe erfolgt leider nur chronologisch, der neueste Beitrag zuerst, der älteste am Schluss. Damit muss man sich aber nicht abfinden, denn Google bietet die Möglichkeit, seine Suchfunktion in jede Website einzubauen. Allerdings muss man dann damit leben, dass Werbung eingeblendet wird. Wen das nicht stört oder wer es sogar wünscht, weil er sich damit noch ein paar Euro dazu verdienen will, kann die Google-Suche bedenkenlos verwenden. Allerdings gibt es beim Einbau der Google-Suche in WordPress einiges zu beachten.

Wer einen AdSense-Account hat, geht auf “Anzeigen abrufen” und wählt dort “AdSense für Suchergebnisseiten”. Auf dem dann folgenden Bildschirm gebt ihr dann an, ob ihr nur auf eurem Blog suchen oder das gesamte Web durchsuchen wollt. Bei einem Blog ist es sicher sinnvoll, nur diesen zu durchsuchen. Dann müsst ihr im nächsten Feld noch eure Blogadresse eintragen und im folgenden Feld noch einige sinnvolle Keywords, die zu eurem Blog passen. Die folgenden Einstellungen sind selbsterklärend, nur bei der Codierung müsst ihr aufpassen. Dort solltet ihr auf alle Fälle die Option “UTF-8″ anwählen, sonst werden nämlich von Google die Umlaute nicht richtig kodiert und Suchbegriffe, die einen Umlaut oder ein “ß” enthalten, nicht gefunden.

Bei der nächsten Maske sucht ihr euch noch ein Suchfeld aus, das euch gefällt und gebt die Länge des Textfeldes ein. Ich habe bei mir “28″ eingetragen, weil bei der vorgegebenen Einstellung von “31″ bei meinem Theme (Twenty Ten von WordPress 3.0) das Suchfeld zu lang wird und abgeschnitten wird.

Da ihr ja wahrscheinlich die Suchergebnisse nicht bei Google, sondern auf eurem eigenen Blog anzeigen lassen wollt, wählt ihr in der dritten Maske bei “Öffnen der Suchergebnisseite” den dritten Eintrag “Ergebnisse auf meiner eigenen Website öffnen” an und tragt eure URL ein. Als nächstes muss noch die Breite des Suchergebnisbereiches und der Anzeigenstandort angegeben werden. Wenn ihr beim Standort “Oben und rechts” anwählt, braucht ihr eine Mindestbreite von 795px. Da das bei den meisten WordPressthemes nicht passt, ist es sinnvoller “Oben und unten” anzugeben. Dafür braucht man dann nur eine Mindestbreite von 600 px. Ich habe bei mir 660px eingestellt. Dann braucht ihr eurer Google-Suche nur noch einen Namen zu geben und erhaltet zwei Codefragmente.

Da der Einbau dieser Codefragmente nicht gerade einfach ist, verwendet ihr dafür am besten das Plugin Google Custom Search. Nach der Installation geht ihr dann auf “Einstellungen/Google Search” und kopiert dort eure beiden Codes in die entsprechenden Felder rein. Bei den Settings braucht ihr normalerweise nichts zu ändern.

Allerdings gab es bei mir nach dem Einbau noch ein Problem. Die Sidebar wurde nämlich unter statt neben den Sucheinträgen angezeigt. Im WordPress-Forum fand ich aber einen netten Menschen, der mir weiterhelfen konnte und mir den Tipp gab, folgenden Code an die style.css im Verzeichnis wp-content/themes/twentyten anzuhängen:

#cse-search-results iframe { width:80%; margin-bottom:30px; float:left; }
.error404 #content.narrowcolumn form#searchform div { float:left; }
.error404 #primary { margin-top:-30px; }

Das hat dann auch prima funktioniert. Ich hätte nicht gedacht, dass es so schwierig sein würde, die Google-Suche in WordPress einzubauen. Aber letztendlich hat es dann doch hingehauen. Die Suche kann man sich hier angucken -> Weltrangliste. In diesen Blog hier habe ich sie nämlich (noch) nicht eingebaut.

© S. Hofschlaeger / Pixelio

Ich hoste meine Webseiten jetzt schon seit ungefähr einem Jahr bei all-inkl.com und bin bis auf Kleinigkeiten auch recht zufrieden mit diesem Anbieter. Vor 3 Tagen wollte ich nun einen neuen Blog aufsetzen und habe zufällig gesehen, dass es im KAS, dem Admin-Tool für all-inkl.com-Kunden, eine fertige Vorinstallation für WordPress gibt. Ganz spontan habe ich mich entschlossen, diese fertige Installation mal auszuprobieren anstatt WordPress selbst zu installieren.

Schnelle Vorinstallation

Das Gute an solch einer fertigen Installation ist ja, dass es viel schneller geht. Normalerweise dauert es schon 10-15 Minuten, bis alle WordPressdateien auf dem Webspace hochgeladen sind. Da bei einer Vorinstallation die Dateien ja nur innerhalb des Rechenzentrums kopiert werden, ging der ganze Vorgang natürlich wesentlich schneller als über das Internet und schon nach einer Minute waren alle Daten im Verzeichnis und WordPress war installiert.

Erstes Problem: Kubrick lacht mich an

Ich habe dann ein Theme installiert, den “Hallo Welt”-Artikel gelöscht, meinen ersten Artikel geschrieben und kurz überprüft ob alles in Ordnung war. Am nächsten Tag, als ich die Startseite aufgerufen habe, lachte mich plötzlich das Kubrick-Theme an und der “Hallo Welt”-Artikel wurde mir als einziger Eintrag angezeigt. Nachdem ich mich vom ersten Schock erholt hatte, meldete ich mich als Admin an und ging ins Dashboard. Dort war alles in Ordnung. Da stand nur mein erster Artikel und von “Hallo Welt” war nix zu sehen. Ich bin dann nochmal auf die Startseite gegangen und da war auf einmal auch wieder alles in Ordnung. Es war kein Kubrick-Theme und kein “Hallo Welt”-Artikel mehr zu sehen. Okay, dachte ich mir, wahrscheinlich lag das vorhin am Browsercache, der mir noch die alten Daten angezeigt hatte.

Irgendwie kam mir das Ganze dann aber doch komisch vor, deshalb loggte ich mich aus, löschte den Browsercache und startete Firefox nochmal neu. Als ich die Startseite dann wieder aufrief, präsentierte mir Kubrick wieder den “Hallo Welt”-Artikel Und das Seltsame war, dass das nur auf der Startseite so war. Wenn ich meinen Artikel direkt aufrief, wurde er einwandfrei mit dem richtigen Theme angezeigt. Allerdings lieferten mir dort die Kategorie- und die Archiv-Links einen Error 404.

Scheinbar war bei der Installation wohl etwas schief gelaufen. Ich wollte dann WordPress nochmal neu installieren, warf aber vorher noch einen Blick ins Plugin-Verzeichnis und was sah ich da? Da war das Plugin WP Super Cache vorinstalliert. Sollten die Probleme vielleicht daher kommen? Also deaktivierte ich das Plugin und siehe da, auf einmal funktionierte wieder alles

Zweites Problem: Google ignoriert den Blog

Allerdings war das leider nicht das einzige Problem, das ich mit der Vorinstallation von all-inkl.com hatte. Mein erster Artikel war ja schon über 24 h im Netz, da müsste er doch inzwischen bei Google zu finden sein. Aber so viel ich auch suchte, ich konnte ihn nicht finden. Okay, dachte ich mir, das lag vielleicht an dem Problem mit Super Cache, das ich ja gerade erst gelöst hatte.

Aber ein paar Stunden später war er immer noch nicht über Google zu finden. Und das, obwohl ich ihn in der Zwischenzeit bei einigen Social Networks eingetragen hatte. Normalerweise ist das dann nur eine Sache von wenigen Minuten, bis Google sich einen Artikel einverleibt hat. Ich habe dann mal im WordPress-Verzeichnis nach einer robots.txt gesucht, ob da vielleicht etwas gesperrt ist. Aber da war nix zu finden. Danach habe ich die Startseite aufgerufen und mir den Source-Code angesehen. Und was sehe ich da? <meta name="robots" content="noindex,nofollow" /> Wo kommt das denn her? Wieso ist der Blog denn für Suchmaschinen gesperrt? Ich hatte direkt die Plugins im Verdacht und deaktivierte die vorhandenen Plugins dann eins nach dem anderen. Aber selbst nach dem Abschalten aller Plugins war der falsche robots-Metatag immer noch im Code.

Ich sah mir dann die WordPresseinstellungen mal genauer an und bin bei Einstellungen/Privatsphäre fündig geworden. All-inkl.com hatte tatsächlich die WordPress-Voreinstellung “Ich möchte, dass mein Blog für jeden sichtbar ist, auch für Suchmaschinen” geändert auf “Ich möchte Suchmaschinen blockieren, aber normale Besucher zulassen.”

Antwort des Supports von all-inkl.com

Da mir völlig unbegreiflich war, wieso man solch eine Voreinstellung vornehmen kann, habe ich mal den Support von all-inkl.com angeschrieben und dabei auch das Problem mit Super-Cache angesprochen. Kurz darauf kam dann folgende Antwort:

Da WordPress im CGI-Modus einen sehr hohen Ressourcenverbrauch hat, sind die Einstellungen von WordPress auf optimale Performance ausgelegt.

Hmmm, unter optimaler Performance verstehe ich aber, dass die installierten Plugins dann auch einwandfrei funktionieren. Und auf meine Frage, wieso Suchmaschinen standardmäßig vom Blog ausgeschlossen werden, erhielt ich gar keine Antwort. Anstatt dem Problem nachzugehen und zu überprüfen, ob meine Bedenken vielleicht berechtigt sind, gibt es nur eine solche Larifari-Antwort. Normalerweise bin ich mit dem Support von all-inkl.com ja zufrieden, aber diesmal kann ich es wirklich nicht sein.

Fazit: Wenn man sich mit einem Skript gut auskennt und es schon mehrfach selbst installiert hat, sollte man auf die fertige Vorinstallation, die einem der Hoster (egal ob all-inkl.com oder ein anderer) anbietet, lieber verzichten. Die Überprüfung der ganzen Voreinstellungen dauert auf alle Fälle länger, als WordPress selbst hochzuladen und zu installieren.

Erfahrungen mit Vorinstallationen?

Habt ihr auch schon Vorinstallationen ausprobiert, die von eurem Hoster angeboten wurden? Gab es dabei auch Probleme? Schreibt doch bitte in den Kommentaren etwas dazu.

© N. Schmitz / Pixelio

In Japan wird zur Zeit an einer Titan-Disc geforscht, die die 100-fache Speicherkapazität einer Blu-ray Disc haben soll. Das neue optische Speichermedium soll aus Titanoxid bestehen, was bedeuten würde, dass die Rohstoffkosten um den Faktor 100 niedriger wären als bei einer Blu-ray Disc. Die zur Datenspeicherung verwendeten Teilchen haben nur eine Größe von 5-20 Nanometer. Bei Verwendung der kleinsten Teilchengröße könnte jede Titan-Disc die gigantische Datenmenge von ca. 5 TB (ca. 5000 GB) speichern.

Brauchen wir die Titan-Disc überhaupt?

Bisher war es bei jeder neu eingeführten Speichertechnologie so gewesen, dass man sich am Anfang fragte, ob solch gigantischen Speichermengen überhaupt gebraucht würden. Vor 20 Jahren bot eine Diskette mit einer Kapazität von 1,44 MB doch mehr als genug Platz. Schon bei der ihr nachfolgenden CD-ROM, die 650 MB speichern konnte, fragte man sich, was man mit soviel Speicherplatz überhaupt anfangen könnte. Dann kam die DVD, die eine Speicherkapazität von 5 GB bot. Damit ließen sich dann schon komplette Filme auf einem einzigen optischen Datenträger speichern. Und auf einer doppellagigen Blu-ray Disc kann man heute so viel speichern wie auf 10 DVDs. Brauchen wir da wirklich noch die 100-fache Speicherkapazität?

Ich denke schon, denn selbst heute gibt es noch Datenmengen, die nicht auf eine Blu-ray Disc passen. Auf einer Titan-Disc könnte man z. B. komplette Film-Sammlungen speichern. Alle James-Bond-Filme oder alle Folgen der Lindenstraße auf einem Datenträger wären doch eine feine Sache. Und das natürlich hochauflösend in bester Qualität. Ganze Bibliotheken könnte man natürlich auch darauf speichern. Bei Unglücksfällen wie beim Einsturz des Kölner Stadtarchivs oder beim Brand der Anna Amalia Bibliothek in Weimar würden keine wertvollen historischen Aufzeichnungen mehr verlorengehen, da die eingescannten Bücher ja auf einer Titan-Disc gespeichert werden könnten.

5 Terabyte können noch zu wenig sein

Und man braucht sich nichts vorzumachen, selbst mit einer Speicherkapazität von 5 TB pro Datenträger wird es immer noch Datenmengen geben, für die die Titan-Disc zu klein ist. Für alle weltweit gespeicherten Internetdaten würde der zur Verfügung stehende Speicherplatz z. B. bei weitem noch nicht reichen.

Wann kommt die Titan-Disc?

Wie lange es dauert, bis die Titan-Disc auf den Markt kommt ist noch nicht abzusehen. Zur Zeit wird ja noch daran geforscht. Es gibt zwar bereits Gespräche mit privaten Investoren, aber trotzdem dürfte es wohl noch ein paar Jahre dauern, bis dieses Speichermedium in den Warenhaus-Regalen liegt. Falls sie überhaupt kommt, denn es kann natürlich auch sein, dass unlösbare Probleme auftreten und die Titan-Disc niemals erscheinen wird. Das wäre aber sehr schade, wenn man bedenkt, welche gigantischen Möglichkeiten sie bieten könnte.

Eure Meinung zur Titan-Disc?

Was haltet ihr von der Titan-Disc? Glaubt ihr, dass sie irgendwann auf den Markt kommt? Welche Einsatzmöglichkeiten könnte es dafür geben? Schreibt doch bitte in den Kommentaren etwas dazu.

Gestern habe ich im Artikel Seitenaufbau beschleunigen 3 – Parallele Downloads ja erklärt, wieso es besser ist, die Ressourcen, die eine Webseite benötigt, auf mehrere Domains bzw. Subdomains zu verteilen. Der theoretische Hintergrund dürfte damit klar sein und wie man dies auf statischen Webseiten praktisch umsetzt, habe ich in dem Artikel ja auch beschrieben.

© Stephanie Hofschlaeger / Pixelio

Auch bei WordPress ist es möglich, die Ressourcen auf mehrere Domains zu verteilen. Allerdings kann man hier nicht so einfach ohne Rücksicht auf Verluste die Dateien verschieben und die Pfadangaben ändern. Schließlich greifen ja auch Plugins auf diese Dateien zu und es kommt natürlich zu Problemen, wenn diese nicht gefunden werden.

Deshalb habe ich mich auf die Themes-Grafiken und die Uploads beschränkt, da diese Dateien meiner Erfahrung nach problemlos umgelenkt werden können.

Themes-Grafiken auslagern

Die Grafiken des Themes liegen im Ordner wpcontent/themes/Themename/images. Nachdem ihr wie gestern beschrieben eine Subdomain angelegt habt, legt ihr dort einen Ordner namens “images” an und kopiert die Grafiken rein (eventuell könnt ihr die Grafiken vorher noch mit OptiPNG verkleinern). Dann ändert ihr alle Pfadangaben zu den Grafiken. Diese sind in der Datei wpcontent/themes/Themename/style.css gespeichert (vorher natürlich ein Backup machen). Aus wpcontent/themes/Themename/images/bgr_header.png macht ihr dann z. B. http://extern.example.com/images/bgr_header.png. Achtung! Im images-Ordner können auch Grafiken drin sein, die nicht über die style.css aufgerufen werden. Diese dürft ihr nach dem Auslagern natürlich nicht löschen.

Umzug des Upload-Ordners

Als zweiten Schritt könnt ihr auch noch eure Uploads auf der Subdomain auslagern. Da wir dafür Veränderungen in der Datenbank vornehmen müssen, macht bitte zuerst ein Backup der WordPress-Datenbank. Als nächstes kopiert ihr den kompletten Ordner Uploads, den ihr unter wpcontent/uploads findet, auf die Subdomain. Der Ordner sollte dann unter http://extern.example.com/uploads zu erreichen sein. Wichtig ist jetzt auch, die Rechte richtig zu setzen. Der Ordner “extern” bekommt 755 als Rechte, der Ordner Uploads mitsamt den darunterliegenden Ordnern und Verzeichnissen 777. Das ist kein Sicherheitsrisiko, sondern die standardmäßige WordPresseinstellung für den Uploads-Ordner. Mit niedrigeren Rechten ist kein Upload möglich.

Danach meldet ihr euch in WordPress als Admin an und wählt im Menü “Einstellungen” den Menüpunkt “Verschiedenes” an. Dort ändert ihr im Textfeld “Uploads in folgenden Ordnern speichern” den Uploadpfad ab. Normalerweise sieht der ungefähr so aus: /www/htdocs/Meine_Kundennummer/Mein_Ordner/wp-content/uploads. Den ändert ihr dann auf den neuen Uploadordner ab, das könnte z. B. so aussehen: /www/htdocs/Meine_Kundennummer/Mein_Ordner/extern/uploads. Wobei “extern” der Ordner ist, dem ihr die Subdomain zugewiesen habt. Es ist ein wenig schwierig, das allgemeingültig zu erklären, weil es bei jedem Hoster ein bisschen anders aussieht. Im Feld “Kompletter Pfad zu den Dateien” gebt ihr dann die Subdomain und den Ordnernamen an, in dem ihr die Uploads gespeichert habt, also z. B. http://extern.example.com/uploads. In beiden Feldern darf am Ende kein Schrägstrich stehen!

Anschließend müsst ihr noch an die Datenbank ran. Dort gebt ihr im SQL-Feld folgenden Code ein (übernommen vom Hausblog14):

UPDATE wp_posts SET post_content = REPLACE(post_content, 'http://example.com/Mein_Ordner/wp-content/uploads/', 'http://extern.example.com/uploads/');

Mit diesem Code wird der bisherige Pfad zum Uploadordner durch den neuen Pfad ersetzt. Die erste Pfadangabe gibt an, wo der Ordner bisher gespeichert war und die zweite weist auf den neuen Ordner hin. Diesmal müssen beide Pfade mit einem Schrägstrich enden.

So, das war es dann auch schon. Ab sofort werden auch bei euch die Ressourcen besser verteilt und ihr dürft euch an einem schnelleren WordPress erfreuen

Hat alles geklappt?

Schreibt doch mal in den Kommentaren, ob bei euch alles geklappt hat. Falls etwas unklar ist, könnt ihr natürlich auch noch Fragen zu der Anleitung stellen.

© Rainer Sturm / Pixelio

Wer seine Webseiten mit Page Speed analysieren läßt, kriegt sehr wahrscheinlich die Meldung “Parallelize downloads across hostnames” angezeigt. Das klingt ziemlich kryptisch, weist aber nur auf eine eher wenig bekannte Möglichkeit hin, seine Webseiten zu beschleunigen. Gemeint ist das Parallelisieren von Downloads über verschiedene Domains. Das hört sich im ersten Moment ziemlich kompliziert an und ist auch nicht ganz einfach zu verstehen, aber ich verspreche, dass ich mir Mühe geben werde, es verständlich zu erklären.

Parallele Downloads – die Theorie

Eine typische Webseite besteht aus vielen Ressourcen (Komponenten), die nacheinander vom Browser aufgerufen werden müssen. Dazu zählen z. B. CSS-Dateien, Javascript-Dateien und Bilder. Auf der Startseite meiner Rätselseite werden z. B. 23 Ressourcen geladen, bevor die Seite angezeigt werden kann (die Anzahl der Ressourcen erfährt man wenn man in Page Speed den Tab “Resources” anklickt). Nun ist es so geregelt, dass Browser 2 Ressourcen auf einmal (also parallel) herunterladen sollen. Die modernen Browser laden sogar 4-6 Ressourcen gleichzeitig herunter. Trotzdem ist das immer noch ziemlich wenig, zumal es durchaus auch Webseiten gibt, die aus 50 oder noch mehr Ressourcen bestehen.

Generell ist es so, dass alle Ressourcen von einer Domain heruntergeladen werden. Wenn man jetzt die Ressourcen aber auf 2 Domains verteilt, lädt ein Browser die doppelte Menge an Ressourcen gleichzeitig herunter. Und das Schöne daran ist, man braucht dafür keine zweite Domain, das Ganze funktioniert nämlich auch mit einer Subdomain.

Parallele Downloads – die Praxis

Wer seine Downloads nun parallelisieren möchte, sollte zuerst mal eine Subdomain anlegen, z. B. http://extern.example.com. Auf dieser Subdomain speichert ihr nun z. B. alle Grafiken, aus denen das Layout besteht. Diese bieten sich deshalb an, weil das Layout ja normalerweise von allen Webseiten verwendet wird und damit alle Seiten gleichzeitig davon profitieren. Danach müssen in allen HTML- und CSS-Dateien die Pfade geändert werden, damit die Grafiken auch gefunden werden können. Wer viele Webseiten hat, für die er Pfadänderungen vornehmen muss, dem empfehle ich für diesen Zweck Notepad++ zu verwenden. Dieser Editor bietet die Möglichkeit des Suchens und Ersetzens über mehrere Dateien hinweg.

Und das war’s dann auch schon. Das Ganze hört sich zwar im ersten Moment schwierig an, aber die praktische Umsetzung ist dafür ziemlich unproblematisch. Messungen habe ich keine vorgenommen, aber meine Webseiten sind nach der Parallelisierung spürbar schneller geworden.

Parallele Downloads bei WordPress

Und allen Blogbetreibern, die wissen wollen, ob das auch mit WordPress funktioniert, kann ich sagen: Ja, es funktioniert und es macht WordPress ein gutes Stück schneller. Die Umsetzung ist allerdings ein bisschen komplizierter, deshalb schreibe ich dazu einen extra Artikel, den ihr morgen hier findet Ressourcen verteilen – WordPress schneller machen

Artikelreihe Webseiten beschleunigen:

Teil 1: Dateigröße von Grafiken verkleinern

Teil 2: Expires-Header verwenden

Teil 4: Die gzip-Compression

Piet von Netzpanorama hat gestern in seinem Artikel Artikelübersicht oder Inhaltsverzeichnis als WordPress Unterseite beschrieben, wie er mit dem WordPress-Plugin Articles eine Sitemap erstellt. Genauer gesagt erstellt dieses Plugin eine HTML-Sitemap, die die Benutzerfreundlichkeit eines Blogs verbessern soll. Das ist der Unterschied zu einer XML-Sitemap, die man erstellt, damit Google sich besser auf der eigenen Website zurechtfindet.

Während bei Piet das Plugin einwandfrei funktioniert, gab es bei mir und zwei anderen Usern Probleme. Articles bietet nämlich zwei Möglichkeiten, eine Sitemap in den eigenen Blog einzubinden. Bei der ersten Variante musste man einen php-Code einfügen, was einen größeren Eingriff ins Template bedeutet hätte.

Einstellungen des Sitemap-Plugins Articles

Für die zweite Möglichkeit musste man lediglich eine neue Seite erstellen und dort in der HTML-Ansicht einen Token einfügen. Außerdem musste man in den Plugineinstellungen ein Auswahlfeld von “No” auf “Yes” ändern. Und genau da hakte es bei mir. Ich konnte zwar die Auswahl auf “Yes” ändern, nach Drücken des Buttons “Update Articles Settings” wurde automatisch wieder die Auswahl auf “No” gestellt.

Ich dachte zuerst, es würde vielleicht an den Dateirechten liegen und stellte das Pluginverzeichnis und die Plugindatei auf 777. Das brachte aber leider nix. Also guckte ich mir mal die WordPress-Datenbank mal näher an und siehe da, da fand ich einen passenden Eintrag, den ich nur von 0 auf 1 ändern musste.

Ich poste hier jetzt mal die genaue Anleitung, wie man die Änderung vornimmt. Wer diese nachvollziehen will, sollte aber unbedingt vorher ein Backup der WordPress-Datenbank machen. Wie das funktioniert habe ich in diesem Artikel bereits erklärt: Datenbank optimieren mit phpMyAdmin.

Datenbankwert bei aka_token von 0 auf 1 ändern

Um in den Plugineinstellungen von Article bei der Option “Enable token method for showing the articles list” den Wert “Yes” einzustellen, muss man in der Tabelle wp_options den Wert “aka_token” auswählen (wenn Articles gerade erst installiert wurde, müsste der Wert in der Tabelle ziemlich weit hinten stehen) und auf Bearbeiten klicken. Dort ändert man den angezeigten Wert von “0″ auf “1″ und klickt auf “OK”. Jetzt braucht man nur noch wie vorgesehen eine Seite zu erstellen und dort den Token einzufügen.

Artikel in die Sitemap aufnehmen

Für ein weiteres Problem habe ich leider keine brauchbare Lösung gefunden. Damit Articles weiß, welchen Beitrag man in der Sitemap haben will, muss man nämlich jeden einzelnen Beitrag bearbeiten und dort bei “Mark as an Article?” mittels eines Radiobuttons das voreingestellte “No” auf “Yes” ändern. Wenn man mehrere hundert Beiträge hat, ist das natürlich ein riesiger Aufwand. Diese Einstellung wird zwar auch in der Datenbank gespeichert, es muss aber zuvor für jeden Artikel ein Datenbankeintrag angelegt werden. Und da ist es doch einfacher, diese Einstellung direkt im Beitrag vorzunehmen. Falls jemand eine einfache Lösung für dieses Problem hat, bin ich natürlich für eine Anregung dankbar

Alles in allem muss ich doch Piet zustimmen, der meinte, dass sich diese Fleißarbeit auf jeden Fall lohnen würde. Denn die von Articles erstellte Sitemap ist nicht nur übersichtlich, sondern auch optisch gut gelungen.

Im ersten Teil der Reihe “Webseiten beschleunigen” hatte ich beschrieben, wie man mit Hilfe von OptiPNG die Dateigröße von Grafiken verkleinern und damit die Ladezeit verkürzen kann. Im zweiten Teil widme ich mich nun einem etwas komplexeren Thema, nämlich der Verwendung von Expires-Header.

Leverage browser caching

Wenn man mit dem Googletool PageSpeed die eigene Website analysieren lässt, dürfte bei den meisten wohl diese Meldung mit einem roten Ausrufezeichen angezeigt werden: Leverage browser caching. Dies bedeutet soviel wie, dass das Browsercaching nicht optimal eingestellt ist. Doch wie kann ich das Browsercaching meiner Seiten optimieren? Um dies zu erreichen, erkläre ich erst mal, wie so ein Browsercaching überhaupt funktioniert.

© katstep / Pixelio

Funktionsweise des Browsercaches

Wenn man eine Website besucht, speichert der Browser des Users diese in einem Zwischenspeicher, dem Browsercache. Wenn der User die gleiche Seite ein zweites Mal besucht, fragt der Browser beim Webserver der Webseite nach, ob sich diese geändert hat. Falls ja, fordert der Browser des Users diese Seite nochmal neu an. Falls nein, liest der Browser diese aus seinem Cache. Das geht natürlich wesentlich schneller, da die benötigten Daten ja schon auf dem Rechner des Users liegen und nicht mehr per Internet übertragen werden müssen.

Im ersten Moment hört sich das nach einer optimalen Lösung an. Allerdings verbraucht auch bereits die Abfrage, ob die Seite schon mal besucht wurde oder nicht, eine gewisse Zeit. Für eine Datei ist das nicht viel, aber eine einzige Seite ruft ja oftmals 10-20 Dateien auf, wie z. B. das Logo, das Favicon, CSS-Dateien, Javascript-Dateien usw. Und bei jeder einzelnen Datei fragt der Browser beim Server nach, ob sich diese geändert hat. Diese vielen Abfragen summieren sich dann natürlich und allein dadurch kann sich die Ladezeit einer Seite um 2-3 Sekunden verlängern.

Den richtigen Zeitraum einstellen

Verhindern kann man dies, indem der Server dem Browser eines Users mitteilt, dass er für eine gewisse Zeit auf diese Abfragen verzichten soll. Dies erreicht man durch die Verwendung von Expires-Header. Mit einem Expires-Header gibt man an, für welchen Zeitraum diese Abfragen nicht mehr erfolgen sollen. Wie lange dieser Zeitraum ist, ist von Dateityp zu Dateityp verschieden und über die richtige Einstellung sollte man sich vor der Verwendung von Expires-Header einige Gedanken machen.

Der Nachteil, wenn man Expires-Header verwendet, ist nämlich, dass Änderungen, die man an einer Datei vornimmt, vom Browser des Users nicht erkannt werden. Schließlich fragt er ja nicht mehr nach, ob eine Datei geändert wurde oder nicht. Wenn man also z. B. eine wichtige css-Datei hat, sollte man den Zeitraum nicht zu hoch einstellen, weil der User die Änderungen an dieser Datei ja erst bei der nächsten Abfrage mitbekommt. Bei Bildern ist es dagegen meistens so, dass man diese nachdem man sie in die Website eingebaut hat, nicht mehr ändert. Deshalb kann man hier den Zeitraum ziemlich hoch einstellen.

Eintragungen in der .htaccess

Nach dem langen theoretischen Vorgeplänkel, das aber leider notwendig war, folgt nun die Praxis. Wenn ihr Expires-Header verwenden wollt, müsst ihr folgende Eintragungen in eurer .htaccess machen.

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css "access plus 1 week"
ExpiresByType application/javascript "access plus 1 month"
ExpiresByType application/x-javascript "access plus 1 month"
ExpiresByType image/gif "access plus 1 month"
ExpiresByType image/jpeg "access plus 1 month"
ExpiresByType image/png "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
</IfModule>

Die If-Abfrage in der ersten Zeile prüft ob das Apache-Modul mod_expires.c verfügbar ist. Falls ja, wird es aktiviert und der Zeitraum für die einzelnen Dateitypen wird eingestellt. ‘ExpiresByType text/css “access plus 1 week”‘ bedeutet z. B. dass nachdem der Browser des Users auf eine css-Datei zugegriffen hat, er eine Woche lang diese Datei aus dem Browsercache holt und sie erst nach Ablauf dieser Frist erneut einliest.

Man kann die Expires-Header natürlich auch noch für andere Dateitypen verwenden. Bei reinen HTML-Dateien macht es allerdings weniger Sinn, da diese ja meist nur wenige kb groß sind. Expires-Header lassen sich auch mit WordPress nutzen, allerdings sollte man die .htaccess nur in die Verzeichnisse wp-admin und wp-includes einbauen und nicht in das Verzeichnis wp-content.

Oben habe ich geschrieben, dass Änderungen an den Dateien erst nach Ablauf des eingestellten Zeitraums wirksam werden. Falls man trotzdem wichtige Änderungen vornehmen will, die sofort bei allen Usern sichtbar werden sollen, kann man zu einem kleinen Kniff greifen. Man hängt an die Datei, die man ändern möchte, einfach eine Zahl an, z. B. style2.css und ändert den Aufruf im HTML-Code. Da diese Datei für den Browser ja neu ist, wird er sie neu einlesen. Dieser Trick ist aber nur bei kleinen Websites sinnvoll oder wenn nur wenige Dateien geändert werden müssen, da der Aufwand sonst zu groß wird.

Was bringen Expires-Header?

Ich habe den oben geposteten Code in die .htaccess meiner Rätselseite eingebaut und ich war überrascht über die erhebliche Leistungssteigerung, die der Einsatz der Expires-Header gebracht hat. Ich hatte das Gefühl, als hätte ich einen kleinen Turbo dazugeschaltet

Und das Schöne daran ist, man schlägt 2 Fliegen mit einer Klappe. Erstens verringert sich die Ladezeit beim Besucher der Website und zweitens wird auch der Server weniger beansprucht, da er ja weniger Anfragen bearbeiten muss.

Eigene Erfahrungen

Setzt ihr auf euren Websites auch Expires-Header ein? Welche Zeiträume habt ihr für die einzelnen Dateien eingestellt? Schreibt doch in den Kommentaren was zu euren Erfahrungen.

Artikelreihe Webseiten beschleunigen:

Teil 1: Dateigröße von Grafiken verkleinern

Teil 3: Parallele Downloads

Teil 4: Die gzip-Compression

Bei erfolgs-blogging.de habe ich heute einen schönen Artikel darüber gefunden, wie man seine WordPress-Datenbank optimieren kann. Der Autor empfiehlt z. B. auf die Tabelle mit den Kommentaren den MySQL-Befehl “Optimize” anzuwenden. Ich habe das ausprobiert und es hat auch einwandfrei funktioniert. Dann habe ich mir gedacht, warum nur auf eine Tabelle anwenden, es bringt doch sicher noch mehr, wenn ich die ganze Datenbank optimiere? Und warum sollte ich mich auf WordPress beschränken, ich verwende doch noch andere Datenbanken, z. B. für mein Rätselforum oder für Piwik?

Also habe ich dann alle Tabellen all meiner Datenbanken der Reihe nach optimiert. Bei den meisten hatte sich die Größe nach der Optimierung zwar etwas verkleinert, aber der Effekt hielt sich doch in Grenzen. Als letztes war dann die Piwik-Datenbank an der Reihe. Diese hatte ich im Dezember 2009 angelegt und bis heute hatte sie die stattliche Größe von 324 MB erreicht. Als ich dann die Optimierung startete, traute ich meinen Augen kaum, denn die Optimierung brachte eine Verkleinerung der Datenbank von satten 50 MB auf 274 MB!

Da die Anleitung auf erfolgsblogging.de doch etwas knapp geraten ist, erkläre ich hier etwas ausführlicher, wie man vorgehen muss, um seine Datenbanken zu optimieren und damit auch zu verkleinern. Ich verwende dafür phpMyAdmin, das eigentlich bei jedem Webhoster installiert sein sollte.

Nach dem Start von phpMyAdmin klickt man oben links auf den Namen der Datenbank. Damit stellt man sicher, dass die richtige Datenbank ausgewählt ist. Und was macht man als nächstes, wenn man an seiner Datenbank etwas ändern möchte? Natürlich ein Backup.

Backup erstellen

Dafür klickt man in der oberen Menüleiste auf “Exportieren”. Falls noch nicht voreingestellt, klickt man dann links oben auf “Alle auswählen”, damit man auch sicher ist, dass wirklich alle Daten gesichert sind. Darunter kann man dann ein beliebiges Exportformat wählen. Da es sich um ein Backup handelt, empfiehlt es sich “SQL” zu verwenden. Falls es ein Problem bei der Optimierung geben sollte, kann man die Datenbank in diesem Format am einfachsten über den Menüpunkt “Importieren” wiederherstellen. Weiter unten klickt man dann noch “Senden” und ein Kompressionsverfahren (z. B. ZIP) an, damit das Backup nicht mehr Platz wegnimmt als unbedingt nötig. Nach dem Klick auf “OK” gibt man noch den Dateinamen an, unter dem das Backup gespeichert werden soll.

Datenbank-Backup mit phpMyAdmin

Datenbank optimieren

Nachdem das Backup dann fertig ist (und auch wirklich erst danach), kann man sich an das Optimieren der Datenbank wagen. Dazu klickt man auf in der oberen Menüleiste auf “Struktur”. Dort werden dann alle Tabellen angezeigt, die die Datenbank enthält. Am Ende der Anzeige wird unter “Größe” die Gesamtgröße angezeigt. Links unten sollte man auf “Alle auswählen” klicken und danach in der Schaltfläche rechts daneben “Optimiere Tabelle” anwählen. Dabei bitte sehr genau darauf achten, was man anklickt, denn die Schaltfläche beinhaltet auch solch gefährliche Menüpunkte wie “Leeren” oder “Löschen”. Bei mir wurde der Optimierungsvorgang übrigens sofort nach der Auswahl gestartet, ohne dass ich auf “OK” klicken musste.

Datenbank optimieren mit phpMyAdmin

Wenn alles geklappt hat wird eine Übersicht angezeigt, welche Tabelle optimiert wurde (OK) und welche nicht (Table is already up to date). Wenn man sich jetzt wieder die Struktur anzeigen lässt, sieht man die neue Größe der Datenbank nach der Optimierung.

Achtung! Wie bereits erwähnt sollte man vor der Datenbankoptimierung unbedingt ein Backup erstellen. Es passiert ganz schnell, dass man mit einem falschen Mausklick Daten ungewollt löscht. Ohne Backup kann dann die Arbeit von Wochen oder Monaten mit einem Schlag weg sein!

Eigene Erfahrungen

Welche Erfahrungen habt ihr mit dem Optimieren von Datenbanken gemacht? Um wie viel konntet ihr eure Datenbankgröße reduzieren? Schreibt doch bitte in den Kommentaren etwas dazu.

Gestern habe ich eine statische Seite in WordPress erstellt und wollte auf dieser Seite 3 Bilder einbinden. Der Text sollte neben den Bildern entlang fließen. Also eigentlich nichts besonderes. Das Problem war nur, dass es ziemlich wenig Text war und die Grafiken wesentlich höher als der Text waren. Dadurch wurde alles bunt miteinander vermischt:

Wordpress-Artikel ohne Leerzeilen

Ich habe dann natürlich die naheliegendste Möglichkeit ausprobiert und einige Zeilenumbrüche eingefügt. In der visuellen Ansicht des WordPress-Editors sah das auch so aus, wie ich es haben wollte. Aber sobald ich auf Vorschau geklickt habe, waren die Zeilenumbrüche wieder weg.

Naja, dachte ich mir, wenn es in der visuellen Ansicht nicht funktioniert, versuche ich mal mein Glück in der HTML-Ansicht und habe dort einige “<br />” eingefügt. Nach einem Klick auf den Vorschau-Button bot sich mir allerdings das bekannte Bild. Die Zeilenumbrüche waren wieder verschwunden

Dann habe ich die Hilfe von Tante Google in Anspruch genommen und schnell festgestellt, dass ich nicht der einzige war, der Probleme damit hatte, Leerzeilen in WordPress einzufügen. Die ersten Einträge, die ich fand, haben mir leider nicht viel weitergeholfen. Da wurde zum Beispiel vorgeschlagen, folgenden Eintrag in die style.css aufzunehmen:

.entry p { margin-bottom: 1em; }

Das brachte aber leider auch keinen Erfolg

Langer Rede, kurzer Sinn: Ich habe nach einigem Suchen dann sogar 2 Möglichkeiten gefunden, wie man Leerzeilen in WordPress einfügen kann.

Zum einen gibt es die etwas unsaubere Lösung ein geschütztes Leerzeichen in ein p oder in ein blockquote einzubauen, also so:

<p>&nbsp;</p>

bzw. so:

<blockquote>&nbsp;</blockquote>.

Die zweite Lösung, die ich bei Rainer Meyer gefunden habe ist dann etwas sauberer, da sie CSS einsetzt um den benötigten Leerraum zu schaffen:

<p style="margin-top: 20px">20 Pixel Leerraum</p>

Damit erzeugt man vor dem Absatz einen 20 Pixel großen Leerraum. Man kann natürlich auch margin-bottom verwenden, um den Leerraum hinter dem Absatz zu erzeugen. Das Ganze sah danach dann so aus:

Wordpress-Artikel mit Leerzeilen

Das bleibt natürlich nicht so. Der Leerraum wird noch mit Text aufgefüllt werden. Es ging mir nur darum, mal eine Zwischenlösung zu haben, bis der restliche Text geschrieben war.

Wobei ich mich frage, was macht da ein Blogger, dem es nur ums reine Schreiben geht und der von HTML und CSS keine Ahnung hat? Da hätte ich doch gedacht, dass WordPress eine einfachere Lösung bietet, um Leerzeilen einzufügen.

Oder gibt es eine und ich habe sie nur nicht gefunden? Wenn ihr eine wisst, dann postet sie doch bitte als Kommentar.